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à !

Lecture conseillée

Pour creuser l'architecture interne (API Server, etcd, Kubelet, Scheduler) avec schémas détaillés et exemples, Kubernetes in Action, 2e éd., Marko Luksa est la référence absolue. 800 pages, à jour Kubernetes 1.27+.

Lien affilié Amazon. Acheter via ce lien soutient le site sans surcoût pour vous.

L'architecture en une image

Avant d'entrer dans les détails, retenez la séparation qui structure tout le reste : un plan de contrôle prend les décisions, des nœuds de travail les exécutent. Vos applications vont sur les seconds, et aucune décision d'ordonnancement n'est prise par eux.

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

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

Glissez pour voir

Cette séparation n'est pas un hasard, et elle explique trois propriétés que vous allez retrouver partout. Elle rend le cluster extensible, puisqu'on ajoute des Worker Nodes sans toucher au Control Plane. Elle le rend résilient, un Worker qui tombe voyant ses Pods réaffectés ailleurs. Et elle le rend protégeable, le Control Plane pouvant être isolé du reste.

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... Son travail, c'est d'orchestrer.

En pratique, vos applications ne s'y déploient pas : une marque posée sur ce nœud en écarte les Pods ordinaires, pour lui garder les ressources dont il a besoin. C'est une protection, pas une impossibilité technique. Un Pod peut y tourner s'il est explicitement autorisé à passer outre, et c'est d'ailleurs ainsi que les composants de Kubernetes eux-mêmes y sont placés. Retenez donc la règle d'usage, pas une interdiction absolue : on ne déploie pas ses applications sur le Control Plane.

Les composants natifs du Control Plane

