Architecture Kubernetes : comprendre le cluster en 15 minutes

Vous avez entendu parler de Kubernetes, vous savez qu’il “orchestre des conteneurs”, mais comment ça marche concrètement ? Ce guide vous explique l’architecture interne de Kubernetes : quels composants font quoi, comment ils communiquent entre eux, et pourquoi votre application reste disponible même quand un serveur tombe en panne.

Ce que vous allez apprendre

• Identifier chaque brique de l’architecture et son rôle précis
• Comprendre le chemin d’un Pod depuis votre commande kubectl jusqu’à son exécution
• Expliquer pourquoi Kubernetes “se répare tout seul” en cas de problème

Prérequis : avoir lu Qu’est-ce que Kubernetes et connaître les bases de Docker. Si ces concepts sont flous, commencez par là !

L’architecture en une image

Avant d’entrer dans les détails, prenons du recul. Imaginez une entreprise de livraison : il y a un bureau central qui décide quels colis envoyer où, et des livreurs sur le terrain qui transportent réellement les colis. Kubernetes fonctionne exactement comme ça.

Un cluster Kubernetes se divise en deux parties distinctes qui ne font pas du tout le même travail :

Partie	Rôle	Analogie	Ce qu’il NE fait PAS
Control Plane	Le cerveau : décide où déployer, surveille l’état, corrige les problèmes	Le bureau central de l’entreprise	Ne fait tourner aucun conteneur applicatif
Worker Nodes	Les muscles : exécutent les conteneurs de vos applications	Les livreurs sur le terrain	Ne prennent aucune décision stratégique

Glissez pour voir

Pourquoi cette séparation ?

Cette séparation n’est pas un hasard — elle apporte trois avantages majeurs :

1. Scalabilité : besoin de plus de puissance ? Ajoutez des Worker Nodes sans toucher au Control Plane
2. Résilience : si un Worker tombe, le Control Plane réaffecte automatiquement les Pods ailleurs
3. Sécurité : le Control Plane peut être isolé et protégé, séparé des workloads applicatifs

Le Control Plane : le cerveau du cluster

Le Control Plane (plan de contrôle) est la partie “intelligente” de Kubernetes. Il prend toutes les décisions du cluster : où déployer vos applications, comment réagir si quelque chose tombe en panne, comment répartir la charge… Mais attention : il ne fait jamais tourner vos conteneurs applicatifs. Son seul travail, c’est d’orchestrer.

Dans notre analogie de l’entreprise de livraison, le Control Plane c’est le siège social : il décide, coordonne, mais ne livre aucun colis lui-même.

Les 4 composants essentiels du Control Plane

Le Control Plane repose sur 4 composants essentiels qui travaillent ensemble. Chacun a un rôle précis — comme les différents services d’une entreprise. Un 5ème composant optionnel (cloud-controller-manager) s’ajoute pour les clusters cloud.

1. API Server — Le point d’entrée unique (l’accueil de l’entreprise)

   Imaginez un standard téléphonique : toutes les communications passent par lui. L’API Server est le seul point d’entrée vers le cluster Kubernetes. Que vous utilisiez la ligne de commande kubectl, un dashboard web, ou un pipeline CI/CD, tout passe par l’API Server.

   Son travail :

   • Recevoir vos requêtes (créer un Pod, lister les services…)
   • Valider que la requête est correcte et que vous avez les droits
   • Transmettre les instructions aux autres composants

   6443/api/v1/pods

   # Chaque commande kubectl passe par l'API Server
   kubectl get pods
   kubectl apply -f deployment.yaml
   # → L'API Server valide le YAML, puis le stocke dans etcd

   Pourquoi un point d'entrée unique ?

   Cette architecture centralisée simplifie la sécurité (un seul endroit à protéger) et garantit la cohérence (impossible d’avoir deux composants qui se contredisent).

2. etcd — La mémoire du cluster (les archives de l’entreprise)

   etcd est une base de données clé-valeur distribuée. Elle stocke absolument tout sur l’état de votre cluster : la liste des Pods, leurs configurations, les secrets, les droits utilisateurs, l’historique des déploiements…

   C’est la “source de vérité” : si vous vous demandez “quel est l’état actuel de mon cluster ?”, la réponse est dans etcd.

   etcd est critique — sauvegardez-le !

   Si etcd est perdu sans backup, votre cluster est irrécupérable. Toutes les configurations, tous les secrets, tout est perdu. En production :

   • Sauvegardez etcd automatiquement (snapshots réguliers)
   • Répliquez etcd sur plusieurs machines (minimum 3 pour la haute disponibilité)
   • Testez vos restaurations !

