Kubernetes et l'orchestration de conteneurs
Kubernetes résout un problème précis : coordonner l'exécution de conteneurs sur un ensemble de machines de façon fiable, scalable et auto-réparatrice. Docker répond à la question "comment empaqueter et faire tourner une application". Kubernetes répond à la question "comment en faire tourner des centaines, sur des dizaines de noeuds, sans interruption de service".
Pourquoi Kubernetes
Un conteneur unique sur un hôte unique est trivial. Les problèmes émergent à l'échelle :
- Placement : sur quel noeud lancer ce conteneur, en fonction des ressources disponibles ?
- Résilience : que faire si un noeud tombe ? si un conteneur plante ?
- Scaling : comment passer de 2 à 20 replicas en fonction de la charge ?
- Mise à jour : comment déployer une nouvelle version sans coupure ?
- Réseau : comment les services se découvrent-ils et communiquent-ils entre eux ?
- Configuration et secrets : comment injecter la config sans la cuire dans l'image ?
Kubernetes répond à chacun de ces problèmes avec des abstractions stables et composables.
Kubernetes vs Docker Swarm
Docker Swarm est plus simple à opérer, intégré nativement à Docker. Kubernetes est plus complexe, mais offre un écosystème incomparablement plus riche. En 2024, Swarm a perdu la bataille de l'adoption en production. Les outils, les opérateurs, les certifications, les offres managées (EKS, GKE, AKS) sont tous centrés sur Kubernetes.
Pour un ingénieur DevOps, Kubernetes est devenu incontournable — pas parce qu'il est toujours le bon outil, mais parce que le marché l'a adopté comme standard de fait.
Historique et gouvernance
Kubernetes naît chez Google en 2014, inspiré de Borg, le système interne d'orchestration de Google. Il est donné à la CNCF (Cloud Native Computing Foundation) en 2016. La gouvernance est ouverte : le projet publie une version mineure tous les quatre mois environ. Kubernetes 1.35 sort en 2025.
La CNCF héberge l'écosystème autour : Helm, Prometheus, ArgoCD, Cilium, Falco, Velero... Ces projets sont indépendants mais conçus pour fonctionner avec Kubernetes.
Concepts clés avant de commencer
- Cluster : ensemble de noeuds (machines) gérés par Kubernetes
- Control Plane : cerveaux du cluster — API server, scheduler, etcd, controller manager
- Node : machine (VM ou physique) qui exécute les charges de travail
- Pod : unité minimale de déploiement — un ou plusieurs conteneurs co-localisés
- Workload : abstraction au-dessus des pods — Deployment, StatefulSet, DaemonSet...
- Service : point d'accès stable vers un ensemble de pods
- Namespace : partition logique du cluster (isolation, quotas, RBAC)
Le modèle déclaratif
Kubernetes fonctionne en mode déclaratif : on décrit l'état désiré (spec), le système converge vers cet état et le maintient. On ne dit pas "lance ce conteneur" — on dit "il doit y avoir 3 replicas de ce pod en permanence". Si un replica meurt, Kubernetes en recrée un. Si un noeud est retiré, les pods sont re-schedulés ailleurs.
Ce modèle de réconciliation en boucle est le coeur de Kubernetes. Tout le reste en découle.