ECS vs EKS: quale servizio di container AWS fa per te?

Che cos’è ECS?

ECS è il servizio proprietario e gestito di orchestrazione dei container di Amazon. Fornisce un modo semplice e sicuro per eseguire applicazioni containerizzate. Progettato per la semplicità, ECS riduce le decisioni dei clienti in merito a configurazioni di calcolo, rete e sicurezza senza sacrificare scalabilità o funzionalità.

Ci sono alcuni termini e componenti con cui è bene familiarizzare per ECS.

1. Cluster
2. Capacity provider
3. Task definition
4. Task
5. Service

Cluster

Un cluster ECS è composto da servizi, task e capacity provider. Contiene anche il control plane di ECS, che è gestito da AWS e non è visibile a noi.

Capacity provider

I container hanno bisogno di un server su cui essere eseguiti, che sia una macchina virtuale nel cloud o il tuo computer locale. Nel contesto di ECS, puoi selezionare il “Launch Type” per eseguire i container su Elastic Compute Cloud (EC2) o Fargate.

Scheda Infrastructure della console AWS ECS.

Task

Un task è un insieme di container in esecuzione configurati secondo una task definition. In sostanza, rappresenta un’istanza di una task definition, in modo analogo a come un container è un’istanza di un’immagine.

Task definition

Abbiamo un Dockerfile per la nostra applicazione e abbiamo creato un’immagine da esso. Abbiamo pubblicato l’immagine su un registry di container come DockerHub o AWS ECR. E ora? Procediamo a creare una task definition, ovvero una configurazione o blueprint per i nostri container (da distribuire su un cluster ECS) che include le seguenti informazioni:

• Immagini. Un task può contenere più di un’immagine.
• Il numero di porta che verrà usato per comunicare con la nostra applicazione.
• Volumi.
• Risorse (CPU e memoria) da riservare per le nostre applicazioni.

Task definition nella console AWS ECS.

Service

Cosa succede quando eseguiamo un container stand-alone e va in crash? Nulla. Rimane nello stato di crash. Questo comportamento è identico se creiamo un task stand-alone su ECS. Usiamo il servizio ECS per assicurarci che le nostre applicazioni siano sempre attive. Un servizio garantisce che un numero desiderato di task sia sempre in esecuzione.

Se un task va in crash o il server sottostante che lo ospita (e quindi il container) si interrompe, il servizio creerà un nuovo task in un capacity provider disponibile.

Implementazione di ECS

Ora che abbiamo coperto le basi di ECS, eseguiamo una semplice immagine Nginx e accediamovi. Usando il cluster ECS e la task definition sopra, creerò un servizio che fa riferimento alla task definition:

Servizi nella console AWS ECS.

Questo servizio, a sua volta, creerà un task.

Un task nella console AWS ECS.

Accesso all’indirizzo IP pubblico del task:

Accesso riuscito all’applicazione in esecuzione su ECS.

Che cos’è EKS?

Prima di entrare in Elastic Kubernetes Service (EKS), è fondamentale capire cos’è Kubernetes. Kubernetes è un motore open-source di orchestrazione dei container che automatizza il deployment, la scalabilità e la gestione delle applicazioni containerizzate. 

Per saperne di più, ti consiglio di dare un’occhiata al corso Introduction to Kubernetes. 

Tuttavia, avviare e gestire da zero un cluster Kubernetes può essere complesso e richiedere molto tempo. Molti componenti e configurazioni necessari per impostare Kubernetes sono simili tra organizzazioni e team. Per astrarre questo lavoro pesante non differenziante e semplificare l’adozione di Kubernetes, AWS ha sviluppato EKS.

EKS è un servizio Kubernetes gestito da AWS che si occupa di gran parte dell’overhead operativo. Semplifica il deployment, la scalabilità e la gestione di Kubernetes gestendo il control plane per conto degli utenti. Astrazione che elimina la necessità di gestire questi componenti, consentendo ad Amazon EKS di far concentrare gli utenti sull’esecuzione dei carichi di lavoro containerizzati e sulla gestione dei worker node o sull’uso di AWS Fargate per il computing serverless.

