Piano di controllo e nodi di lavoro EKS

Amazon Elastic Kubernetes Service (EKS) è un servizio Kubernetes completamente gestito che elimina l'onere di installare, gestire e mantenere il control plane di Kubernetes. AWS esegue, adatta e aggiorna il control plane in più Availability Zone, fornendo un endpoint del cluster altamente disponibile. Lei si concentra interamente sul deployment e sulla gestione dei carichi di lavoro dell'applicazione.

Il control plane di EKS è costituito dal server API, da etcd, dal controller manager e dallo scheduler, tutti gestiti da AWS. Questi componenti vengono eseguiti in account di proprietà di AWS, quindi non vi accede mai tramite SSH. AWS garantisce uno SLA del 99,95% per l'endpoint API di EKS e sostituisce automaticamente i nodi non integri del control plane. Per il control plane paga una tariffa fissa per cluster e per ora.

Può creare un cluster EKS usando la Console AWS, eksctl o CloudFormation. Il cluster richiede una VPC con subnet distribuite in almeno due AZ e un ruolo IAM che conceda al control plane di Kubernetes l'autorizzazione a chiamare le API AWS. Una volta creato, l'endpoint del cluster è un URL HTTPS che configura nel suo kubeconfig.

Dopo aver creato il cluster, aggiorni il suo kubeconfig locale affinché kubectl sappia come raggiungere il server API di EKS. AWS CLI genera automaticamente la voce necessaria. Il server API di EKS utilizza AWS IAM per l'autenticazione: l'utente o il ruolo IAM viene associato a un'identità Kubernetes RBAC tramite il ConfigMap aws-auth.

I managed node group consentono ad AWS di effettuare il provisioning, registrare e gestire il ciclo di vita dei nodi worker EC2 per suo conto. Quando richiede un aggiornamento o una sostituzione, EKS esegue automaticamente il draining dei pod, sostituisce l'istanza e la registra nuovamente, senza intervento manuale. I managed node group utilizzano gli Auto Scaling Group in background, offrendo il controllo della capacità minima, massima e desiderata e l'integrazione con Cluster Autoscaler.

Con i self-managed node group avvia personalmente le istanze EC2 (tramite CloudFormation o Terraform) e le registra nel cluster EKS eseguendo lo script di bootstrap. Questo offre la massima flessibilità: può utilizzare AMI personalizzate, tipi di istanza GPU o configurazioni del kernel altamente personalizzate; tuttavia, è interamente responsabile dell'applicazione delle patch, del draining e della sostituzione dei nodi.

Ogni nodo worker deve essere eseguito con un profilo dell'istanza EC2 che disponga di tre policy gestite da AWS: AmazonEKSWorkerNodePolicy, AmazonEKS_CNI_Policy e AmazonEC2ContainerRegistryReadOnly. Queste consentono al nodo di unirsi al cluster, gestire il networking dei pod con il plugin VPC CNI e scaricare le immagini da ECR. Senza queste policy, i nodi non riusciranno a registrarsi.

EKS utilizza il ConfigMap aws-auth nel namespace kube-system per associare utenti e ruoli IAM a nomi utente e gruppi Kubernetes. Quando crea un cluster, solo l'identità IAM del creatore riceve automaticamente l'accesso amministrativo. Per consentire ad altri utenti o ruoli CI/CD di accedere al cluster, deve aggiungere le voci appropriate a questo ConfigMap usando le chiavi mapRoles o mapUsers.

Gli add-on EKS sono componenti software selezionati e convalidati da AWS, come VPC CNI, CoreDNS e kube-proxy, che EKS può installare e mantenere aggiornati per suo conto. Quando aggiorna la versione Kubernetes del cluster, aggiorni prima il control plane e poi ciascun managed node group alla versione corrispondente. EKS supporta una differenza di versione minor N-1 tra control plane e nodi durante la finestra di rollout.

L'endpoint del server API di EKS può essere configurato come solo pubblico, solo privato oppure in entrambe le modalità. Gli endpoint pubblici sono protetti dall'autenticazione IAM; gli endpoint solo privati richiedono che il suo kubeconfig raggiunga la VPC tramite VPN o Direct Connect. Può inoltre abilitare la crittografia envelope dei secret Kubernetes inattivi usando una chiave AWS KMS, fornendo un ulteriore livello di protezione per i dati di configurazione sensibili.

Il Cluster Autoscaler è un pod Kubernetes che monitora i pod non schedulabili e adatta automaticamente le dimensioni degli Auto Scaling Group dei managed node group. Quando i pod non possono essere pianificati a causa di risorse insufficienti, Cluster Autoscaler esegue lo scale-up. Quando i nodi sono sottoutilizzati e i relativi pod possono essere ripianificati altrove, esegue lo scale-down. Sono necessarie autorizzazioni IAM per chiamare l'API EC2 Auto Scaling tramite IRSA.

Verifichi la sua comprensione dei concetti AWS Solutions Architect (SAA-C03) trattati in questa lezione.

In questa lezione ha imparato che: AWS gestisce il piano di controllo EKS con uno SLA del 99,95%, i gruppi di nodi gestiti consentono ad AWS di gestire il ciclo di vita dei nodi, mentre i gruppi autogestiti offrono la massima personalizzazione, e la ConfigMap aws-auth associa le identità IAM a Kubernetes RBAC per il controllo degli accessi al cluster. Ora esamineremo i profili Fargate per l'esecuzione serverless dei pod.