3. Scheduler — Le placeur de Pods (le service logistique)

   Quand vous créez un nouveau Pod, une question se pose : sur quel serveur le déployer ? C’est le travail du Scheduler.

   Il analyse :

   • Les ressources disponibles sur chaque Worker Node (CPU, mémoire)
   • Les contraintes que vous avez définies (affinités, taints, tolerations)
   • Les besoins du Pod (ressources demandées, volumes nécessaires)

   Puis il choisit le meilleur candidat et informe l’API Server de sa décision.

   Le Scheduler ne lance rien lui-même

   Le Scheduler décide où, mais il ne déploie pas. Il se contente de dire “ce Pod devrait aller sur le Node X”. C’est ensuite le Kubelet du Node X qui fait le travail.

4. Controller Manager — Le gardien de l’état (le service qualité)

   Le Controller Manager surveille en permanence l’état réel du cluster et le compare à l’état souhaité (ce que vous avez défini dans vos fichiers YAML). S’il y a une différence, il agit pour corriger.

   Exemples concrets :

   • Vous avez demandé 3 répliques, mais un Pod a crashé → il en recrée un
   • Un nœud ne répond plus → il marque ses Pods comme “à redéployer”
   • Un Deployment a été mis à jour → il orchestre le rolling update

   Le Controller Manager contient en fait plusieurs contrôleurs spécialisés : Node Controller, Replication Controller, Endpoints Controller, etc.

Le cloud-controller-manager : l’intégrateur cloud (optionnel)

Le cloud-controller-manager est un composant optionnel du Control Plane. Il n’existe que si votre cluster est déployé sur un fournisseur cloud (AWS, GCP, Azure, etc.). Si vous utilisez un cluster bare-metal ou local (Minikube, kubeadm sur VMs), vous n’en avez pas besoin.

Pourquoi un composant séparé ?

Avant Kubernetes 1.6, la logique spécifique au cloud était intégrée directement dans le Controller Manager. L’extraction vers un composant dédié permet aux fournisseurs cloud de mettre à jour leur code indépendamment de Kubernetes.

Que gère le cloud-controller-manager ?

Il contient plusieurs contrôleurs spécifiques au cloud :

Contrôleur	Rôle	Exemple concret
Node Controller	Vérifie si un nœud existe toujours chez le provider	Si une VM AWS est supprimée, il met à jour l’état du cluster
Route Controller	Configure les routes réseau dans le cloud	Crée les règles de routage entre sous-réseaux
Service Controller	Gère les Load Balancers cloud	Crée automatiquement un ELB/ALB quand vous déclarez type: LoadBalancer

Glissez pour voir

Ce que ça change pour vous :

# Avec cloud-controller-manager sur AWS :
apiVersion: v1
kind: Service
metadata:
  name: mon-app
spec:
  type: LoadBalancer  # ← Le cloud-controller-manager crée un ELB automatiquement
  ports:
    - port: 80

Sans cloud-controller-manager, un Service de type LoadBalancer resterait en état “Pending” indéfiniment.

Clusters managés = automatique

Si vous utilisez EKS, GKE ou AKS, le cloud-controller-manager est déjà configuré. Vous n’avez rien à faire — il fonctionne en arrière-plan.

Comment ils travaillent ensemble

Ces composants ne fonctionnent jamais isolément — ils forment une chaîne de traitement. Voici ce qui se passe quand vous déployez une application :

Seul l'API Server accède à etcd

Point crucial de l’architecture : l’API Server est le seul composant qui communique directement avec etcd. Le Scheduler, le Controller Manager, les Kubelets — tous passent par l’API Server pour lire ou écrire des données. Cette centralisation garantit la cohérence des données et simplifie la sécurité.

Communication asynchrone et modèle pull

