AWS EKS — Cheat Sheet

Tag: aws, eks, kubernetes, containers, fargate, ec2, devops

Livello: intermedio

TL;DR: Servizio gestito Kubernetes di AWS. Delega ad AWS la gestione, scalabilità e alta affidabilità del control plane, lasciando all'utente la gestione dei worker node.

Concetti chiave

-

EKS gestisce il control plane Kubernetes distribuendolo automaticamente su più Availability Zone (AZ).

-

I worker node possono essere istanze EC2 (Managed Node Groups) o nodi serverless (AWS Fargate).

-

L'integrazione con AWS IAM avviene tramite OIDC, permettendo di assegnare ruoli IAM ai ServiceAccount (IRSA).

-

Utilizza il plugin AWS VPC CNI: i pod ricevono indirizzi IP nativi direttamente dalla subnet del VPC.

-

Gli aggiornamenti di versione non sono completamente automatici: richiedono l'upgrade esplicito del control plane e poi dei nodi.

-

Componenti base come kube-proxy, CoreDNS e VPC CNI sono gestiti come EKS Add-ons.

-

L'accesso iniziale al cluster è garantito all'identità IAM che ha creato il control plane.

-

L'autenticazione kubectl si appoggia ad AWS CLI per generare token temporanei tramite il comando get-token.

Domande tipiche e risposte pronte

-

Q: Qual è la differenza tra usare EKS con EC2 e con Fargate?R: Con EC2 controllo i nodi, l'OS e posso eseguire DaemonSet o container privilegiati. Fargate è serverless: niente nodi da gestire, niente DaemonSet, pago solo le risorse dei pod.

-

Q: Come assegni permessi AWS specifici (es. accesso a S3) a un singolo pod?R: Utilizzo IRSA (IAM Roles for Service Accounts). Associo un ServiceAccount Kubernetes a un IAM Role tramite provider OIDC, evitando di assegnare permessi troppo ampi all'intero nodo EC2.

-

Q: Come si gestisce l'aggiornamento di versione in EKS?R: Aggiorno prima il control plane alla nuova versione. Poi aggiorno i componenti aggiuntivi (Add-ons) e infine ruoto i Managed Node Group per aggiornare i kubelet.

-

Q: Come si autorizza un nuovo sviluppatore ad accedere al cluster tramite kubectl?R: Mappo il suo utente o ruolo IAM all'interno della ConfigMap aws-auth (o tramite le EKS Access Entries), assegnandogli i gruppi RBAC di Kubernetes necessari.

Insidie e errori comuni

-

Esaurimento degli indirizzi IP nella subnet a causa del VPC CNI, poiché ogni pod consuma un IP reale del VPC.

-

Dimenticare di aggiornare le versioni degli EKS Add-ons (VPC CNI, CoreDNS, kube-proxy) dopo aver aggiornato il control plane.

-

Modificare in modo errato la ConfigMap aws-auth, perdendo i permessi di accesso al cluster per interi team o servizi.

-

Uso di Fargate senza configurare correttamente i Fargate Profiles: i pod rimangono in stato Pending.

Snippet e comandi

# Generare/aggiornare il kubeconfig per un cluster EKS
aws eks update-kubeconfig --region eu-west-1 --name mio-cluster

# Creare un cluster con eksctl fornendo un file di configurazione
eksctl create cluster -f cluster.yaml

# Visualizzare le identità IAM mappate (se si usa aws-auth)
kubectl get configmap aws-auth -n kube-system -o yaml

Da ripassare

-

[ ] Dettagli della gestione IP secondari di VPC CNI con Custom Networking

-

[ ] Nuova gestione degli accessi tramite EKS Access Entries vs ConfigMap aws-auth

Riferimenti

-

AWS EKS Official Documentation

-

eksctl Documentation

Jarvis Interviews
Jarvis