Skip to content
Learni
View all tutorials
Cloud & DevOps

Comment maîtriser Amazon EKS en 2026

Introduction

Amazon EKS (Elastic Kubernetes Service) est le service managé de Kubernetes par AWS, lancé en 2018 et évolué jusqu'en 2026 avec des intégrations natives comme Karpenter pour l'auto-scaling avancé et Bottlerocket pour des nœuds sécurisés. Contrairement à un cluster Kubernetes auto-géré (self-managed), EKS gère le plan de contrôle (control plane) haute disponibilité sur trois AZ minimum, libérant les équipes DevOps de tâches comme les upgrades Kubernetes ou les certificats.

Pourquoi c'est crucial en 2026 ? Avec l'essor des workloads IA/ML et edge computing, EKS supporte désormais EKS Anywhere pour on-prem et Fargate pour serverless pods, réduisant les coûts TCO de 40-60% via Spot Instances optimisées. Imaginez un orchestre : AWS est le chef (control plane), vous gérez les musiciens (workers). Ce tutoriel conceptuel INTERMEDIATE décortique l'architecture, le networking, la sécurité et le scaling sans une ligne de code, pour que vous puissiez architecturer un cluster production-ready. (148 mots)

Prérequis

  • Connaissances solides en Kubernetes (pods, deployments, services, namespaces).
  • Familiarité avec AWS : VPC, IAM, EC2, ELB.
  • Compréhension des concepts networking : CIDR, subnets, security groups.
  • Expérience en DevOps : CI/CD, monitoring, scaling horizontal.

1. Comprendre l'architecture EKS

Le control plane EKS : AWS provisionne un cluster API server HA sur 3 AZ, avec étalement temporel des upgrades (cordon/drain des nœuds). Exemple concret : un cluster de 10 nœuds gère 1000 pods ; EKS assure 99.95% SLA sans downtime.

Composants workers : Node Groups (gérés via ASG EC2) vs Fargate (serverless). Node Groups pour workloads CPU/GPU custom (ex: ML training sur P4 instances) ; Fargate pour burst traffic sans provisionner EC2.

Analogie : Comme un data center virtuel, où VPC est le câblage, subnets les racks, et security groups les serrures. En 2026, EKS intègre nativement AWS Nitro Enclaves pour confidential computing.

Étude de cas : Une fintech déploie EKS pour microservices ; control plane scalé à 5000 pods via managed add-ons comme CoreDNS auto-scalé.

2. Configurer le networking VPC

VPC CNI (Container Network Interface) : Plugin AWS pour pods avec IP ENI (Elastic Network Interface), supportant jusqu'à 250 IP/pod en 2026. Évitez le prefix delegation pour IPv6 hybride.

Subnets et routage : Toujours 3 subnets privés par AZ (ex: /24 CIDR par AZ pour 251 hosts). Public subnets pour ALB Ingress. Routage via NAT Gateway pour outbound traffic.

Exemple concret : Cluster en VPC 10.0.0.0/16 ; subnets 10.0.1.0/24 (AZ1), 10.0.2.0/24 (AZ2), 10.0.3.0/24 (AZ3). Security groups : allow 443/6443 inbound au control plane.

Checklist networking :

  • Activer IMDSv2 sur nœuds pour sécurité.
  • Utiliser AWS Load Balancer Controller pour NLB/ALB.
  • Limiter ENI quotas à 30/pod pour éviter throttling.

3. Gérer les nœuds et le scaling

Node Groups : Managed (ASG + AMI optimisée) vs Self-Managed. En 2026, Bottlerocket OS remplace Amazon Linux 2 pour immutabilité (read-only rootfs).

Cluster Autoscaler vs Karpenter : CA scale ASG sur CPU/Memory ; Karpenter (natif EKS) provisionne Spot Instances just-in-time, réduisant coûts de 70%. Ex: Pod pending → Karpenter lance t3.medium Spot en 30s.

Fargate Profiles : Sélection par namespace/label ; idéal pour dev/test (pay-per-pod).

Exemple : Politique scaling : min 3 nœuds, max 20, desired 6 ; HPA sur deployments (target 70% CPU). Étude de cas : E-commerce Black Friday scale de 10 à 100 nœuds sans intervention.

4. Sécuriser le cluster EKS

IAM Roles for Service Accounts (IRSA) : Lie IAM roles à Kubernetes SA ; ex: pod S3 access via OIDC provider sans keys statiques.

Pod Security Standards : Enforce baseline (no root, no hostPath) via admission controllers.

Network Policies + Security Groups for Pods : Calico/Cilium pour L7 policies ; sgpod pour granularité EC2-like.

Exemple concret : Namespace 'prod' avec IRSA pour RDS access ; policy deny-all + allow 80/443 inter-pods. En 2026, EKS Private Clusters cachent control plane derrière VPC endpoints.

Checklist sécurité :

  • Activer EKS Audit Logs vers CloudTrail.
  • Utiliser Kyverno/Gatekeeper pour OPA policies.
  • Rotate kubeconfig tokens via EKS Access Entries.

5. Monitoring et observabilité

CloudWatch Container Insights : Métriques pods/nœuds (CPU, memory, network) + logs FluentBit.

Prometheus + Grafana : Via Amazon Managed Grafana ; scrape via ServiceMonitor CRDs.

Exemple : Alerte sur 80% memory pod → autoscaler trigger. X-Ray pour tracing services mesh (App Mesh).

Étude de cas : Banque monitore 500 pods ; anomaly detection via CloudWatch Anomaly Detection prédit outages 24h avant.

Bonnes pratiques

  • Multi-AZ always : 3+ AZ pour HA ; testez chaos engineering avec AWS Fault Injection.
  • IRSA everywhere : Zéro access keys ; utilisez least-privilege via IAM Access Analyzer.
  • Immutable infrastructure : Bottlerocket + rolling upgrades (maxUnavailable 25%).
  • Cost optimization : 70% Spot + Savings Plans ; tag tout pour Cost Explorer.
  • GitOps workflow : Flux/ArgoCD pour declarative deployments.

Erreurs courantes à éviter

  • VPC mal dimensionnée : CIDR trop petit → IP exhaustion ; toujours planifiez 65k+ IP/cluster.
  • IAM sur-privileges : ClusterRole admin à tous → utilisez RBAC + OIDC.
  • Scaling réactif seulement : Sans VPA (Vertical Pod Autoscaler), pods OOMKilled fréquents.
  • Logs non centralisés : Sans FluentBit → debugging impossible ; configurez dès le jour 1.

Pour aller plus loin

Plongez dans les docs officielles AWS EKS. Explorez EKS Blueprints pour Terraform. Pour une maîtrise experte, inscrivez-vous à nos formations Learni DevOps AWS couvrant EKS + Karpenter hands-on. Rejoignez la communauté CNCF pour Kubernetes best practices.