Les composants ne s’appellent pas directement. Ils “observent” tous etcd (via l’API Server) et réagissent aux changements. C’est un modèle événementiel : le Scheduler ne sait pas qu’il doit agir parce que l’API Server l’appelle, mais parce qu’il détecte un nouveau Pod “non assigné” dans etcd.

De même, les Kubelets fonctionnent en mode “pull” : ils interrogent régulièrement l’API Server pour savoir quels Pods ils doivent exécuter, plutôt que d’attendre des ordres.

Les Worker Nodes : là où tournent vos conteneurs

Maintenant que nous avons vu le “cerveau”, passons aux “muscles”. Les Worker Nodes (nœuds de travail) sont les machines qui exécutent réellement vos applications. C’est là que vos conteneurs tournent, consomment du CPU, de la mémoire, et répondent aux requêtes.

Dans notre analogie, les Worker Nodes sont les livreurs : ils ne décident pas où aller (c’est le Control Plane), mais ce sont eux qui font le travail concret.

Chaque Worker Node est une machine (physique ou virtuelle) avec trois composants essentiels installés dessus.

Les 3 composants d’un Worker Node

Composant	Rôle en une phrase	Analogie	Exemple concret
Kubelet	Agent qui reçoit les ordres et lance les conteneurs	Le contremaître sur le chantier	”L’API Server dit de lancer nginx, je m’en occupe”
Kube-proxy	Configure le réseau pour que les Pods communiquent	Le standardiste téléphonique	”Le Service X doit rediriger vers ces 3 Pods”
Container Runtime	Exécute réellement les conteneurs	Les outils de construction	”Je télécharge l’image et je lance le conteneur”

Glissez pour voir

Kubelet : l’agent local qui fait le travail

Le Kubelet est un agent qui tourne sur chaque Worker Node. C’est lui qui fait le lien entre le Control Plane (qui décide) et le Node (qui exécute).

Son travail au quotidien :

• Écouter l’API Server pour savoir quels Pods il doit faire tourner
• Lancer les conteneurs en demandant au Container Runtime
• Surveiller la santé des Pods (liveness probes, readiness probes)
• Remonter l’état au Control Plane (“ce Pod est Running”, “celui-là a crashé”)

# Vérifier que kubelet tourne sur un nœud (à exécuter sur le Node)
systemctl status kubelet

# Voir les logs du kubelet
journalctl -u kubelet -f

Le Kubelet est autonome

Si le Control Plane devient temporairement injoignable, le Kubelet continue de faire tourner les Pods existants. Il ne peut juste pas recevoir de nouvelles instructions. C’est un point fort de l’architecture : les workloads survivent aux pannes du Control Plane.

Kube-proxy : le réseau entre Pods et Services

Kube-proxy est responsable de la connectivité réseau sur le Node. Quand vous créez un Service Kubernetes (une IP stable pour accéder à vos Pods), c’est kube-proxy qui configure les règles pour que ça fonctionne.

Concrètement, il gère :

• Les règles iptables ou IPVS pour router le trafic
• Le load balancing entre les Pods d’un même Service
• La communication entre Pods de différents Nodes

Sans kube-proxy, vos Pods seraient isolés et incapables de communiquer avec le reste du cluster.

Container Runtime : l’exécution des conteneurs

Le Container Runtime est le moteur qui lance réellement les conteneurs. Kubernetes ne sait pas “lancer un conteneur” — il délègue cette tâche au runtime.

Kubernetes supporte plusieurs runtimes via l’interface CRI (Container Runtime Interface) :

Runtime	Description	Quand l’utiliser
containerd	Léger, standard de facto	Recommandé pour la plupart des cas
CRI-O	Optimisé pour Kubernetes	Clusters OpenShift, environnements Red Hat
Docker	Via dockershim (déprécié)	Éviter pour les nouveaux clusters

Glissez pour voir

Docker n'est plus nécessaire

Depuis Kubernetes 1.24, Docker n’est plus supporté directement comme runtime. Mais pas de panique : vos images Docker fonctionnent toujours parfaitement ! Le format d’image (OCI) est le même. Seul le moteur d’exécution change (containerd remplace Docker).

Si vous avez l’habitude de faire docker build, continuez — l’image résultante tourne sans problème sur containerd.

Le cycle de vie d’un déploiement : de kubectl au conteneur