Le Control Plane repose sur 4 composants natifs 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 (kube-apiserver) : le point d'entrée unique (l'accueil de l'entreprise)

   Toutes les communications transitent par lui : l'API Server est le seul point d'entrée du cluster, pour vos commandes kubectl comme pour les composants internes. 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

   Ce point d'entrée unique n'est pas une contrainte mais un choix : il n'y a qu'un seul endroit à protéger, et deux composants ne peuvent pas se contredire.

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 (kube-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.

   Retenez la limite de son rôle, car elle surprend : le Scheduler décide où, mais il ne déploie rien. Il inscrit sa décision, et c'est le Kubelet du nœud choisi qui fait le travail.

4. Controller Manager (kube-controller-manager) : le gardien de l'état (le service qualité)

   Le Controller Manager compare en permanence l'état réel du cluster à l'état souhaité, celui que vous avez déclaré dans vos fichiers YAML. Dès qu'il constate un écart, il agit pour le réduire.

   Trois situations quotidiennes montrent cette boucle de correction à l'œuvre :

   • Vous avez demandé 3 répliques et un Pod s'est arrêté : 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 la mise à jour progressive

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

Ces noms entre parenthèses ne sont pas décoratifs : ce sont les noms de processus que vous lirez sur un vrai cluster. Sur une installation kubeadm, les quatre composants tournent comme Pods statiques dans le namespace kube-system, et le nom du nœud leur est accolé :

kubectl get pods -n kube-system -l tier=control-plane
# NAME                             READY   STATUS
# etcd-node1                       1/1     Running
# kube-apiserver-node1             1/1     Running
# kube-controller-manager-node1    1/1     Running
# kube-scheduler-node1             1/1     Running

Retenez la correspondance, car les messages d'erreur et la documentation officielle emploient toujours la forme technique : « API Server » se lit kube-apiserver dans les journaux, « Scheduler » se lit kube-scheduler, et « Controller Manager » se lit kube-controller-manager. Un Pod bloqué en Pending sans événement de placement renvoie donc à kube-scheduler, pas à un composant nommé « Scheduler » quelque part.

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é ?

La logique propre à chaque fournisseur cloud vivait autrefois dans le Controller Manager lui-même. Son extraction vers un composant dédié permet à ces fournisseurs de publier leurs correctifs sans attendre une version 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.

Si vous utilisez EKS, GKE ou AKS, ce composant est déjà configuré par le fournisseur : il fonctionne en arrière-plan, vous n'avez rien à faire.

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 :

Un point structure toute l'architecture : l'API Server est le seul composant qui parle directement à etcd. Le Scheduler, le Controller Manager et les Kubelets passent tous par lui pour lire ou écrire. Deux bénéfices en découlent, la cohérence des données, qu'un seul écrivain garantit, et la sécurité, puisqu'il n'y a qu'un accès à protéger.

Les composants ne s'appellent jamais directement. Chacun observe l'API Server et réagit aux changements qu'il y voit : c'est un modèle événementiel. Le Scheduler n'agit pas parce que quelqu'un le lui demande, mais parce qu'il a vu apparaître un Pod « non assigné ».

Notez la formulation, elle compte : les composants observent l'API Server, pas etcd. Personne d'autre que l'API Server ne sait où est etcd, ni comment lui parler.

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 composants d'intégration d'un cluster réel

Les composants natifs ne suffisent pas à faire un cluster utilisable. Kubernetes s'arrête volontairement à la définition d'interfaces et laisse à d'autres le soin de les implémenter : c'est ce qui lui permet de tourner aussi bien sur un poste de travail que chez un fournisseur cloud, sans rien changer à ses objets.

Composant	Ce que Kubernetes délègue	Où il s'exécute
CNI	le réseau des Pods	un plugin sur chaque nœud
CSI	le stockage persistant	un contrôleur et des plugins par nœud
Cloud Controller Manager	l'intégration au fournisseur cloud	côté Control Plane
Ingress Controller	l'application des règles HTTP/HTTPS	dans le cluster, en Pods

Glissez pour voir

Retenez la conséquence plutôt que la liste : un objet Kubernetes sans son implémenteur ne fait rien. C'est l'erreur de débutant la plus fréquente, et elle prend toujours la même forme. Un Ingress créé sans Ingress Controller déployé est ignoré, sans message d'erreur. Un PersistentVolumeClaim sans driver CSI reste en attente. Un cluster sans plugin CNI garde ses nœuds en NotReady.

Chacun de ces composants a son guide : le réseau des Pods, le stockage et l'Ingress.

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.

Les Worker Nodes exécutent ce que le Control Plane a décidé. Ils ne choisissent pas quel Pod héberger, mais fournissent le CPU, la mémoire et le réseau sur lesquels il tourne réellement.

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

Les 3 composants d'un Worker Node

Trois programmes suffisent à faire un nœud de travail, et ils se répartissent les rôles sans se chevaucher : l'un reçoit les ordres, l'autre lance les conteneurs, le dernier rend le réseau utilisable.

Composant	Rôle en une phrase	Exemple concret
Kubelet	Agent qui reçoit les ordres et lance les conteneurs	"L'API Server dit de lancer nginx, je m'en occupe"
Kube-proxy	Configure le réseau pour que les Pods communiquent	"Le Service X doit rediriger vers ces 3 Pods"
Container Runtime	Exécute réellement les conteneurs	"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 simplement plus recevoir de nouvelles instructions. C'est un point fort de l'architecture, les applications survivent à une panne 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 nftables qui traduisent l'IP d'un Service vers ses Pods
• Le load balancing entre les Pods d'un même Service
• Le suivi des EndpointSlices, pour ne router que vers les Pods prêts

Une confusion revient souvent, et il vaut mieux la lever tout de suite : kube-proxy ne fait pas communiquer les Pods entre eux. C'est le greffon CNI qui pose les routes permettant à un Pod de joindre un Pod d'un autre nœud, et cette communication fonctionne sans que kube-proxy n'intervienne. Sans kube-proxy, les Services cesseraient de répondre ; les Pods, eux, continueraient de se parler par leurs adresses IP.

Le mode IPVS est déprécié depuis Kubernetes 1.35, au profit de nftables, disponible en version stable depuis la 1.33. Le mode iptables reste le défaut sur Linux.

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 Engine	Non supporté depuis Kubernetes 1.24 (dockershim supprimé)	Ne pas utiliser

Glissez pour voir

Docker n'est plus nécessaire

Depuis Kubernetes 1.24, dockershim a été supprimé. Docker Engine n'est plus un runtime supporté directement. 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 interroge l'API Server en permanence. Il détecte qu'un nouveau Pod existe mais n'a pas encore de Node assigné (champ nodeName vide).

   Il passe alors en revue chaque nœud de travail disponible, et la comparaison se joue sur les ressources libres :

   • Node A, 2 CPU libres et 4 Go de mémoire : retenu, la demande passe
   • Node B, 0,5 CPU libre et 1 Go : écarté, ressources insuffisantes
   • Node C, marqué en maintenance : exclu d'office

   Décision : Node A. Le Scheduler écrit cette assignation via l'API Server, qui la persiste dans etcd.

4. Le Kubelet lance le conteneur

   Le Kubelet du Node A interroge lui aussi l'API Server. Il voit qu'un Pod lui est assigné.

   Il enchaîne alors quatre actions, toujours dans cet ordre :

   • Télécharge l'image OCI si elle n'est pas déjà en cache sur le nœud
   • Demande au runtime de conteneurs, containerd, de créer le conteneur
   • Configure les volumes, les variables d'environnement et 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 rend ce Pod joignable, ce qui recouvre trois garanties :

   • Le Pod communique avec les autres Pods du cluster
   • S'il fait partie d'un Service, les règles de routage sont mises à jour
   • La répartition de charge est configurée si le Service en compte plusieurs

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).

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. Le Controller Manager la compare en permanence à l'état réel, et agit dès qu'un écart apparaît.

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 en cours	Aucun	Rien à faire, l'état converge
3 répliques	2 Pods en cours	-1 Pod	Créer 1 Pod
3 répliques	4 Pods en cours	+1 Pod	Supprimer le Pod en trop
3 répliques	0 Pod en cours	-3 Pods	Créer les 3 Pods

