Control Plane Kubernetes : le cerveau de votre cluster

Vous avez compris l’architecture globale de Kubernetes : un Control Plane qui décide, et des Worker Nodes qui exécutent. Mais comment le Control Plane fonctionne-t-il en interne ? Quels composants le constituent, et surtout, comment communiquent-ils entre eux ?

Ce guide vous explique en détail le fonctionnement du Control Plane — le cerveau de votre cluster. Vous comprendrez pourquoi vos applications restent disponibles même quand un Pod crashe, et comment Kubernetes “sait” où déployer vos conteneurs.

Ce que vous allez apprendre

• Identifier les 4 composants essentiels du Control Plane et leur rôle précis
• Comprendre la règle d’or : seul l’API Server accède à etcd
• Expliquer la boucle de contrôle (watch → compare → act) du Controller Manager
• Savoir comment le Scheduler et les Kubelets communiquent avec l’API Server

Prérequis : avoir lu Architecture Kubernetes. Si vous ne savez pas ce qu’est un Pod ou un Node, commencez par là !

Vue d’ensemble du Control Plane

Le Control Plane est la partie “intelligente” de Kubernetes. Il prend toutes les décisions du cluster mais ne fait jamais tourner vos conteneurs applicatifs. Son seul travail : orchestrer.

Le Control Plane repose sur 4 composants essentiels qui travaillent ensemble, plus un 5ème optionnel pour les clusters cloud :

Composant	Rôle en une phrase	Ce qu’il NE fait PAS
kube-apiserver	Point d’entrée unique, seul à accéder à etcd	Ne lance pas de conteneurs
etcd	Base de données clé-valeur, source de vérité	Ne prend aucune décision
kube-scheduler	Assigne les Pods aux Nodes	Ne lance PAS les conteneurs
kube-controller-manager	Boucle de contrôle, réconcilie état souhaité/actuel	N’accède pas directement à etcd
cloud-controller-manager	(optionnel) Intègre les services cloud	N’existe que sur clusters cloud

Glissez pour voir

Confusion fréquente : le Scheduler ne lance rien

Une erreur courante : croire que le Scheduler lance les conteneurs. C’est faux. Le Scheduler ne fait qu’assigner un Pod à un Node (il écrit “ce Pod va sur ce Node” dans etcd via l’API Server). C’est le Kubelet du Node qui lance réellement le conteneur.

L’API Server : le point d’entrée unique

Le kube-apiserver est le cœur du Control Plane. C’est lui qui reçoit toutes les requêtes — que ce soit de kubectl, d’une interface web, ou des autres composants internes.

Ce que fait l’API Server

L’API Server remplit trois fonctions essentielles :

1. Valide les requêtes : vérifie le format, l’authentification, les autorisations
2. Persiste les données : stocke l’état dans etcd (et seulement lui le fait !)
3. Expose l’état du cluster : permet de lire l’état via l’API REST

# Toute interaction passe par l'API Server
kubectl get pods                    # Lecture via API Server
kubectl apply -f deployment.yaml    # Écriture via API Server
kubectl delete pod mon-pod          # Suppression via API Server

Seul l’API Server accède à etcd

C’est la règle d’or de l’architecture Kubernetes :

Point crucial de l'architecture

Seul l’API Server 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 :

• Cohérence : un seul point de vérité
• Sécurité : un seul composant à sécuriser pour protéger etcd
• Simplicité : les autres composants n’ont pas besoin de connaître etcd

Vérifier l’état de l’API Server

# Voir le pod de l'API Server
kubectl get pod -n kube-system -l component=kube-apiserver

# Vérifier la santé de l'API
kubectl get --raw='/healthz'
# Résultat attendu : ok

etcd : la mémoire du cluster

etcd est une base de données clé-valeur distribuée qui stocke tout l’état du cluster. C’est la “source de vérité” de Kubernetes.

Ce que stocke etcd

Type de données	Exemples
Configuration du cluster	Nodes, namespaces, RBAC
État des ressources	Pods, Deployments, Services, ConfigMaps
Données sensibles	Secrets (chiffrés)
Métadonnées	Labels, annotations

Glissez pour voir

Pourquoi etcd est critique

Si etcd est perdu sans backup, le cluster devient irrécupérable. Vous perdez :

• La liste de tous vos Deployments
• La configuration de tous vos Services
• Tous vos Secrets et ConfigMaps
• L’historique des ReplicaSets

Toujours sauvegarder etcd

