Module 5 · Cloud provider - AWS EKS¶

Objectifs

Comprendre ce qu'apporte un cluster managé (EKS) vs un cluster « à la main ».
Provisionner un cluster EKS avec eksctl.
Configurer node groups, IAM/IRSA, LoadBalancer, autoscaling.
Détruire proprement pour maîtriser le coût.
Durée : ~1 h (time-boxé : on provisionne et on détruit dans la même séance) · Pré-requis : Module 4t - Diagnostiquer.

💸 Ce module coûte de l'argent

EKS est facturé (~0,10 $/h le control plane + le coût des nœuds EC2 + le LoadBalancer). Règle d'or : on provisionne en début de session, on détruit en fin de session. Le kit cloud/aws/ fournit up.sh / down.sh exactement pour ça.

Pourquoi pas de TP auto-corrigé ici ?

Les TP tp start … se valident dans ta sandbox ; ce module se joue hors sandbox, sur un vrai compte AWS (facturé, time-boxé). Le module entier est le TP : le kit cloud/aws/ sert de fil rouge, et la checklist de destruction ci-dessous tient lieu de validation - avec le mentor.

Managé vs auto-géré¶

	k3s/kubeadm (toi-même)	EKS (AWS managé)
Control plane	À toi de l'installer/maintenir	AWS le gère (HA, patches)
Coût	Prix des VMs	Control plane + nodes + LB
Mise en place	Longue	`eksctl` en ~15 min
Intégrations cloud	À faire	LB, EBS, IAM natifs

Le k8s reste le même

Tout ce que tu as appris - Pods, Deployments, Services, debug - marche à l'identique sur un cluster managé. Ce qui change, c'est l'intégration cloud : le LoadBalancer, le stockage (EBS), l'IAM, l'autoscaling. Le reste est transposable tel quel.

Pré-requis (à installer une fois)¶

aws --version          # AWS CLI v2
eksctl version         # https://eksctl.io
kubectl version --client
# Authentification
aws configure          # access key / secret / région (ex: eu-west-3 Paris)
aws sts get-caller-identity   # vérifie que tu es bien authentifié

Compte AWS

Utilise un compte/sandbox dédié (idéalement avec un budget AWS et une alerte de coût). Jamais un compte de prod. On configure une AWS Budgets alert avant de démarrer.

Provisionner avec eksctl¶

Le kit fournit cloud/aws/cluster.yaml. Création :

eksctl create cluster -f cluster.yaml
# ou en one-liner pour comprendre les options :
eksctl create cluster \
  --name mentorat \
  --region eu-west-3 \
  --nodes 2 \
  --node-type t3.small \
  --managed

eksctl crée en réalité : un VPC, des subnets, le control plane EKS, un node group (EC2), et configure ton kubeconfig. Observe-le ensuite avec k9s :

k9s            # :nodes → tes nœuds EC2 ; :ns → namespaces AWS (kube-system, etc.)

Node groups & autoscaling¶

Un node group = un ensemble de nœuds EC2 homogènes (type, taille, scaling).
Managed node group : AWS gère le cycle de vie (upgrades, drain).
Cluster Autoscaler / Karpenter : ajoutent/retirent des nœuds selon la charge.

Exercice 5.1 - Scaler le node group

eksctl scale nodegroup --cluster mentorat --name ng-1 --nodes 3

Observe dans k9s (:nodes) l'apparition du 3ᵉ nœud, puis reviens à 2.

IAM & IRSA (le concept clé d'EKS)¶

IRSA (IAM Roles for Service Accounts) lie un ServiceAccount Kubernetes à un rôle IAM AWS. → un pod obtient des droits AWS (lire un bucket S3, etc.) sans clé statique.

eksctl utils associate-iam-oidc-provider --cluster mentorat --approve
eksctl create iamserviceaccount \
  --cluster mentorat --namespace default --name s3-reader \
  --attach-policy-arn arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess --approve

Le lien avec le RBAC du module 4

RBAC = droits dans Kubernetes. IRSA/IAM = droits vers AWS. Les deux se combinent : un SA a un Role k8s (RBAC) et un rôle IAM (IRSA).

LoadBalancer & exposition¶

Créer un Service type: LoadBalancer sur EKS provisionne un ELB/NLB AWS automatiquement :

kubectl create deployment web --image nginx:1.27-alpine
kubectl expose deployment web --port 80 --type LoadBalancer
kubectl get svc web        # EXTERNAL-IP = DNS du load balancer AWS

Ça crée une vraie ressource facturée

Supprime le Service LoadBalancer avant de détruire le cluster, sinon l'ELB peut rester.

Le contraste avec ta sandbox

En sandbox, ce même Service restait <pending> : aucun fournisseur de LB. Sur EKS, la différence tient au cloud-controller-manager, qui provisionne l'ELB automatiquement. En bare-metal, on obtient le même résultat avec MetalLB - pas de magie cloud, juste un composant installé qui répond à la demande d'IP.

🔥 Détruire (obligatoire en fin de session)¶

# 1) Supprimer les Services LoadBalancer (ELB facturés)
kubectl delete svc --all-namespaces --field-selector spec.type=LoadBalancer
# 2) Détruire le cluster et tout son VPC
eksctl delete cluster --name mentorat --region eu-west-3

Puis vérifier dans la console AWS : aucun cluster EKS, aucun ELB orphelin, aucun EC2 actif.

Ce qu'il faut retenir¶

EKS = Kubernetes managé : AWS tient le control plane, toi les workloads.
eksctl = provisioning déclaratif (VPC + EKS + node group) en une commande.
IRSA relie ServiceAccount k8s ↔ rôle IAM AWS, sans clé statique.
type: LoadBalancer → ELB AWS automatique.
Toujours eksctl delete cluster en fin de session. Coût maîtrisé = mentorat serein.

Quiz éclair¶

Teste-toi : réponds de tête, puis déplie.

1. Dans EKS, qu'est-ce qu'AWS gère à ta place ?

Le control plane (API server, etcd, scheduler) en HA, avec les patches. Toi, tu gères les workloads et (selon le mode) les nodes.

2. À quoi sert IRSA ?

À relier un ServiceAccount Kubernetes à un rôle IAM AWS : un pod obtient des droits AWS (ex. lire un bucket S3) sans clé statique.

3. Quel est le réflexe coût en fin de session ?

Supprimer les Services LoadBalancer (ELB facturés), puis eksctl delete cluster, et vérifier dans la console AWS qu'il ne reste ni ELB ni EC2 orphelins.

➡️ Suite : Module 6 - Mise en situation