Glissez pour voir

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

C'est tout l'intérêt du mode déclaratif : vous n'avez pas à prévoir chaque scénario de panne. Kubernetes sait que vous voulez 3 répliques. Qu'un serveur tombe, qu'un disque lâche ou qu'un conteneur plante, il revient de lui-même à 3 répliques.

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 !

Ne vous attendez pas à une réaction immédiate : la détection d'une panne de nœud prend environ cinq minutes par défaut. Ce délai est voulu, un réseau brièvement instable ne devant pas déclencher le déplacement de toutes les applications d'une machine.

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

« Plat » veut dire que tous les Pods se voient directement : le Pod A sur le nœud 1 contacte le Pod B sur le nœud 3 sans configuration particulière, comme s'ils partageaient un réseau local, alors qu'ils sont 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é
kindnet	minimal, sans réglage	fourni d'office par Kind, pour l'apprentissage

Glissez pour voir

Le plus souvent, vous n'aurez pas à choisir : un cluster managé arrive avec son CNI, et Kind installe kindnet sans rien demander. La question se pose le jour où vous montez un cluster vous-même, et elle se tranche d'abord sur les Network Policies, que Flannel ne sait pas appliquer.

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)

Le tableau se lit par sa dernière colonne : chaque composant existe pour répondre à une question, et c'est ainsi qu'on retient lequel fait quoi.

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

Glissez pour voir

Composants des Worker Nodes (les muscles)

Même lecture côté nœuds de travail, avec une différence de nature : aucun de ces composants ne décide quoi que ce soit, tous exécutent.

Composant	Rôle en une phrase	Question qu'il résout
Kubelet	Agent qui lance les conteneurs	"Comment lancer ce Pod sur ce Node ?"
Kube-proxy	Configure le réseau local	"Comment joindre ce Pod ?"
Container Runtime	Exécute les conteneurs	"Comment faire tourner ce conteneur ?"

Glissez pour voir

À retenir

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

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

Dix questions pour vérifier que la répartition des rôles est acquise : qui décide, qui exécute, et ce qui se passe quand un composant manque.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

10 questions

15 min.

70% requis

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

FAQ : questions fréquentes sur l'architecture Kubernetes

Ces questions reviennent souvent quand on découvre le fonctionnement interne d'un cluster Kubernetes. Les réponses ci-dessous reprennent les points clés du guide, composants du Control Plane, rôle d'etcd et du kubelet, auto-réparation et dimensionnement d'un cluster.

Qu'est-ce qu'un cluster Kubernetes ?

Un cluster Kubernetes est un ensemble de machines, appelées nœuds, qui exécutent vos applications conteneurisées. Il réunit un Control Plane qui pilote le cluster et des Worker Nodes qui font tourner les Pods.

Quels sont les composants du Control Plane ?

Le Control Plane réunit l'API Server, etcd, le Scheduler et le Controller Manager. Ensemble, ils reçoivent les requêtes, stockent l'état du cluster, placent les Pods sur les nœuds et corrigent les écarts.

Quelle est la différence entre le Control Plane et les Worker Nodes ?

Le Control Plane est le cerveau du cluster : il décide, planifie et surveille. Les Worker Nodes sont les muscles : ils exécutent réellement les Pods de vos applications. Un cluster a besoin des deux.

À quoi sert etcd dans Kubernetes ?

etcd est la base de données clé-valeur du cluster. Elle stocke tout l'état de Kubernetes : objets, configuration, état souhaité. Sa sauvegarde est essentielle car perdre etcd revient à perdre le cluster.

Qu'est-ce que le kubelet ?

Le kubelet est l'agent présent sur chaque Worker Node. Il reçoit les Pods à exécuter, demande au container runtime de lancer les conteneurs et remonte leur état de santé au Control Plane.

Comment Kubernetes assure-t-il l'auto-réparation ?

Kubernetes compare en continu l'état souhaité, stocké dans etcd, à l'état réel du cluster. Dès qu'un écart apparaît, par exemple un Pod en moins, les contrôleurs agissent pour rétablir l'état voulu.

Combien de nœuds faut-il pour un cluster Kubernetes ?

Un cluster de test peut tenir sur un seul nœud. En production, prévoyez au moins trois nœuds Control Plane pour la haute disponibilité, plus des Worker Nodes dimensionnés selon la charge des applications.

Qu'est-ce que l'API Server Kubernetes ?

L'API Server est la porte d'entrée unique du cluster. Toute commande kubectl et tout composant interne passent par lui. Il valide les requêtes, les applique et lit ou écrit l'état dans etcd.

Pour aller plus loin

• Les Pods : L'unité que le scheduler place sur un node, vue de l'intérieur.
• Écrire des manifests : La traduction de cette architecture en YAML que l'API Server accepte.
• Les Worker Nodes : Le rôle exact du kubelet, du kube-proxy et du runtime sur chaque node.

×

📖 Voir la documentation →