Maintenant que vous connaissez tous les composants, voyons le film complet : que se passe-t-il exactement quand vous tapez kubectl apply ? Suivons le parcours étape par étape.

1. Vous envoyez une requête depuis votre terminal

   Tout commence par votre commande. Vous avez un fichier YAML qui décrit votre application, et vous demandez à Kubernetes de le déployer.

   kubectl apply -f mon-pod.yaml

   À ce stade, rien ne tourne encore. Vous venez juste d’envoyer une requête vers l’API Server.

2. L’API Server valide et stocke

   L’API Server reçoit votre requête et effectue plusieurs vérifications :

   • Authentification : qui êtes-vous ? (certificat, token…)
   • Autorisation : avez-vous le droit de créer un Pod dans ce namespace ?
   • Validation : le YAML est-il correct ? Les champs requis sont-ils présents ?

   Si tout est OK, il enregistre l’état souhaité dans etcd. À ce moment, etcd contient “je veux un Pod nginx”, mais le Pod n’existe pas encore réellement.

3. Le Scheduler choisit un nœud

   Le Scheduler surveille etcd en permanence. Il détecte qu’un nouveau Pod existe mais n’a pas encore de Node assigné (champ nodeName vide).

   Il analyse alors tous les Worker Nodes disponibles :

   • Node A : 2 CPU libres, 4 Go RAM → ✅ suffisant
   • Node B : 0.5 CPU libre, 1 Go RAM → ❌ pas assez
   • Node C : marqué “en maintenance” → ❌ exclu

   Décision : Node A. Le Scheduler met à jour etcd avec cette assignation.

4. Le Kubelet lance le conteneur

   Le Kubelet du Node A surveille aussi etcd (via l’API Server). Il voit qu’un Pod lui est assigné.

   Il passe alors à l’action :

   • Télécharge l’image Docker/OCI si elle n’est pas en cache
   • Demande au Container Runtime (containerd) de créer le conteneur
   • Configure les volumes, les variables d’environnement, les limites de ressources
   • Lance le conteneur

   Une fois le conteneur démarré, le Kubelet met à jour le statut : “Running”.

5. Kube-proxy configure le réseau

   En parallèle, kube-proxy entre en jeu. Le Pod vient d’obtenir une adresse IP (attribuée par le plugin CNI).

   Kube-proxy s’assure que :

   • Le Pod peut communiquer avec les autres Pods du cluster
   • Si le Pod fait partie d’un Service, les règles de routage sont mises à jour
   • Le load balancing est configuré si nécessaire

6. Le Controller Manager surveille en continu

   Le travail n’est pas terminé ! Le Controller Manager continue de surveiller :

   • Le Pod est-il toujours “Running” ?
   • Répond-il aux health checks (liveness probe) ?
   • Si c’est un Deployment avec 3 répliques, y a-t-il bien 3 Pods ?

   Si quelque chose ne va pas, le Controller Manager déclenche une action corrective (on verra ça dans la section suivante).

Tout ça prend quelques secondes

Ce parcours semble long, mais en pratique il se déroule en quelques secondes. Vous pouvez suivre l’avancement avec kubectl get pods -w (mode watch) pour voir le Pod passer de “Pending” à “ContainerCreating” à “Running”.

La réconciliation : Kubernetes se répare tout seul

C’est le super-pouvoir de Kubernetes et ce qui le différencie fondamentalement d’un simple script de déploiement. Kubernetes ne se contente pas de lancer vos conteneurs — il garantit qu’ils restent dans l’état que vous avez demandé, quoi qu’il arrive.

Le concept : état souhaité vs état actuel

Quand vous déployez une application sur Kubernetes, vous ne dites pas “lance 3 conteneurs”. Vous dites “je veux 3 répliques de mon application”. C’est une différence subtile mais fondamentale :

• Impératif (script classique) : “Exécute cette commande maintenant”
• Déclaratif (Kubernetes) : “Voici l’état que je souhaite, débrouille-toi”

Kubernetes stocke votre déclaration (l’état souhaité) dans etcd. Puis le Controller Manager compare en permanence avec la réalité (l’état actuel). S’il y a un écart, il agit.

Comment ça marche concrètement

Imaginons que vous avez déclaré vouloir 3 répliques de votre application :

