L'architecture de Kubernetes : plan de contrôle, nœuds, API

Avant de taper la moindre commande kubectl, il faut savoir à qui on parle. Kubernetes n'est pas un programme unique : c'est un ensemble de composants qui coopèrent, chacun avec un rôle précis. Quand quelque chose ne marche pas, savoir quel composant fait quoi est ce qui vous permet de chercher au bon endroit.

Ce que vous saurez à la fin : expliquer ce qui se passe entre le moment où vous tapez kubectl apply et celui où votre conteneur tourne, nommer chaque composant et dire ce qui arrive quand l'un d'eux tombe.

Le problème que Kubernetes résout

Faire tourner un conteneur sur une machine, Docker le fait très bien. Les vraies questions arrivent à l'échelle :

• Vous avez 30 conteneurs et 5 machines : où placer chacun ?
• Une machine tombe à 3 h du matin : qui relance ses conteneurs ailleurs ?
• Vous passez de la version 1.4 à la 1.5 : comment remplacer les conteneurs sans couper le service ?
• Le trafic double : qui ajoute des copies, et comment le trafic les trouve-t-il ?

Kubernetes est un orchestrateur : il répond à ces questions à votre place, en continu.

L'idée centrale : l'état désiré

Avec Kubernetes, on ne donne pas d'ordres (« démarre ce conteneur »). On décrit l'état voulu (« je veux 3 copies de nginx 1.27 »), et Kubernetes travaille sans arrêt pour que la réalité corresponde à cette description.

C'est ce qu'on appelle une boucle de réconciliation :

   ┌──────────────────────────────────────────────┐
   │  1. Observer : combien de copies tournent ?  │
   │  2. Comparer : j'en veux 3, il y en a 2      │
   │  3. Agir     : en créer 1                    │
   └───────────────── et recommencer ────────────┘

Cette boucle tourne en permanence. Si vous supprimez une copie à la main, elle revient. Si une machine meurt, ses copies sont recréées ailleurs. Vous ne « lancez » pas une application : vous la déclarez, et Kubernetes la maintient.

Vue d'ensemble : un cluster

Un cluster Kubernetes se compose de deux parties :