En production, sauvegardez etcd régulièrement. Les clusters managés (EKS, GKE, AKS) le font automatiquement. Pour un cluster kubeadm :

ETCDCTL_API=3 etcdctl snapshot save backup.db \
  --endpoints=https://127.0.0.1:2379 \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/server.crt \
  --key=/etc/kubernetes/pki/etcd/server.key

Vérifier l’état d’etcd

# Voir le pod etcd
kubectl get pod -n kube-system -l component=etcd

# Lister les clés stockées (attention, très verbeux !)
kubectl exec -n kube-system etcd-<node> -- etcdctl \
  --endpoints=https://127.0.0.1:2379 \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/server.crt \
  --key=/etc/kubernetes/pki/etcd/server.key \
  get / --prefix --keys-only | head -20

Le Scheduler : le stratège du placement

Le kube-scheduler décide où déployer chaque Pod. Il analyse les besoins du Pod et les ressources disponibles sur chaque Node.

Comment le Scheduler travaille

Le Scheduler suit un processus en deux étapes :

1. Filtrage : éliminer les Nodes impossibles

   Le Scheduler exclut les Nodes qui ne peuvent pas accueillir le Pod :

   • Pas assez de CPU ou mémoire
   • Taints incompatibles
   • Contraintes d’affinité non respectées

2. Scoring : classer les Nodes restants

   Parmi les Nodes possibles, le Scheduler attribue un score selon :

   • Répartition de charge (spread)
   • Affinités préférées
   • Ressources disponibles

Ce que le Scheduler NE fait PAS

Le Scheduler n’exécute pas les conteneurs. Il écrit simplement dans etcd (via l’API Server) : “ce Pod est assigné à ce Node”. C’est tout.

# Le Scheduler ne fait que ça : assigner un nodeName
spec:
  nodeName: worker-node-1   # ← Écrit par le Scheduler

Ensuite, le Kubelet du Node concerné détecte cette assignation et lance le conteneur.

Communication du Scheduler

Le Scheduler communique exclusivement via l’API Server :

1. Il “watch” les Pods sans nodeName (Pods non assignés)
2. Il calcule le meilleur Node
3. Il écrit le binding (Pod → Node) dans l’API Server
4. L’API Server persiste dans etcd

Jamais de communication directe avec les Kubelets ou etcd.

Le Controller Manager : la boucle de contrôle

Le kube-controller-manager est le composant qui fait la magie de Kubernetes : il réconcilie en permanence l’état souhaité avec l’état actuel.

La boucle de contrôle : watch → compare → act

Le Controller Manager exécute une boucle infinie pour chaque type de ressource :

Étape	Action	Exemple
WATCH	Observer l’état via l’API Server	”Je vois 2 Pods nginx running”
COMPARE	Comparer avec l’état souhaité	”L’utilisateur veut 3 répliques”
ACT	Corriger l’écart	”Je crée 1 Pod supplémentaire”

Glissez pour voir

Cette boucle tourne en continu, sans intervention humaine. C’est ce qui permet à Kubernetes de “se réparer tout seul”.

Le Controller Manager agit en permanence

Contrairement à ce qu’on pourrait penser, le kube-controller-manager n’agit pas uniquement quand un utilisateur interagit. Il surveille et corrige les écarts en permanence, même si personne ne touche au cluster. Un Pod qui crashe à 3h du matin sera recréé automatiquement.

Les contrôleurs regroupés

Le Controller Manager regroupe plusieurs contrôleurs spécialisés dans un seul processus :

Contrôleur	Responsabilité
Deployment Controller	Gère les rolling updates, rollbacks
ReplicaSet Controller	Maintient le nombre de répliques
Node Controller	Détecte les Nodes en panne
Job Controller	Gère les Jobs et leur complétion
Service Account Controller	Crée les comptes de service par défaut
Endpoints Controller	Maintient les endpoints des Services

Glissez pour voir

Le Controller Manager ne touche pas etcd

Comme les autres composants, le Controller Manager passe par l’API Server pour toute lecture ou écriture. Il ne communique jamais directement avec etcd.

Controller Manager → API Server → etcd
                  ↓
              (jamais direct)

Le cloud-controller-manager (optionnel)

Le cloud-controller-manager est un composant optionnel qui n’existe que sur les clusters déployés chez un fournisseur cloud (AWS, GCP, Azure, etc.).

Quand il est présent

