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. Son travail est d'orchestrer : enregistrer ce que vous demandez, décider où le placer et corriger les écarts. En pratique, vos applications ne s'y déploient pas, une marque posée sur ce nœud en écartant les Pods ordinaires. C'est une protection, pas une impossibilité technique : un Pod explicitement autorisé à passer outre peut y tourner, et c'est ainsi que les composants de Kubernetes eux-mêmes y sont placés.

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

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

Son travail tient en trois temps, toujours les mêmes quelle que soit la requête :

1. Valider : vérifier le format, l'authentification, les autorisations
2. Persister : stocker l'état dans etcd, ce que lui seul fait
3. Exposer : permettre de relire cet état via l'API REST

C'est cette validation systématique qui fait de lui le gardien du cluster.

# 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 :

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

La première commande ne fonctionne que si vous administrez le control plane. C'est le cas avec Kind ou kubeadm, où chaque composant tourne dans son propre Pod statique. Sur un cluster managé (EKS, GKE, AKS), le fournisseur exploite le control plane pour vous et ne l'expose pas : la commande renvoie No resources found, et ce n'est pas une panne.

C'est pourquoi le contrôle de santé se fait sur /healthz, /readyz ou /livez : ils répondent ok partout, quelle que soit la façon dont le cluster a été installé.

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

Sauvegardez etcd régulièrement. C'est la seule protection contre la perte du cluster, et c'est aussi ce qui distingue un cluster que vous administrez d'un cluster managé : chez EKS, GKE ou AKS, le fournisseur s'en charge sans que vous ayez à y penser. La procédure, ses certificats et la restauration sont détaillés dans le guide etcd.

Vérifier qu'etcd répond

Sur un cluster que vous administrez, etcd tourne comme un Pod du namespace kube-system, au même titre que les autres composants :

kubectl get pod -n kube-system -l component=etcd

Sur un cluster managé, cette commande ne renvoie rien, et ce n'est pas une panne : le fournisseur n'expose pas son control plane.

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 écarte d'emblée les nœuds qui ne peuvent pas accueillir le Pod. Trois motifs suffisent à disqualifier un candidat :

   • Pas assez de CPU ou de mémoire disponible
   • Taints incompatibles avec les tolerations du Pod
   • 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.

La preuve tient en une commande. Créez un Pod qu'aucun nœud ne peut accueillir, et regardez ce que le Scheduler écrit :

kubectl get pod impossible -o custom-columns='POD:.metadata.name,STATUS:.status.phase,NODE:.spec.nodeName'
kubectl get events --field-selector involvedObject.name=impossible

Sortie

POD          STATUS    NODE
impossible   Pending   <none>

0/2 nodes are available: 1 node(s) didn't match Pod's node affinity/selector,
1 node(s) had untolerated taint(s).

Le champ nodeName reste vide : le Scheduler n'a rien écrit, donc aucun Kubelet ne se sent concerné, et le Pod attend. Le message dit exactement combien de nœuds ont été écartés et pourquoi, ce qui en fait la première chose à lire devant un Pod Pending.

Communication du Scheduler

Le Scheduler communique exclusivement via l'API Server :

1. Il observe en continu les Pods sans nodeName, donc non assignés
2. Il calcule le meilleur nœud pour chacun
3. Il écrit l'association entre le Pod et le nœud dans l'API Server
4. L'API Server la 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".

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 le comportement normal sur un cluster local comme celui de cette formation. Mesuré sur kind : le Service obtient bien une CLUSTER-IP et un port de nœud, mais son EXTERNAL-IP reste <pending> indéfiniment. Passez par NodePort ou kubectl port-forward.

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. Conséquence directe : une panne du Control Plane ne coupe pas les applications déjà lancées, puisque chaque Kubelet continue de faire tourner ce qu'il a reçu.

Attention toutefois à ne pas en conclure que le trafic ne va jamais dans l'autre sens. Le sens Control Plane vers Node existe bel et bien, pour un ensemble de gestes précis : kubectl logs, kubectl exec, kubectl port-forward et le proxy de nœud passent par une connexion que l'API Server ouvre vers le Kubelet, sur le port 10250. C'est pourquoi le manifeste de l'API Server porte un certificat client dédié, apiserver-kubelet-client.crt. Un pare-feu qui bloquerait ce port laisserait le cluster fonctionner, mais rendrait kubectl logs et kubectl exec inopérants.

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