Un cluster Kubernetes est un ensemble de processus qui coopèrent. Savoir ce que fait chacun rend tout le reste, de la planification au dépannage, plus facile à comprendre. Ce guide nomme les composants, puis suit une seule requête jusqu’à un conteneur en cours d’exécution.

Plan de contrôle et nœuds de travail

Le plan de contrôle prend les décisions concernant le cluster. Les nœuds de travail exécutent vos charges de travail. Dans un cluster local comme minikube, un seul nœud joue les deux rôles. Les clusters de production ont généralement plusieurs nœuds de plan de contrôle pour la disponibilité : si vous perdez le seul existant, vous ne pouvez plus rien modifier dans le cluster, même si les charges de travail déjà en cours continuent généralement de tourner un certain temps. Les nœuds du plan de contrôle sont normalement marqués d’un taint pour que vos Pods applicatifs n’y soient pas planifiés.

Composants du plan de contrôle

• kube-apiserver est la porte d’entrée. Tous les clients (kubectl, tableaux de bord, scripts et les autres composants) lui parlent via une API HTTP. Il authentifie et autorise les requêtes, valide les objets, et c’est le seul composant qui lit et écrit dans etcd.
• etcd est un magasin clé-valeur cohérent qui contient tout l’état du cluster : quels nœuds existent, quels Pods doivent tourner, leur statut actuel. Considérez-le comme la mémoire du cluster. Sauvegardez-le, car le perdre signifie perdre la trace de tout.
• kube-scheduler choisit un nœud pour chaque Pod qui n’en a pas encore, en fonction des requests de ressources, des contraintes et de la capacité disponible.
• kube-controller-manager exécute les controllers, ces boucles de contrôle qui comparent l’état souhaité et l’état réel et agissent sur la différence. Les controllers Deployment, ReplicaSet et Node y résident.
• cloud-controller-manager (uniquement chez les fournisseurs cloud) s’intègre avec le fournisseur pour des éléments comme les load balancers et le cycle de vie des nœuds.

Composants des nœuds

• kubelet est l’agent présent sur chaque nœud. Il surveille les Pods assignés à son nœud, s’assure que leurs conteneurs tournent et sont sains, et remonte leur statut.
• Le runtime de conteneurs exécute réellement les conteneurs. C’est généralement containerd ou CRI-O, connectés via la Container Runtime Interface. Kubernetes ne communique plus directement avec Docker Engine (dockershim a été supprimé dans la version 1.24), mais les images construites avec Docker fonctionnent toujours, car les images suivent le standard ouvert OCI.
• kube-proxy maintient sur chaque nœud les règles réseau qui permettent aux adresses des Services d’atteindre les bons Pods.
• Un plugin réseau (CNI) donne aux Pods leurs adresses IP et leur connectivité entre les nœuds.

Suivre une requête de kubectl apply jusqu’à un conteneur en cours d’exécution

Supposons que vous appliquiez un manifeste de Deployment. Voici ce qui se passe :

1. kubectl lit votre kubeconfig et envoie le manifeste à l’API server via HTTPS.
2. L’API server vous authentifie et vous autorise, valide l’objet, le stocke dans etcd et répond.
3. Le controller Deployment remarque le nouveau Deployment et crée un ReplicaSet, puis le controller ReplicaSet crée les objets Pod. À ce stade, les Pods existent mais ne sont pas assignés à un nœud.
4. Le scheduler remarque les Pods sans nœud, en choisit un pour chacun et enregistre cette décision via l’API server.
5. Le kubelet du nœud choisi voit un Pod qui lui est assigné et demande au runtime de conteneurs de télécharger l’image et de démarrer les conteneurs.
6. Le kubelet remonte l’avancement à l’API server, qui le stocke dans etcd. C’est ce que lit kubectl get pods.

Remarquez que les composants ne s’appellent jamais directement. Chacun surveille l’API server pour les objets qui l’intéressent et réagit. Ce couplage faible explique pourquoi vous pouvez redémarrer la plupart des composants sans rien perdre : l’état dont ils ont besoin est dans etcd.

Vous pouvez voir la séquence dans les événements enregistrés par Kubernetes :

kubectl create deployment demo --image=nginx:1.25
kubectl get events --sort-by=.metadata.creationTimestamp

Cherchez Scheduled, Pulling, Pulled, Created et Started. C’est le scheduler et le kubelet qui font leur part.

Observer les composants dans votre propre cluster

kubectl get nodes -o wide
kubectl get pods -n kube-system

Sur minikube et les clusters construits avec kubeadm, vous verrez les composants du plan de contrôle s’exécuter comme des Pods dans le namespace kube-system, aux côtés de kube-proxy et du plugin réseau. Sur les services managés (EKS, GKE, AKS), le fournisseur exécute le plan de contrôle pour vous et vous ne voyez que vos nœuds de travail.

Ce que cette conception implique en pratique

• L’API server est le goulot d’étranglement. Tout y passe : le sécuriser et le dimensionner est important.
• La santé d’etcd, c’est la santé du cluster. Sauvegardez-le et, en production, exécutez-le de façon redondante.
• Les défaillances sont attendues. Un nœud mort, un composant planté ou un Pod supprimé n’est qu’une différence entre l’état souhaité et l’état réel qu’un controller finira par corriger.