Aller au contenu principal

Architecture d'un cluster Kubernetes

Résumé : un cluster Kubernetes se divise en deux mondes — le control plane qui décide et le data plane (worker nodes) qui exécute. Cette leçon détaille chacun des composants (API Server, etcd, Scheduler, Controller Manager, Cloud Controller Manager, kubelet, kube-proxy, container runtime), leur rôle précis, et comment ils dialoguent pour faire tourner des milliers de Pods de manière autonome et résiliente.

1. Vue d'ensemble en un schéma​

Deux règles fondamentales à retenir :

  1. L'API Server est le point central obligatoire. Toute communication passe par lui.
  2. Le control plane décide, les nodes exécutent. Séparation nette des rôles.

2. Le control plane — le cerveau du cluster​

Le control plane est l'ensemble des composants qui prennent les décisions. Dans un cluster managé (EKS, GKE, AKS), le cloud gère intégralement le control plane pour vous. Dans un cluster on-premise, vous le gérez vous-même.

2.1 · API Server — le portail obligatoire​

Sans API Server, rien ne fonctionne. C'est le composant le plus critique du cluster. Sa haute disponibilité est priorité absolue en production.

2.2 · etcd — la mémoire du cluster​

etcd vient d'un jeu de mots — c'est un stockage /etc distribué. Utilisé aussi hors Kubernetes par des projets comme CoreDNS ou Rook.

2.3 · Scheduler — le placeur intelligent​

Analogie utile : le Scheduler est comme un maître d'hôtel qui place les clients dans un restaurant — il regarde les tables disponibles, la taille des groupes, les préférences (fumeur/non-fumeur, terrasse/intérieur), et attribue la meilleure place.

2.4 · Controller Manager — la boucle de convergence​

Le Controller Manager est le vrai moteur de Kubernetes. C'est lui qui maintient tout à sa place, 24h/24, sans intervention humaine.

2.5 · Cloud Controller Manager — la passerelle vers le cloud​

Ce composant existe précisément pour que Kubernetes reste portable — le core Kubernetes ne connaît pas AWS ou GCP, le CCM traduit.

3. Les worker nodes — les bras du cluster​

Un worker node est une machine (physique ou virtuelle) qui fait tourner les Pods. C'est ici que votre code réel s'exécute.

3.1 · kubelet — l'agent local​

kubelet est le composant le plus proche de vos conteneurs. C'est lui qui parle au container runtime pour dire « lance nginx:1.27 avec ces variables et cette mémoire ».

3.2 · Container Runtime — l'exécuteur​

En 2026, containerd est le runtime par défaut sur presque tous les clusters. Docker Engine n'est plus utilisé par Kubernetes (mais reste très utilisé pour construire les images).

3.3 · kube-proxy — le magicien réseau​

En 2026, de plus en plus de clusters remplacent kube-proxy par des CNI modernes comme Cilium (basé sur eBPF), qui offrent des performances 10 fois supérieures et des fonctionnalités avancées (observabilité, network policies L7).

4. Le réseau Kubernetes — un monde plat​

Le modèle réseau de Kubernetes est très différent de celui de Docker seul.

C'est le CNI qui rend Kubernetes portable entre AWS, GCP, Azure et on-premise, malgré leurs modèles réseau très différents.

5. Le cycle complet — que se passe-t-il quand on fait kubectl apply ?​

Suivons pas à pas ce qui se passe quand vous lancez un Deployment.

Ce chorégraphie complexe est complètement invisible pour vous. Vous voyez juste deployment/mon-app created. Mais savoir ce qui se passe sous le capot vous aidera énormément pour diagnostiquer les incidents en production.

6. Haute disponibilité — le control plane répliqué​

En production, on ne se contente jamais d'un seul control plane. On en réplique au moins 3.

Bonne pratique : 3, 5 ou 7 masters répartis sur plusieurs zones de disponibilité. Le cluster tolère la perte d'une zone entière sans downtime.

Dans un cluster managé (EKS, GKE, AKS), le cloud gère tout ça pour vous. C'est la raison n°1 de choisir un cluster managé au démarrage.

7. Combien coûte un cluster en 2026 ?​

Question pratique importante — les prix approximatifs pour un cluster managé en 2026.

Note importante : ces coûts effraient au premier abord, mais ils remplacent une équipe entière d'admins système. Le ROI Kubernetes se calcule en effectif économisé et résilience gagnée, pas juste en dollars cloud.

Retenir en 30 secondes​

  • Un cluster = control plane (décide) + data plane (exécute, worker nodes).
  • Control plane = API Server + etcd + Scheduler + Controller Manager + Cloud Controller Manager.
  • Worker node = kubelet + kube-proxy + container runtime (containerd).
  • L'API Server est le point d'entrée obligatoire — tout passe par lui.
  • etcd est la mémoire du cluster — perte d'etcd = perte du cluster.
  • kubelet est le seul composant obligatoire côté worker qui parle à l'API Server.
  • CNI (Container Network Interface) = rend Kubernetes portable multi-cloud.
  • HA = 3+ masters répartis sur plusieurs zones.

Suivant : Manifests YAML et kubectl : le workflow déclaratif →