État souhaité	État actuel	Écart détecté	Action du Controller Manager
3 répliques	3 Pods running	Aucun	✅ Rien à faire, tout va bien
3 répliques	2 Pods running	-1 Pod	⚠️ Créer 1 nouveau Pod
3 répliques	4 Pods running	+1 Pod	⚠️ Supprimer 1 Pod en trop
3 répliques	0 Pod running	-3 Pods	🔴 Créer 3 Pods d’urgence

Glissez pour voir

Cette boucle de réconciliation tourne en continu, toutes les quelques secondes. Elle ne s’arrête jamais.

Déclaratif = Résilient

C’est la magie du déclaratif : vous n’avez pas besoin de prévoir tous les scénarios de panne. Kubernetes sait que vous voulez 3 répliques. Si un serveur brûle, un disque lâche, ou un conteneur plante, Kubernetes corrigera automatiquement pour revenir à 3 répliques. Vous dormez tranquille.

Exemple concret d’auto-réparation

Suivons un scénario réaliste pas à pas :

# Situation initiale : tout va bien, 3 répliques running
kubectl get pods
# NAME                     READY   STATUS    RESTARTS   AGE
# nginx-deployment-abc12   1/1     Running   0          2h
# nginx-deployment-def34   1/1     Running   0          2h
# nginx-deployment-ghi56   1/1     Running   0          2h

# 💥 PANNE : le Node qui héberge nginx-deployment-ghi56 tombe !
# (panne réseau, crash matériel, peu importe)

# Que se passe-t-il automatiquement ?
# 1. Le Node Controller détecte que le Node ne répond plus
# 2. Après un délai (node-monitor-grace-period), il marque le Node "NotReady"
# 3. Les Pods sur ce Node sont marqués "Unknown" puis "Terminating"
# 4. Le ReplicaSet Controller détecte : 2 Pods running ≠ 3 souhaités
# 5. Il demande la création d'un nouveau Pod
# 6. Le Scheduler assigne ce Pod à un Node sain
# 7. Le Kubelet du nouveau Node lance le conteneur

# Résultat quelques minutes plus tard :
kubectl get pods
# NAME                     READY   STATUS    RESTARTS   AGE
# nginx-deployment-abc12   1/1     Running   0          2h
# nginx-deployment-def34   1/1     Running   0          2h
# nginx-deployment-xyz99   1/1     Running   0          45s   ← Nouveau !

Délais de détection

La détection d’une panne de Node n’est pas instantanée (par défaut ~5 minutes). C’est voulu : on évite les faux positifs dus à un réseau temporairement instable. Ces délais sont configurables selon vos besoins de réactivité.

Pourquoi c’est révolutionnaire

Avant Kubernetes, gérer les pannes demandait :

• Des scripts de monitoring complexes
• Des procédures manuelles de failover
• Une astreinte 24/7 pour réagir aux incidents

Avec Kubernetes, vous déclarez ce que vous voulez, et le cluster se débrouille. Pas besoin d’écrire “si le serveur A tombe, relance sur B”. C’est automatique.

Le réseau Kubernetes : comment les Pods communiquent

Le réseau est souvent la partie la plus abstraite pour les débutants. Pourtant, Kubernetes impose un modèle simple et élégant qui facilite grandement la vie des développeurs.

Les 3 règles d’or du réseau Kubernetes

Kubernetes garantit ces trois propriétés, quel que soit le plugin réseau utilisé :

Règle	Ce que ça signifie	Pourquoi c’est pratique
Chaque Pod a sa propre IP	Pas d’IP partagée, pas de ports en conflit	Vos conteneurs peuvent tous écouter sur le port 80
Tous les Pods peuvent communiquer	Réseau “plat” sans NAT	Pas de configuration complexe pour joindre un autre Pod
Les Services fournissent une IP stable	Une IP fixe même si les Pods changent	Vos applications peuvent se référencer par nom

Glissez pour voir

Réseau plat = simplicité

Dans un réseau “plat”, tous les Pods se voient directement. Le Pod A sur le Node 1 peut contacter le Pod B sur le Node 3 sans configuration particulière. C’est comme si tous les Pods étaient sur le même réseau local, même s’ils sont répartis sur des machines différentes.

Les plugins CNI : qui implémente tout ça ?

