Control Plane Kubernetes : API Server, etcd, Scheduler

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 détaille le fonctionnement du Control Plane, l'ensemble des processus qui décident de l'état du cluster sans jamais exécuter vos applications. Vous comprendrez pourquoi vos applications restent disponibles quand un Pod crashe, et par quel mécanisme Kubernetes détermine 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 regroupe les processus qui décident de l'état du cluster. Il prend toutes les décisions mais ne fait jamais tourner vos conteneurs applicatifs : ceux-ci s'exécutent sur les Worker Nodes. Son seul travail est d'orchestrer, c'est-à-dire enregistrer ce que vous demandez, décider où le placer et corriger les écarts.

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

Ces deux commandes ne répondent pas à la même question. La première cherche le Pod qui héberge l'API Server, la seconde interroge l'endpoint de santé exposé par l'API elle-même. Sur un cluster de découverte, seule la seconde est fiable : /healthz renvoie la chaîne ok dès que l'API répond, quelle que soit la distribution.

# Voir le pod de l'API Server (clusters kubeadm)
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

Pas de Pod API Server sur k3s, k3d ou minikube

La commande kubectl get pod -n kube-system -l component=kube-apiserver renvoie No resources found in kube-system namespace. sur ces distributions, et c'est normal. Elles regroupent API Server, Scheduler et Controller Manager dans un processus unique, il n'existe donc aucun Pod statique à lister. Les Pods kube-apiserver-<node> et etcd-<node> du namespace kube-system sont une particularité des clusters installés avec kubeadm, où chaque composant tourne dans son propre Pod statique. Pour tester la disponibilité de l'API partout, préférez /healthz, /readyz ou /livez, qui renvoient tous les trois ok.

etcd : la source de vérité 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

Tout ce que vous pouvez lister avec kubectl get se trouve dans etcd, et rien d'autre : ni les logs de vos conteneurs, ni les métriques, ni les images. La ligne à retenir est la troisième, parce qu'elle est contre-intuitive. Par défaut, les Secrets ne sont pas chiffrés dans etcd, ils y sont seulement encodés en base64, ce qui n'est pas une protection. La documentation Kubernetes l'écrit noir sur blanc : « Kubernetes Secrets are, by default, stored unencrypted in the API server's underlying data store (etcd) ». Le chiffrement au repos s'active explicitement, via une EncryptionConfiguration passée à l'API Server.

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

Glissez pour voir

Un Secret n'est pas chiffré par défaut

Quiconque a accès à etcd, ou dispose d'un accès API suffisant, peut lire vos Secrets en clair. Deux mesures se posent ensemble : activer le chiffrement au repos (Encrypting Confidential Data at Rest) et restreindre les droits de lecture sur les Secrets avec RBAC. Sans ces deux garde-fous, un base64 -d suffit à récupérer un mot de passe.

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

La seconde commande vous montre la structure réelle des données du cluster : des chemins du type /registry/pods/default/nginx. C'est instructif une fois, pour constater que Kubernetes n'a pas de schéma relationnel, seulement un arbre de clés. Retenez surtout la présence des trois options --cacert, --cert et --key : etcd n'accepte que des clients authentifiés en TLS mutuel, et ces chemins sont ceux d'un cluster kubeadm. Comme la section précédente, ces commandes ne s'appliquent pas à k3s, k3d ou minikube.

# 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 choix du Node

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 rend Kubernetes auto-correctif : 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

La question à se poser est simple : votre cluster a-t-il besoin de créer des ressources chez un fournisseur ? Un load balancer, une route, un disque. Si oui, il lui faut ce composant et les droits IAM associés ; sinon, il est inutile. Le tableau ci-dessous se lit avec cette grille. Sur les offres managées, vous n'avez rien à faire, il est déjà là. Sur un cluster que vous installez vous-même dans le cloud, c'est à vous de le déployer, et son absence est la cause la plus fréquente d'un Service bloqué en Pending.

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

Le point qui distingue les deux onglets est le sens de la connexion réseau. Dans un modèle push, c'est le Control Plane qui ouvre une connexion vers chaque Node ; il doit donc pouvoir les joindre en permanence, et chaque Node doit exposer un port. Dans le modèle pull retenu par Kubernetes, ce sont les Kubelets qui appellent l'API Server. Cela a deux conséquences directes : les Nodes n'ont besoin d'aucun port entrant depuis le Control Plane, et une panne du Control Plane ne coupe pas les applications déjà lancées.

Modèle push (ce que Kubernetes ne fait pas)

API Server --push--> Kubelet
"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

Les dix questions ci-dessous portent sur les points où les erreurs sont les plus tenaces : qui accède à etcd, qui lance réellement les conteneurs, et dans quel sens circulent les communications. Le seuil de réussite est de 70 % ; en dessous, relisez la section sur les flux de communication, qui concentre à elle seule la moitié des confusions.

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

Pour aller plus loin

• etcd : Le fonctionnement interne du magasin clé/valeur dont dépend tout le control plane.
• Haute disponibilité du Control Plane : Le passage de un à trois nœuds de contrôle, et le quorum qui va avec.
• Backup et Restore : La sauvegarde d'etcd, seul filet de sécurité quand le control plane tombe.
• Troubleshooting cluster : Le diagnostic d'un API Server ou d'un Scheduler qui ne répond plus.

×

📖 Voir la documentation →