Questa sezione tratta brevemente EKS. Per approfondire, vedi l’articolo Fondamenti di orchestrazione dei container con AWS Elastic Kubernetes Service (EKS).

Ci sono alcuni termini e componenti con cui è bene familiarizzare per EKS:

1. Cluster (master e worker node)
2. File di manifest
3. Pod
4. ReplicaSet
5. Utility da riga di comando kubectl

Cluster

Un cluster Kubernetes è un gruppo di server o macchine virtuali su cui vengono eseguiti i carichi di lavoro Kubernetes. È composto dal master node (comunemente chiamato control plane) e dai worker node. 

In EKS, il master node è gestito da AWS nella sua VPC; per noi è astratto. Nel frattempo, possiamo gestire i worker node tramite istanze EC2 o passare al serverless con Fargate.

Connettività di rete del control plane EKS. Fonte immagine: AWS

Pod

Un pod è una risorsa dell’API Kubernetes. Sono le unità distribuibili più piccole in Kubernetes. Sono un gruppo di uno o più container e contengono specifiche sull’immagine da usare, porta, comandi, ecc.

Scheda Resources nella console AWS EKS.

ReplicaSet

Analogo a un pod, anche un ReplicaSet è una risorsa dell’API Kubernetes. Garantisce che il numero desiderato di pod sia sempre in esecuzione.

File di manifest

I file di manifest di Kubernetes sono file di configurazione usati per definire lo stato desiderato delle risorse Kubernetes in modo dichiarativo. Questi file descrivono quali risorse dovrebbero esistere in un cluster Kubernetes, le loro configurazioni e come interagiscono tra loro.

I file di manifest sono tipicamente scritti in YAML:

# pod.yml - Pod manifest
apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod
  labels:
    app: nginx
spec:
  containers:
  - name: nginx-container
    image: nginx:1.27
    ports:
    - containerPort: 80

# service.yml - Kubernetes Service manifest
apiVersion: v1
kind: Service
metadata:
  name: nginx-node-port-service
spec:
  type: NodePort 
  selector:
    app: nginx
  ports:
    - protocol: TCP
      port: 8080
      targetPort: 80
      nodePort: 31000

kubectl

Utility da riga di comando per comunicare con il cluster Kubernetes. Possiamo usare il comando kubectl per creare, gestire ed eliminare le risorse Kubernetes in modo imperativo oppure usarlo insieme ai file di manifest in modo dichiarativo.

# Create a pod that runs a container with the nginx:1.27 image
kubectl run nginx-pod --image nginx:1.27 
# Create a replicaset with 2 pods
kubectl create replicaset --replicas=2 --image nginx:1.27

Implementazione di EKS

Vediamo ora come funziona EKS eseguendo e accedendo alla stessa immagine Nginx. 

Per semplicità, creerò un’istanza EC2/worker node in una subnet pubblica, distribuirò lì l’applicazione, la esporrò tramite una risorsa Service di Kubernetes di tipo NodePort e vi accederò tramite l’IP pubblico dell’istanza. 

Userò i manifest di pod e service sopra e il comando kubectl per creare il pod:

# Update local .kube/config file
aws eks update-kubeconfig --region ap-southeast-1 --name i-love-datacamp-eks-cluster
# Create the pod
kubectl create -f pod.yml
# Create the service
kubectl create -f service.yml

Il cluster EKS ha un’istanza EC2:

Istanza EC2/worker node.

Individua l’indirizzo IPv4 pubblico dell’istanza.

L’indirizzo IP pubblico dell’istanza EC2/ worker node.

Accesso all’indirizzo IP pubblico dell’istanza con la porta 31000:

Accesso riuscito all’applicazione in esecuzione su EKS.

ECS vs. EKS: somiglianze

Ora che abbiamo coperto le basi di ECS ed EKS, possiamo vedere alcune somiglianze tra loro. Non sorprende, dato che sono entrambi strumenti di orchestrazione dei container.

Capacità di calcolo

Entrambi i servizi permettono di eseguire le applicazioni su EC2, dove gli utenti sono responsabili della manutenzione, patching e aggiornamento delle istanze EC2, oppure su AWS Fargate, l’opzione serverless in cui AWS gestisce i server sottostanti, eliminando la necessità di gestire l’infrastruttura.