Kubernetes définit les règles, mais ne fournit pas l’implémentation réseau. C’est le rôle des plugins CNI (Container Network Interface). Vous devez en choisir un lors de l’installation du cluster.

Plugin	Points forts	Cas d’usage typique
Calico	Réseau + Network Policies avancées, BGP	Production avec besoins de sécurité
Flannel	Simple, léger, rapide à installer	Clusters de test, environnements simples
Cilium	eBPF, observabilité native, performances	Clusters modernes, besoin de visibilité
Weave	Chiffrement intégré, mesh réseau	Multi-datacenter, réseaux non fiables

Glissez pour voir

Quel CNI choisir ?

Pour débuter, Calico ou Flannel sont les choix les plus courants. Calico offre plus de fonctionnalités (Network Policies), Flannel est plus simple. Pour un cluster managé (EKS, GKE, AKS), le CNI est souvent préconfiguré.

Récapitulatif : tous les composants en un coup d’œil

Voici un tableau de synthèse de tous les composants que nous avons vus. Gardez-le sous la main comme référence !

Composants du Control Plane (le cerveau)

Composant	Rôle en une phrase	Analogie	Question qu’il résout
API Server	Point d’entrée unique du cluster	L’accueil de l’entreprise	”Comment communiquer avec le cluster ?“
etcd	Base de données de l’état du cluster	Les archives centrales	”Quel est l’état actuel et souhaité ?”
Scheduler	Décide où placer les Pods	Le service logistique	”Sur quel Node déployer ce Pod ?”
Controller Manager	Maintient l’état souhaité	Le service qualité	”L’état réel correspond-il au souhaité ?”
Cloud Controller Manager (optionnel)	Intègre les services cloud	Le service partenariats	”Comment utiliser les ressources du cloud ?”

Glissez pour voir

Composants des Worker Nodes (les muscles)

Composant	Rôle en une phrase	Analogie	Question qu’il résout
Kubelet	Agent qui lance les conteneurs	Le contremaître	”Comment lancer ce Pod sur ce Node ?”
Kube-proxy	Configure le réseau local	Le standardiste	”Comment joindre ce Pod ?”
Container Runtime	Exécute les conteneurs	Les outils	”Comment faire tourner ce conteneur ?”

Glissez pour voir

À retenir

Si vous ne devez retenir que quelques points de ce guide, voici l’essentiel :

Les 8 points clés

1. Architecture en 2 parties : Control Plane (décide) + Worker Nodes (exécutent) — ils ne font jamais le même travail

2. Tout passe par l’API Server : c’est le seul point d’entrée vers le cluster, et le seul à communiquer avec etcd

3. etcd est la mémoire : toute la configuration et l’état du cluster y sont stockés — sauvegardez-le impérativement

4. Le Scheduler place, il ne lance pas : il décide du “où”, c’est le Kubelet qui fait le “comment”

5. Le Kubelet fonctionne en mode pull : il interroge régulièrement l’API Server pour savoir quels Pods exécuter

6. Le cloud-controller-manager est optionnel : il n’existe que sur les clusters cloud (AWS, GCP, Azure) pour gérer Load Balancers, routes et nœuds

7. Kubernetes est déclaratif : vous décrivez l’état souhaité, Kubernetes se débrouille pour l’atteindre et le maintenir

8. La réconciliation est continue : le Controller Manager compare en permanence état souhaité vs état réel, et corrige les écarts automatiquement

Schéma mental à retenir

Testez vos connaissances

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

📝 10 questions

⏱️ 15 min.

🎯 70%

Informations

• Le chronomètre démarre au clic sur Démarrer
• Questions à choix multiples, vrai/faux et réponses courtes
• Vous pouvez naviguer entre les questions
• Les résultats détaillés sont affichés à la fin

▶ Démarrer le quiz

Lance le quiz et démarre le chronomètre

Prochaines étapes

Control Plane en détail Plongez dans l'API Server, etcd, Scheduler et Controller Manager

Worker Nodes en détail Kubelet, Kube-proxy et Container Runtime expliqués

Écrire des manifests YAML Créez vos premiers fichiers de configuration Kubernetes

Guide des Pods L'unité de base de Kubernetes en pratique

×

📖 Voir la documentation →