Profili Fargate per pod serverless

AWS Fargate per EKS consente di eseguire pod Kubernetes senza effettuare il provisioning o gestire nodi EC2. Invece di occuparsi dei tipi di istanza e dei gruppi di nodi, si definisce un profilo Fargate che indica a EKS quali pod devono essere eseguiti su Fargate, in base al relativo namespace e agli eventuali selettori di etichette. AWS effettua automaticamente il provisioning della quantità di risorse di calcolo appropriata per ogni pod e la rilascia quando il pod viene arrestato.

Un profilo Fargate è associato a un cluster EKS e contiene uno o più selettori; ogni selettore specifica un namespace e, facoltativamente, coppie chiave-valore di etichette Kubernetes. Per essere pianificato su Fargate, un pod deve corrispondere ad almeno un selettore. Il profilo specifica anche il ruolo di esecuzione del pod (un ruolo IAM) e le subnet private che Fargate deve utilizzare per avviare i pod.

Il ruolo di esecuzione del pod è un ruolo IAM che EKS assume quando Fargate recupera le immagini dei container e invia i log dei pod a CloudWatch. Deve includere la policy gestita da AWS AmazonEKSFargatePodExecutionRolePolicy. Senza questo ruolo, l'avvio dei pod pianificati su Fargate non riuscirà, perché Fargate non può autenticarsi a ECR né scrivere nei CloudWatch Logs.

Fargate impone importanti restrizioni sui namespace. Il namespace kube-system non è disponibile per la maggior parte dei profili Fargate, perché vi vengono eseguiti pod di sistema come kube-proxy. Un'eccezione è CoreDNS: AWS offre una procedura guidata per applicare una patch al deployment CoreDNS e rimuovere l'annotazione eks.amazonaws.com/compute-type: ec2, in modo che possa essere eseguito su Fargate. I pod nei namespace esclusi rimarranno non pianificati se non sono disponibili nodi EC2.

Fargate assegna le risorse di calcolo in base alle richieste di CPU e memoria definite nella specifica del pod. Arrotonda i valori alla combinazione di vCPU e memoria Fargate supportata immediatamente superiore (ad esempio, da 0,25 vCPU / 0,5 GB fino a 16 vCPU / 120 GB). Il costo viene calcolato solo sulle risorse assegnate, al secondo, per il periodo di esecuzione del pod. Imposti sempre richieste di risorse accurate: richieste inferiori al necessario causano terminazioni per esaurimento della memoria, mentre richieste eccessive aumentano i costi.

Fargate elimina la gestione dei nodi, ma presenta alcune limitazioni: nessun DaemonSet (poiché non esistono nodi persistenti su cui pianificarli), nessun container privilegiato e supporto limitato per alcuni tipi di storage. I gruppi di nodi EC2 supportano GPU, kernel personalizzati e carichi di lavoro stateful con unità NVMe locali. Un modello comune consiste nell'eseguire i servizi stateless su Fargate e i carichi di lavoro stateful o basati su GPU su gruppi di nodi EC2 dedicati all'interno dello stesso cluster EKS.

Ogni pod Fargate riceve una propria interfaccia di rete elastica (ENI) e un indirizzo IP privato dalla subnet specificata nel profilo. È quindi possibile applicare un gruppo di sicurezza univoco a ogni pod utilizzando la funzionalità Security Groups for Pods. I pod Fargate supportano tutte le regole standard dei gruppi di sicurezza VPC, offrendo un controllo dettagliato del traffico in entrata e in uscita a livello del singolo pod, un vantaggio significativo in termini di sicurezza rispetto ai gruppi di sicurezza condivisi a livello di nodo.

I pod Fargate inviano i log ad Amazon CloudWatch Logs utilizzando il router di log Fluent Bit integrato. Il logging si configura creando una ConfigMap denominata aws-logging nel namespace aws-observability. Il ruolo di esecuzione del pod deve disporre dell'autorizzazione per creare gruppi di log e scrivere eventi di log. I log vengono organizzati in gruppi di log CloudWatch per cluster e namespace, semplificando l'aggregazione centralizzata dei log senza dover eseguire un agente di log separato.

Fargate supporta il Horizontal Pod Autoscaler (HPA) di Kubernetes. Quando HPA aumenta il numero di repliche, Fargate effettua automaticamente il provisioning di nuove micro-VM, senza che sia necessario modificare le dimensioni dei gruppi di nodi. Si ottiene così un'esperienza di autoscaling realmente serverless: HPA controlla il numero di pod e Fargate gestisce elasticamente le risorse di calcolo. È comunque necessario che nel cluster sia distribuito il Metrics Server, affinché HPA possa leggere l'utilizzo di CPU e memoria.

Fargate viene addebitato in base ai secondi-vCPU e ai secondi-GB consumati, con un minimo di 1 minuto per pod. Non sono previsti costi a livello di nodo, addebiti per capacità riservata né costi per l'applicazione di patch ad AMI o sistemi operativi. In genere, Fargate è più costoso per unità di calcolo rispetto alle istanze EC2 on demand correttamente dimensionate, ma il costo totale di proprietà è spesso inferiore se si considera il tempo degli ingegneri risparmiato nella gestione dei nodi, nell'applicazione delle patch e nelle decisioni di dimensionamento.

Limitazioni importanti di Fargate per l'esame SAA-C03: nessun supporto per DaemonSet (i pod non possono essere posizionati su ogni nodo perché non esistono nodi persistenti), nessun container privilegiato, modalità hostNetwork non supportata e storage effimero limitato a 20 GB per pod (espandibile a 200 GB tramite una configurazione). Lo storage a blocchi persistente con EBS non è supportato: utilizzi EFS per lo storage di file persistente condiviso con i pod Fargate.

In questa lezione ha imparato che: i profili Fargate utilizzano selettori di namespace ed etichette per pianificare i pod in modalità serverless, il ruolo di esecuzione del pod concede a Fargate l'autorizzazione per recuperare le immagini e scrivere i log, e Fargate non supporta DaemonSet né EBS; utilizzi EFS per lo storage persistente. Ora esamineremo il networking EKS con il plugin VPC CNI e AWS Load Balancer Controller.