Modello di gestione dei carichi di lavoro

Entrambi i servizi hanno strutture e approcci simili per gestire e mantenere le risorse delle applicazioni.

In AWS ECS, la configurazione che definisce come devono essere eseguiti i container si chiama task definition, mentre in AWS EKS questo si ottiene usando un file di manifest del pod. Una volta distribuita, l’applicazione containerizzata in ECS gira all’interno di un task, mentre in EKS gira all’interno di un pod. Per assicurare che un numero specificato di task o pod sia sempre in esecuzione, ECS usa un service, mentre EKS si affida a un replica set per questa funzionalità.

Integrazione profonda con altri servizi AWS

In quanto servizi di container su AWS, Amazon si è impegnata molto per garantire che ECS ed EKS si integrino bene con altri servizi AWS. 

Per il networking c’è Amazon VPC, che permette ai container di essere eseguiti in ambienti isolati con pieno controllo sulle configurazioni di rete, i security group e le subnet. I bilanciatori di carico per instradare il traffico ai container. 

Soluzioni come EBS, EFS e S3 sono disponibili per gestire i requisiti di storage persistente per le applicazioni containerizzate.

Entrambi i servizi usano AWS IAM per controllare in modo granulare accessi e permessi. Ciò stabilisce a quali risorse AWS l’applicazione containerizzata può accedere, come S3, DynamoDB o RDS.

Riepilogo delle principali somiglianze

ECS vs. EKS: differenze

Capire le differenze tra Amazon ECS e Amazon EKS è importante quando si sceglie tra i due. 

In questa sezione suddivideremo le loro differenze principali in termini di facilità d’uso, scalabilità, personalizzazione e costi, aiutandoti a determinare quale servizio si allinea meglio ai tuoi requisiti tecnici e obiettivi di business.

Facilità d’uso e curva di apprendimento

EKS è costruito su Kubernetes, quindi è necessaria familiarità con concetti e strumenti di Kubernetes. Di conseguenza, la curva di apprendimento per EKS sarà più ripida rispetto a ECS. Ciò implica capire come funziona il comando kubectl e alcune altre risorse di base essenziali dell’API Kubernetes, come i service (da non confondere con il termine “service” usato nel contesto di ECS), i config map, l’ingress, ecc. La sezione “Che cos’è EKS” sopra appena sfiora la superficie di ciò che offre EKS.

Sia ECS che EKS richiedono conoscenza di servizi AWS come CloudWatch, IAM, ASG, ecc. Fortunatamente, questo è tutto ciò che serve per ECS, ma non per EKS. Dunque, ECS vince in termini di facilità d’uso.

Scalabilità

Entrambi i servizi possono scalare altrettanto bene quando sono configurati correttamente. Tuttavia, il modo in cui scalano è diverso. ECS supporta l’autoscaling tramite ECS Service Auto Scaling per i task e ECS Cluster Auto Scaling per le istanze. Usa solo servizi nativi AWS come metriche CloudWatch e policy di scaling ASG.

EKS invece utilizza funzionalità di scaling native di Kubernetes, come l’Horizontal Pod Autoscaler (HPA) per i pod e il Cluster Autoscaler per le istanze. Cluster Autoscaler non è installato di default sul cluster EKS e quindi richiede all’utente di installarlo. Questo aggiunge complessità poiché è necessaria un’adeguata configurazione sia sulle risorse AWS (ad es., ruoli IAM) sia sulle risorse dell’API Kubernetes (ad es., service account) affinché il Cluster Autoscaler funzioni, il quale deve effettuare chiamate all’API AWS per scalare in e out.

Una nuova funzionalità rilasciata di recente per EKS, EKS AutoMode, può affrontare questa complessità aggiuntiva. Scarica su AWS la gestione e la scalabilità dei worker node EKS, ma comporta costi extra.

Flessibilità e personalizzazione

Come accennato, ECS è il servizio proprietario e gestito di orchestrazione dei container di Amazon, progettato per la semplicità. AWS gestisce la maggior parte delle attività di gestione del cluster, offrendo configurazioni predefinite adatte ai carichi di lavoro container comuni ma che potrebbero non soddisfare requisiti di nicchia. Pur riducendo la complessità, limita le opzioni di personalizzazione rispetto a Kubernetes.