┌─────────────────── PLAN DE CONTRÔLE (le cerveau) ───────────────────┐
│                                                                     │
│   kube-apiserver  ◄──►  etcd                                        │
│        ▲                                                            │
│        ├── kube-scheduler                                           │
│        └── kube-controller-manager                                  │
└────────┼────────────────────────────────────────────────────────────┘
         │  (tout passe par l'API)
┌────────┼──────────── NŒUDS (les bras) ──────────────────────────────┐
│        ▼                                                            │
│   nœud 1 : kubelet + runtime de conteneurs + kube-proxy → pods      │
│   nœud 2 : kubelet + runtime de conteneurs + kube-proxy → pods      │
└─────────────────────────────────────────────────────────────────────┘

• Le plan de contrôle (control plane) prend les décisions.
• Les nœuds (nodes, aussi appelés workers) font tourner vos applications.

Le plan de contrôle, composant par composant

kube-apiserver : la porte d'entrée unique

C'est le seul composant auquel tout le monde parle : vous (via kubectl), les autres composants, les nœuds. Il :

• reçoit les requêtes (créer un pod, lister des services…) ;
• vérifie qui vous êtes (authentification) et ce que vous avez le droit de faire (autorisation) ;
• valide l'objet (un champ inconnu, une valeur impossible → refus) ;
• l'enregistre dans etcd.

Retenez-le : aucun composant ne parle directement à un autre. Tout passe par l'API. C'est ce qui rend Kubernetes cohérent et extensible.

etcd : la mémoire du cluster

Une base de données clé-valeur, distribuée et fiable. Elle contient tout l'état du cluster : chaque pod, chaque service, chaque secret. Seul l'apiserver lui parle.

Si etcd est perdu sans sauvegarde, le cluster a perdu la mémoire : les conteneurs peuvent continuer à tourner un moment, mais plus personne ne sait ce qu'ils sont censés être. C'est pourquoi sauvegarder etcd est une tâche d'administration essentielle.

kube-scheduler : celui qui choisit le nœud

Quand un pod est créé, il n'est d'abord affecté à aucun nœud : il est Pending. Le scheduler le remarque et choisit le meilleur nœud selon :

• les ressources demandées (le pod veut 200 Mo, quel nœud les a ?) ;
• les contraintes (« seulement sur un nœud avec un SSD », « pas sur le même nœud que ce pod-là »).

Il écrit sa décision dans l'API, sans rien démarrer lui-même. Un pod qui reste Pending indéfiniment, c'est souvent que le scheduler ne trouve aucun nœud qui convient : kubectl describe pod vous dira pourquoi.

kube-controller-manager : les boucles de réconciliation

Il regroupe des dizaines de contrôleurs, chacun responsable d'un type d'objet :

• le contrôleur de ReplicaSet veille à ce que le bon nombre de copies existe ;
• le contrôleur de Deployment orchestre les mises à jour progressives ;
• le contrôleur de nœuds remarque quand un nœud ne répond plus ;
• le contrôleur de Jobs relance les tâches qui échouent…

Chacun applique la même boucle : observer, comparer, agir.

Dans le cloud, on trouve aussi un cloud-controller-manager, qui crée chez le fournisseur les répartiteurs de charge ou les disques demandés par le cluster.

Les nœuds, composant par composant

kubelet : l'agent sur chaque nœud

Le kubelet surveille l'API : « quels pods m'ont été affectés ? ». Pour chacun, il demande au runtime de démarrer les conteneurs, vérifie qu'ils restent en bonne santé (les sondes), et remonte leur état à l'API.

Le kubelet ne gère que les pods créés via Kubernetes : un conteneur lancé à la main sur le nœud lui est inconnu.

Le runtime de conteneurs

C'est lui qui démarre réellement les conteneurs : containerd ou CRI-O le plus souvent. Le kubelet lui parle à travers une interface standard, la CRI (Container Runtime Interface). Kubernetes ne dépend donc d'aucun runtime en particulier.

Sur KubeNow, vos pods tournent sous gVisor, un runtime qui intercale un noyau isolé entre vos conteneurs et le serveur. C'est grâce à lui que des centaines d'élèves peuvent partager la même machine en sécurité.

kube-proxy : le réseau des Services

Il programme les règles réseau du nœud pour que l'adresse stable d'un Service mène bien vers l'un des pods qui sont derrière. Certains plugins réseau modernes le remplacent complètement.

Le parcours d'une commande, de bout en bout

Que se passe-t-il quand vous tapez kubectl create deployment web --image=nginx --replicas=2 ?

1. kubectl transforme la commande en requête HTTPS vers l'apiserver.
2. L'apiserver vous authentifie, vérifie vos droits, valide le Deployment et l'écrit dans etcd.
3. Le contrôleur de Deployment voit le nouveau Deployment et crée un ReplicaSet.
4. Le contrôleur de ReplicaSet voit qu'il faut 2 pods et en crée 2 (encore sans nœud : Pending).
5. Le scheduler voit 2 pods sans nœud et choisit un nœud pour chacun.
6. Le kubelet de chaque nœud choisi voit qu'un pod lui est affecté, demande au runtime de télécharger l'image et de démarrer le conteneur.
7. Le kubelet remonte l'état : le pod passe Running.

Remarquez que personne ne se donne d'ordre : chaque composant observe l'API et réagit à ce qui le concerne. Si le scheduler est en panne, les pods restent Pending ; dès qu'il revient, il rattrape son retard.

Que se passe-t-il quand…

Panne	Conséquence immédiate	Ce qui continue
l'apiserver tombe	kubectl ne répond plus, plus aucun changement possible	les pods déjà lancés continuent de tourner
le scheduler tombe	les nouveaux pods restent Pending	tout ce qui tourne déjà
le controller-manager tombe	plus de réparation automatique, plus de mise à l'échelle	les pods existants
un nœud tombe	après un délai, ses pods sont recréés sur d'autres nœuds (s'ils sont gérés par un Deployment)	le reste du cluster
etcd est perdu sans sauvegarde	le cluster perd tout son état	rien de fiable

C'est pour cela qu'en production, le plan de contrôle est répliqué (souvent 3 copies, nombre impair pour etcd), et qu'on n'y fait pas tourner d'applications.

Les objets de l'API

Tout ce que vous manipulez est un objet de l'API, décrit en YAML avec la même structure :

apiVersion: apps/v1     # groupe et version de l'API
kind: Deployment        # type d'objet
metadata:               # identité : nom, namespace, labels
  name: web
spec:                   # l'état DÉSIRÉ (écrit par vous)
  replicas: 2
status:                 # l'état RÉEL (écrit par Kubernetes)
  readyReplicas: 2

spec contre status : c'est la boucle de réconciliation écrite noir sur blanc. Vous écrivez spec, les contrôleurs font tout pour que status le rejoigne.

Et sur KubeNow ?

Votre environnement est un cluster virtuel (vCluster) : un plan de contrôle complet (apiserver, controller-manager, base de données) qui tourne lui-même dans un pod du vrai cluster. Vos pods sont exécutés sur les nœuds du cluster hôte. Pour vous, c'est un cluster Kubernetes standard : mêmes commandes, même API. C'est ce qui permet de vous en donner un en quelques secondes.

À retenir

• Kubernetes maintient un état désiré grâce à des boucles de réconciliation.
• Plan de contrôle : apiserver (porte d'entrée unique), etcd (mémoire), scheduler (placement), controller-manager (réconciliation).
• Nœuds : kubelet (agent), runtime de conteneurs (via la CRI), kube-proxy (réseau des Services).
• Tout passe par l'API, aucun composant ne parle directement à un autre.
• spec = ce que vous voulez, status = ce qui est.

Quand vous êtes prêt, passez le QCM : les questions ne reprennent pas le texte mot pour mot, elles vous demandent de raisonner sur des situations.