Environnement	cloud-controller-manager ?
EKS, GKE, AKS	✅ Oui (géré automatiquement)
kubeadm sur VMs cloud	✅ Oui (à installer)
kubeadm bare-metal	❌ Non
Minikube, kind	❌ Non

Glissez pour voir

Ce qu’il gère

Le cloud-controller-manager contient des contrôleurs spécifiques au cloud :

Contrôleur	Rôle	Exemple concret
Node Controller	Vérifie si les VMs existent	Si une VM AWS est supprimée, met à jour le cluster
Route Controller	Configure les routes réseau	Crée les règles de routage entre sous-réseaux
Service Controller	Gère les Load Balancers	Crée un ELB quand vous déclarez type: LoadBalancer

Glissez pour voir

Service LoadBalancer sans cloud-controller-manager

Sans cloud-controller-manager, un Service de type LoadBalancer reste en état Pending indéfiniment :

kubectl get svc
# NAME    TYPE           CLUSTER-IP    EXTERNAL-IP   PORT(S)
# myapp   LoadBalancer   10.96.0.1     <pending>     80:30000/TCP

C’est normal sur un cluster local (Minikube, kubeadm bare-metal). Utilisez NodePort ou un ingress controller à la place.

Communication entre composants : le modèle pull

Un point essentiel de l’architecture Kubernetes : les Kubelets fonctionnent en mode “pull”.

Ce que signifie le modèle pull

❌ Modèle push (ce que Kubernetes NE fait PAS)

API Server --push--> Kubelet
"Hé Kubelet, lance ce Pod !"

Problème : si l’API Server est surchargé ou injoignable, les ordres ne passent pas.

✅ Modèle pull (ce que Kubernetes FAIT)

Kubelet --interroge--> API Server
"Quels Pods dois-je faire tourner ?"

Avantage : si l’API Server est temporairement injoignable, le Kubelet continue de faire tourner les Pods existants.

Résilience grâce au modèle pull

Le modèle pull apporte une résilience majeure : si le Control Plane tombe temporairement, les Kubelets continuent de faire tourner les Pods existants. Ils ne peuvent juste pas recevoir de nouvelles instructions. Vos applications restent disponibles !

Résumé des flux de communication

Composant	Communique avec	Via
kubectl	API Server	Requêtes HTTPS
Scheduler	API Server	Watch + Update
Controller Manager	API Server	Watch + Update
Kubelet	API Server	Watch + Report
API Server	etcd	Lecture/Écriture directe

Glissez pour voir

Tous passent par l’API Server, sauf l’API Server lui-même qui accède à etcd.

Flux complet : du kubectl au conteneur

Voici ce qui se passe quand vous créez un Deployment :

1. Vous envoyez la requête

   kubectl apply -f deployment.yaml

   kubectl envoie la requête HTTPS à l’API Server.

2. L’API Server valide et persiste

   • Authentification : qui êtes-vous ?
   • Autorisation : avez-vous le droit ?
   • Admission : la requête est-elle valide ?
   • Stockage dans etcd

3. Le Deployment Controller réagit

   Il détecte le nouveau Deployment et crée un ReplicaSet.

4. Le ReplicaSet Controller crée des Pods

   Il voit que le ReplicaSet demande 3 répliques, crée 3 Pods (sans nodeName).

5. Le Scheduler assigne les Pods

   Il détecte les Pods sans nodeName, calcule les meilleurs Nodes, écrit les assignations.

6. Les Kubelets lancent les conteneurs

   Chaque Kubelet détecte les Pods assignés à son Node et demande au container runtime (containerd) de lancer les conteneurs.

Contrôle de connaissances

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

10 questions

5 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

À retenir

• Seul l’API Server accède à etcd — tous les autres composants passent par l’API Server
• Le Scheduler assigne, le Kubelet lance — le Scheduler ne lance jamais de conteneurs
• Le Controller Manager tourne en permanence — pas seulement quand un utilisateur agit
• Le modèle pull rend le cluster résilient — les Kubelets interrogent l’API Server, pas l’inverse
• Le Controller Manager regroupe plusieurs contrôleurs — Deployment, ReplicaSet, Node, Job…
• Le cloud-controller-manager est optionnel — uniquement sur clusters cloud
• etcd est critique — sauvegardez-le régulièrement

Prochaines étapes

Worker Nodes Découvrez les composants qui exécutent vos conteneurs

Pods Kubernetes Comprendre l'unité de base de Kubernetes

Deployments Déployer et mettre à jour vos applications

Services Exposer vos applications dans le cluster

×

📖 Voir la documentation →