EKS offre tutta la potenza di Kubernetes, consentendo di personalizzare deployment, scheduling dei pod, classi di storage e policy di rete in base alle esigenze. Funzionalità avanzate di orchestrazione, come le Custom Resource Definition (CRD) e gli operator, permettono una flessibilità senza pari nella progettazione delle applicazioni. 

EKS può anche essere integrato con vari strumenti e plugin open-source dell’ecosistema Kubernetes, come Prometheus, Grafana e Istio, consentendo agli sviluppatori di creare soluzioni altamente su misura. Quindi, EKS vince la sfida su flessibilità e personalizzazione.

Costo

Oltre ai costi standard per le risorse di rete (ad es., indirizzi IPv4 pubblici, NAT gateway) e le risorse di calcolo e storage (ad es., istanze EC2, Fargate e volumi EBS) che si applicano sia a ECS che a EKS, ECS ha un costo inferiore e una struttura dei costi molto più semplice.

Non ci sono addebiti per il control plane di ECS. In altre parole, se crei un cluster ECS senza alcun task in esecuzione, non sosterrai alcun costo. Nel frattempo, per EKS, ci sono costi per il control plane gestito da AWS indipendentemente dal fatto che tu abbia applicazioni in esecuzione nel cluster Kubernetes.

Il costo del control plane EKS varia in base alla versione di Kubernetes utilizzata. Una versione di Kubernetes sotto supporto standard costa 0,10 $ per cluster all’ora, mentre una sotto supporto esteso costa 0,60 $ per cluster all’ora.

Riepilogo delle principali differenze

Quando scegliere ECS?

La scelta dipende dai requisiti della tua applicazione, dagli obiettivi di business, dalle competenze del team, dal budget operativo e dalle priorità complessive.

ECS, essendo più semplice e più conveniente, è ideale per team con budget ridotti, esigenze di time-to-market più brevi e una preferenza per operazioni snelle. È particolarmente adatto per applicazioni che non richiedono portabilità tra ambienti multi-cloud o ibridi ed è progettato per essere eseguito esclusivamente su AWS. In quanto servizio specifico di AWS, ECS si allinea perfettamente ai carichi di lavoro confinati all’ecosistema AWS.

Sebbene sia ECS che EKS supportino Fargate per i deployment serverless dei container, ECS offre un’integrazione più lineare. Con ECS, puoi scegliere direttamente i task da eseguire su Fargate senza configurazioni aggiuntive. Al contrario, con EKS e Fargate è necessario specificare etichette dei pod per determinare quali carichi di lavoro debbano essere eseguiti su Fargate, aggiungendo un livello di complessità. Questo rende ECS una scelta interessante per i team che cercano un’esperienza serverless più semplice.

Quando scegliere EKS?

Kubernetes, la piattaforma alla base di EKS, è indipendente dal cloud, consentendo ai carichi di lavoro di essere eseguiti in modo coerente su AWS, altri provider cloud e ambienti on-premises. Questa portabilità è particolarmente vantaggiosa per le organizzazioni che operano in configurazioni multi-cloud o infrastrutture ibride on-premises. Anche Azure e Google Cloud offrono servizi Kubernetes gestiti — rispettivamente Azure Kubernetes Service (AKS) e Google Kubernetes Engine (GKE) — a conferma dell’ubiquità di Kubernetes negli ambienti cloud moderni.

EKS è ideale se la tua applicazione o il tuo caso d’uso richiede personalizzazione ed estensibilità avanzate. Ad esempio, Kubernetes supporta la creazione di Custom Resource Definition (CRD), che ti permettono di definire risorse personalizzate per gestire specifiche configurazioni applicative o integrare sistemi esterni. Questa flessibilità è un elemento distintivo di EKS.

Sebbene EKS astragga il control plane e si affidi ad AWS per gestirlo, operare efficacemente in un ambiente EKS richiede comunque familiarità con le risorse e i concetti dell’API Kubernetes. Pertanto, l’expertise del team su Kubernetes è cruciale per sfruttare efficacemente la piattaforma.

