Qu'est-ce que Kubernetes et pourquoi l'avoir adopté ?
Kubernetes, souvent abrégé en K8s, est un système open source d'orchestration de conteneurs, initialement développé par Google sur la base de son outil interne Borg. En 2026, il s'est imposé comme le standard de facto pour la gestion des applications conteneurisées en production.
Imaginez que vous déployez une application avec Docker Compose sur un serveur. Tant que vous avez un seul serveur et une charge modérée, cela fonctionne. Mais dès que vous devez gérer plusieurs machines, assurer la haute disponibilité, répartir la charge entre les instances, mettre à jour sans interruption de service ou redémarrer automatiquement un conteneur défaillant, les limites apparaissent rapidement. C'est précisément le problème que Kubernetes résout.
L'adoption de Kubernetes dans les entreprises françaises a connu une croissance significative depuis 2024. Selon le rapport Cloud Native Computing Foundation (CNCF) de 2025, 71 % des organisations interrogées utilisent désormais Kubernetes en production, contre 56 % en 2023.
Les concepts fondamentaux à maîtriser
Kubernetes repose sur un petit nombre de concepts clés. Leur compréhension est indispensable avant d'aborder la pratique.
Le Pod
Le Pod est la plus petite unité déployable dans Kubernetes. Il contient un ou plusieurs conteneurs qui partagent le même réseau et le même espace de stockage. En pratique, on place un seul conteneur par Pod dans la majorité des cas, sauf pour des motifs spécifiques comme les side-cars de logging ou de monitoring.
Le Service
Un Service est une abstraction qui expose une application exécutée sur un ensemble de Pods. Les Pods sont éphémères : ils peuvent mourir et être recréés avec une nouvelle adresse IP. Le Service fournit une adresse et un nom stables, ainsi qu'un équilibrage de charge entre les Pods.
Le Deployment
Un Deployment décrit l'état désiré de votre application : combien de réplicas, quelle image de conteneur, quelle stratégie de mise à jour. Kubernetes se charge de faire converger l'état réel vers l'état désiré, en créant ou supprimant des Pods si nécessaire. C'est avec les Deployments que l'on pilote les mises à jour sans interruption de service (rolling updates).
Le Namespace
Les Namespaces permettent de partitionner un cluster Kubernetes en environnements virtuels isolés. Cela s'avère utile pour séparer les environnements de développement, de test et de production sur un même cluster, ou pour isoler les équipes.
Architecture d'un cluster Kubernetes
Un cluster Kubernetes se compose de deux grandes catégories de machines : le plan de contrôle (control plane) et les nœuds de travail (worker nodes).
Le plan de contrôle prend les décisions globales : ordonnancement des Pods, détection des événements, réponse aux changements. Il comprend plusieurs composants :
- kube-apiserver : la porte d'entrée du cluster, via laquelle toutes les opérations transitent
- etcd : la base de données clé-valeur qui stocke l'état du cluster
- kube-scheduler : décide sur quel nœud chaque nouveau Pod doit être placé
- kube-controller-manager : exécute les boucles de contrôle qui maintiennent l'état désiré
Les nœuds de travail, quant à eux, exécutent les Pods. Chaque nœud embarque le kubelet (agent qui communique avec le plan de contrôle), le kube-proxy (gestion du réseau) et le runtime de conteneurs (Docker, containerd, etc.).
Cette architecture peut sembler complexe au premier abord, mais elle apporte une robustesse éprouvée : un cluster standard peut supporter des centaines de nœuds sans dégradation des performances.
Quand utiliser Kubernetes plutôt que Docker Compose ?
Le choix entre Docker Compose et Kubernetes dépend essentiellement de l'échelle de votre infrastructure.
| Critère | Docker Compose | Kubernetes |
|---|---|---|
| Nombre de machines | 1 serveur | Plusieurs (cluster) |
| Haute disponibilité | Non natif | Inclus |
| Mise à jour continue | Manuelle | Rolling update |
| Auto-réparation | Non | Oui |
| Équilibrage de charge | Basique | Avancé |
| Montée en charge | Limitée | Auto-scaling |
| Courbe d'apprentissage | Faible | Élevée |
La recommandation des équipes DevOps expérimentées est claire : commencez par Docker Compose tant que votre architecture tient sur un seul serveur. Migrez vers Kubernetes lorsque vous atteignez les limites de la machine unique.
Premiers pas avec Minikube et kubectl
Pour débuter sans avoir besoin d'un cluster cloud, Minikube est l'outil idéal : il crée un cluster Kubernetes local avec un seul nœud, dans une machine virtuelle ou un conteneur.
Voici les commandes essentielles :
# Démarrer un cluster local
minikube start --driver=docker
# Vérifier l'état
kubectl cluster-info
# Lister les nœuds
kubectl get nodes
# Déployer
kubectl create deployment nginx --image=nginx:alpine
# Exposer
kubectl expose deployment nginx --port=80 --type=LoadBalancer
# Voir les Pods
kubectl get pods
# Voir les Services
kubectl get svc
# Accéder
minikube service nginx
La force de l'outil réside dans sa cohérence : les mêmes commandes fonctionnent sur Minikube, GKE, EKS, AKS ou un cluster on premise.
Une fois ces bases acquises, l'étape suivante consiste à découvrir les manifests YAML, qui permettent de décrire l'état désiré de votre infrastructure de manière déclarative.
FAQ
Kubernetes est-il réservé aux grandes entreprises ?
Non. Des solutions comme Minikube, K3s ou les clusters managés cloud le rendent accessible même aux équipes de deux ou trois développeurs.
Faut-il maîtriser Docker avant Kubernetes ?
Oui, dans une certaine mesure. Les bases suffisent : images, Dockerfiles, registres.
Kubernetes remplace-t-il Docker ?
Non, Kubernetes orchestre des conteneurs, il ne les remplace pas. Docker (ou containerd) reste le runtime.