EKS offre anche un’ampia gamma di add-on personalizzabili che possono essere installati per estendere la funzionalità del cluster. Questi add-on facilitano il provisioning di un cluster con gli strumenti operativi necessari, semplificando la configurazione e aumentando la produttività.

Selezione degli add-on EKS.

In sintesi, EKS è adatto ad architetture a microservizi o applicazioni con numerosi componenti interconnessi che richiedono elevato controllo e granularità. È particolarmente vantaggioso per team che necessitano di opzioni di personalizzazione avanzate o operano in ambienti in cui la portabilità dei carichi di lavoro è essenziale.

Diagramma di flusso decisionale ECS vs. EKS. Immagine dell’autore.

Strumenti e integrazioni

Che si tratti di un’applicazione containerizzata o di un’applicazione in esecuzione direttamente su una VM, monitoraggio e osservabilità sono fondamentali. All’interno dell’ecosistema AWS, sia ECS che EKS possono sfruttare strumenti AWS e servizi di terze parti per migliorare l’intero ciclo di vita dello sviluppo software (SDLC) per le applicazioni containerizzate.

Monitoraggio e logging

Monitoraggio e logging sono essenziali per avere visibilità sulle tue applicazioni e sull’infrastruttura. AWS fornisce strumenti nativi e supporta integrazioni di terze parti per entrambi, come Amazon CloudWatch per metriche, log e allarmi. 

AWS X-Ray per tracciare le richieste tra microservizi semplifica l’analisi e il debug dei problemi di performance nei task ECS o nei pod EKS. Strumenti di terze parti come Datadog, Prometheus, Grafana e New Relic offrono capacità avanzate di visualizzazione e alerting pensate per i container.

Pipeline CI/CD

Le pipeline CI/CD aiutano ad automatizzare test, scan e deployment, garantendo iterazioni più rapide e minore sforzo manuale. Strumenti CI/CD popolari, come le pipeline di GitLab e GitHub Actions, si integrano con ECS ed EKS per abilitare build, test e deployment dei container. Questi strumenti lavorano con i container Docker per ECS o con le chart Helm per EKS.

Infrastructure as Code (IaC)

L’IaC è cruciale per creare infrastrutture coerenti e ripetibili, minimizzando i tempi di provisioning e riducendo il rischio di errori umani associati a configurazioni manuali tramite la AWS Management Console. 

Gli strumenti IaC più diffusi includono Terraform e AWS CloudFormation. Sebbene entrambi siano ampiamente usati, Terraform è spesso preferito per le sue capacità cloud-agnostic, che consentono ai team di gestire l’infrastruttura su più provider cloud usando un unico strumento.

Rete e sicurezza

AWS offre funzionalità robuste di rete e sicurezza sia per ECS che per EKS per garantire comunicazioni sicure e controllo degli accessi, come il networking AWS VPC per isolare le risorse in subnet private. AWS WAF e Shield: proteggono le applicazioni ospitate su ECS ed EKS da vulnerabilità web comuni e attacchi DDoS. AWS KMS per crittografare i volumi EBS e i secret di Kubernetes archiviati in etcd.

Conclusioni

ECS ed EKS sono entrambi servizi di orchestrazione dei container robusti forniti da AWS, ciascuno pensato per soddisfare esigenze applicative e priorità di team differenti. 

ECS è più semplice per iniziare, più facile da effettuare il provisioning, distribuire e mantenere, e ha costi operativi inferiori. Al contrario, EKS ha una curva di apprendimento più ripida e una complessità iniziale maggiore, ma offre flessibilità senza pari e opzioni avanzate di personalizzazione, rendendolo ideale per team con requisiti specializzati o complessi. 

La scelta tra ECS ed EKS dipende dalle esigenze della tua applicazione, dalle competenze del team e dal bilanciamento desiderato tra semplicità e controllo.

Se vuoi rafforzare le tue conoscenze su AWS, il corso AWS Concepts è un ottimo punto di partenza. Per approfondire gli strumenti e le tecnologie AWS, dai un’occhiata al corso AWS Cloud Technology and Services. Inoltre, per chi è interessato a padroneggiare la containerizzazione, il percorso Containerization and Virtualization offre spunti preziosi per eccellere nella gestione e distribuzione dei container.