L'architecture d'un cluster

Pourquoi

La leçon 1 a posé le principe : on déclare un état voulu, des contrôleurs le réalisent. Mais quand une commande kubectl apply échoue, quand un Pod reste en attente sans raison apparente, quand un nœud disparaît et que rien ne se passe pendant cinq minutes, ce principe ne suffit plus. Il faut savoir quel composant fait quoi, dans quel ordre, et qui parle à qui.

Le diagnostic d'un cluster Kubernetes est presque toujours une question d'architecture : un Pod Pending concerne l'ordonnanceur ; un Pod qui ne démarre pas sur son nœud concerne le kubelet et le runtime ; un Service qui ne répond pas concerne kube-proxy ou le plugin réseau ; une commande refusée concerne l'authentification, l'autorisation ou l'admission. Cette leçon donne la carte. La leçon 12 s'en servira pour diagnostiquer.

C'est aussi cette carte qui permet de comprendre une offre managée : ce que le fournisseur exploite pour vous, et ce qui reste de votre ressort.

Les concepts

Deux moitiés : le plan de contrôle et les nœuds

Un cluster Kubernetes se divise en deux :

• le plan de contrôle (control plane), qui stocke l'état voulu, prend les décisions et pilote l'ensemble ;
• les nœuds (nodes, autrefois workers), les machines physiques ou virtuelles sur lesquelles tournent réellement les conteneurs.

On retrouve la distinction entre plan de contrôle et plan de données du cours cloud : si le plan de contrôle tombe, les conteneurs déjà lancés continuent de tourner et de servir du trafic ; on ne peut simplement plus rien changer, et plus rien n'est réparé.

    flowchart TB
  subgraph PC["Plan de contrôle"]
    API["kube-apiserver"]
    ETCD[("etcd")]
    SCH["kube-scheduler"]
    CM["kube-controller-manager"]
    CCM["cloud-controller-manager"]
    API --- ETCD
    SCH --> API
    CM --> API
    CCM --> API
  end
  subgraph N1["Nœud"]
    K1["kubelet"] --> R1["runtime (containerd)"]
    P1["kube-proxy"]
  end
  subgraph N2["Nœud"]
    K2["kubelet"] --> R2["runtime (containerd)"]
    P2["kube-proxy"]
  end
  U["kubectl"] --> API
  K1 --> API
  K2 --> API
  P1 --> API
  P2 --> API
  

Remarquez la forme du schéma : toutes les flèches vont vers le serveur d'API. Aucun composant ne parle directement à un autre, et seul le serveur d'API parle à etcd. C'est la propriété la plus importante de l'architecture.

Le plan de contrôle

kube-apiserver, le serveur d'API, expose l'API HTTP de Kubernetes. C'est la seule porte d'entrée : kubectl, les contrôleurs, l'ordonnanceur, les kubelets, Argo CD, tous lisent et écrivent par lui. Il authentifie, autorise, valide chaque requête, puis enregistre le résultat dans etcd. Il est sans état : on peut en faire tourner plusieurs exemplaires derrière un répartiteur de charge.

etcd est une base clé-valeur cohérente et hautement disponible qui contient tout l'état du cluster : chaque objet, chaque Secret, chaque statut. Perdre etcd sans sauvegarde, c'est perdre le cluster (pas les conteneurs en cours, mais toute la connaissance de ce qui doit exister). Ses membres s'accordent par le protocole de consensus Raft : une écriture n'est validée que si une majorité de membres l'a enregistrée.

kube-scheduler, l'ordonnanceur, cherche les Pods qui n'ont pas encore de nœud et en choisit un pour chacun. Il ne lance rien : il écrit sa décision (le nom du nœud) dans l'objet Pod, par l'API. La leçon 8 détaille ses critères.

kube-controller-manager fait tourner, dans un seul processus, la plupart des contrôleurs intégrés : Deployments, ReplicaSets, Jobs, nœuds, comptes de service, et d'autres. Chacun est une boucle de réconciliation au sens de la leçon 1.

cloud-controller-manager, facultatif, relie le cluster au fournisseur de cloud : il crée un répartiteur de charge du fournisseur quand on déclare un Service de type LoadBalancer (leçon 6), retire un nœud du cluster quand l'instance correspondante a été supprimée, etc. Chez Scaleway, c'est lui qui crée un Load Balancer Scaleway pour un Service Kapsule.

Les nœuds

kubelet est l'agent de chaque nœud. Il s'enregistre auprès du serveur d'API, surveille les Pods qui lui sont attribués, et s'assure que leurs conteneurs tournent, en demandant au runtime de les créer, de les arrêter, de les redémarrer. Il exécute aussi les sondes de santé (leçon 4) et remonte l'état des Pods et du nœud.

Le runtime de conteneurs fait réellement tourner les conteneurs. Le kubelet lui parle par la CRI (Container Runtime Interface), une interface gRPC ; depuis Kubernetes 1.26, le kubelet exige la version v1 de cette interface et refuse d'enregistrer un nœud dont le runtime ne la parle pas. Le runtime le plus répandu est containerd, que vous avez rencontré sous Docker dans le cours Docker : les fondamentaux ; CRI-O est l'autre grand runtime. Sous containerd, c'est toujours runc qui crée les espaces de noms et les cgroups du conteneur.

kube-proxy programme, sur chaque nœud, les règles réseau qui font fonctionner les Services : il traduit l'adresse virtuelle d'un Service en adresses de Pods (leçon 6). Il a plusieurs modes sous Linux :

La documentation recommande d'indiquer explicitement le mode dans la configuration de kube-proxy, pour qu'il ne change pas à l'occasion d'une montée de version. kube-proxy est d'ailleurs facultatif : certains plugins réseau, comme Cilium, peuvent le remplacer entièrement.

Les modules complémentaires

Un cluster fonctionnel a besoin de quelques composants qui ne font pas partie du cœur, mais tournent eux-mêmes comme des Pods :

• CoreDNS, le serveur DNS du cluster, qui donne un nom à chaque Service (leçon 6) ;
• un plugin réseau CNI (Container Network Interface), qui donne une adresse IP à chaque Pod et assure le routage entre Pods de nœuds différents. Les plus courants sont Cilium et Calico ; kind installe le sien, kindnet. Chez Scaleway, Kapsule propose Cilium (le choix par défaut de la CLI scw) ou Calico ;
• metrics-server, qui collecte la consommation de processeur et de mémoire des Pods, nécessaire à kubectl top et à la mise à l'échelle automatique ;
• souvent un contrôleur d'entrée (Traefik chez Lyneko) pour exposer les applications en HTTP (leçon 11).

Tout passe par le serveur d'API

Pourquoi ce choix d'architecture, où rien ne se parle directement ? Les auteurs de Kubernetes, dans l'article Borg, Omega, and Kubernetes, en donnent la logique : un point unique qui valide, autorise et journalise chaque changement, et des composants qui ne se connaissent pas. Les conséquences :

• On peut remplacer ou ajouter un composant sans toucher aux autres : un autre ordonnanceur, un contrôleur de plus (Argo CD), un autre plugin réseau.
• Tout est contrôlé au même endroit : authentification, autorisation, admission, audit.
• etcd n'est jamais exposé qu'au serveur d'API.

Mais si les composants ne se parlent pas, comment l'ordonnanceur apprend-il qu'un nouveau Pod attend ? Il ne demande pas toutes les secondes la liste de tous les Pods : il surveille (watch). L'API de Kubernetes permet d'ouvrir une requête GET avec le paramètre watch qui reste ouverte et reçoit en flux chaque création, modification ou suppression d'objet. Chaque objet porte une version (resourceVersion) : un composant commence par lister les objets à une version donnée, puis surveille les changements à partir de cette version. S'il est coupé, il reprend là où il en était. C'est ce couple list-watch qui rend possibles les contrôleurs « par niveau » de la leçon 1.

En pratique

Nous allons suivre une commande kubectl apply de bout en bout, puis regarder les composants dans le cluster kind que vous créerez à la leçon 3. Les commandes de cette section qui interrogent un cluster sont expliquées sans reproduire de sortie : vous les lancerez à la leçon suivante.

Le chemin d'un kubectl apply

Reprenons le manifeste signalements-deployment.yaml de la leçon 1 : deux exemplaires de Signalements.

    sequenceDiagram
  participant U as kubectl
  participant A as kube-apiserver
  participant E as etcd
  participant C as contrôleurs
  participant S as kube-scheduler
  participant K as kubelet (nœud)
  participant R as containerd
  U->>A: POST Deployment (TLS + identité)
  A->>A: authentification, autorisation, admission, validation
  A->>E: enregistrer le Deployment
  A-->>U: 201 Created
  C->>A: (watch) nouveau Deployment
  C->>A: créer un ReplicaSet
  C->>A: (watch) nouveau ReplicaSet, créer 2 Pods
  S->>A: (watch) 2 Pods sans nœud
  S->>A: écrire nodeName pour chaque Pod
  K->>A: (watch) un Pod pour mon nœud
  K->>R: CRI : créer le bac à sable, tirer l'image, lancer le conteneur
  K->>A: mettre à jour le statut du Pod
  

Étape par étape :

1. Transport. kubectl lit son fichier kubeconfig (leçon 3), ouvre une connexion TLS vers le serveur d'API (port 6443 par défaut) et envoie le manifeste.
2. Authentification. Le serveur d'API établit qui parle : certificat client, jeton. En cas d'échec, il répond 401.
3. Autorisation. Il vérifie que cette identité a le droit de créer un Deployment dans ce namespace, avec le module RBAC en général. Sinon : 403.
4. Admission. Des contrôleurs d'admission peuvent modifier la requête (ajouter des valeurs par défaut, par exemple), puis la valider ou la refuser selon des règles. Un seul refus suffit à rejeter la requête.
5. Validation et persistance. L'objet est validé contre le schéma de l'API, puis écrit dans etcd. kubectl reçoit la réponse : à ce stade, aucun conteneur n'existe.
6. Contrôleurs. Le contrôleur de Deployments, qui surveille les Deployments, voit le nouveau et crée un ReplicaSet. Le contrôleur de ReplicaSets voit celui-ci et crée deux Pods, sans nœud.
7. Ordonnancement. L'ordonnanceur voit deux Pods sans nœud. Pour chacun, il filtre les nœuds possibles (ressources suffisantes, contraintes), note ceux qui restent, choisit le meilleur et écrit son nom dans le Pod.
8. Exécution. Le kubelet de chaque nœud choisi voit un Pod qui lui est attribué. Il demande au runtime, par la CRI, de créer le bac à sable du Pod (ses espaces de noms, dont le réseau, configuré par le plugin CNI), de tirer l'image et de lancer le conteneur.
9. Statut. Le kubelet remonte l'état du Pod (Pending, puis Running) ; les contrôleurs mettent à jour le statut du ReplicaSet et du Deployment.

Retenez une conséquence pratique : kubectl apply réussit dès l'étape 5. Une commande qui répond deployment.apps/signalements created dit seulement que l'état voulu est enregistré. Le reste peut échouer plus tard (pas de nœud assez grand, image introuvable), et ces échecs se lisent dans le statut des objets et dans les événements (leçon 12).

Regarder les composants dans kind

Une fois le cluster formation créé à la leçon 3, lancez :

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

La première commande liste les nœuds : avec la configuration de la leçon 3, un nœud formation-control-plane et deux nœuds formation-worker et formation-worker2, avec leur version de Kubernetes, leur adresse interne, leur système et leur runtime de conteneurs (colonne CONTAINER-RUNTIME, de la forme containerd://<version>).

La seconde liste les Pods du namespace kube-system. Vous devez y reconnaître les composants de cette leçon :

• etcd-formation-control-plane, kube-apiserver-formation-control-plane, kube-controller-manager-formation-control-plane, kube-scheduler-formation-control-plane : le plan de contrôle, sur le nœud de plan de contrôle ;
• un Pod kube-proxy-... par nœud ;
• un Pod du plugin réseau kindnet-... par nœud ;
• deux Pods coredns-....

Les quatre composants du plan de contrôle portent le nom du nœud en suffixe : ce sont des Pods statiques, que le kubelet du nœud lance directement à partir de fichiers de manifestes posés sur le disque (outil d'installation kubeadm, utilisé par kind), sans passer par l'ordonnanceur. C'est ainsi que le plan de contrôle peut démarrer avant d'exister. kube-proxy, kindnet et CoreDNS sont au contraire gérés par des contrôleurs : un DaemonSet (un Pod par nœud, leçon 10) pour les deux premiers, un Deployment pour CoreDNS.

Descendre dans un nœud

Un nœud kind est un conteneur Docker. On peut y entrer pour voir le runtime de près :

$ docker exec -it formation-worker crictl ps
$ docker exec -it formation-worker crictl pods

crictl est un client de la CRI : il parle à containerd par la même interface que le kubelet. crictl pods liste les bacs à sable de Pods présents sur ce nœud, crictl ps leurs conteneurs. Vous y retrouvez les Pods de Signalements une fois déployés, et ceux du système qui tournent sur ce nœud.

Sous le capot

etcd et le quorum

etcd n'accepte une écriture que si une majorité de ses membres l'a enregistrée : pour n membres, il faut (n/2) + 1 voix, arrondi à l'entier inférieur pour la division. La FAQ d'etcd donne le tableau qui en découle :

Deux conséquences :

• Un nombre pair n'apporte rien : 4 membres ont besoin de 3 voix et ne tolèrent qu'une panne, comme 3 membres. Et en cas de coupure réseau en deux moitiés égales, aucune n'a la majorité. On déploie donc 3 ou 5 membres, rarement plus (la FAQ déconseille de dépasser sept).
• Sans majorité, etcd refuse d'écrire. Le cluster continue de faire tourner ce qui tourne, mais le serveur d'API ne peut plus enregistrer aucun changement : plus de déploiement, plus de réparation.

Un plan de contrôle hautement disponible comporte donc au moins trois membres etcd, idéalement dans trois zones, et plusieurs serveurs d'API derrière un répartiteur. L'ordonnanceur et le gestionnaire de contrôleurs tournent aussi en plusieurs exemplaires, mais un seul est actif à la fois : ils s'élisent un chef par un verrou stocké dans l'API (un objet Lease), pour éviter que deux ordonnanceurs placent le même Pod.

Quand un nœud disparaît

Le kubelet signale régulièrement qu'il est vivant, en renouvelant un objet Lease dans le namespace kube-node-lease, toutes les 10 secondes par défaut. Le contrôleur de nœuds surveille ces signaux. D'après la documentation :

1. après 40 secondes sans nouvelles (node-monitor-grace-period), il marque le nœud NotReady et lui pose des teintes (taints) node.kubernetes.io/unreachable ou node.kubernetes.io/not-ready avec l'effet NoExecute ;
2. les Pods ont, par défaut, une tolérance de 300 secondes à ces teintes : pendant cinq minutes, on considère que le nœud va peut-être revenir ;
3. passé ce délai, les Pods du nœud sont évincés, et leurs contrôleurs (ReplicaSet, etc.) en recréent ailleurs.

C'est la réponse au mystère du nœud disparu « sans que rien ne se passe pendant cinq minutes » : c'est voulu, pour ne pas tout déplacer à la première coupure réseau passagère. Si l'application ne supporte pas cinq minutes de capacité réduite, la réponse n'est pas de raccourcir ce délai, mais d'avoir assez d'exemplaires sur d'autres nœuds pour absorber la perte (leçon 5), comme pour les zones du cours cloud.

Pièges courants

Croire qu'une commande réussie a déployé l'application. kubectl apply enregistre l'état voulu ; le déploiement se lit ensuite dans le statut (kubectl rollout status, leçon 5).

Chercher l'erreur au mauvais étage. Un Pod Pending est un problème d'ordonnancement (ressources, contraintes) ; un Pod assigné mais qui ne démarre pas est un problème de nœud, d'image ou de configuration. La leçon 12 en fait une méthode.

Un etcd à deux membres. Il tolère zéro panne, comme un seul, mais tombe deux fois plus souvent. Toujours un nombre impair.

Oublier de sauvegarder etcd sur un cluster auto-géré. C'est la seule partie du cluster qui ne se reconstruit pas à partir de manifestes. Sur un cluster managé, c'est le fournisseur qui s'en charge, mais vos manifestes versionnés restent votre vraie sauvegarde.

Supposer que le mode de kube-proxy ne changera jamais. La documentation annonce un changement de défaut vers nftables : fixez le mode explicitement.

Sécurité

• Le serveur d'API est la cible principale. Il ne doit être exposé qu'aux réseaux qui en ont besoin, et chaque identité doit avoir les droits minimaux (cours Sécurité de Kubernetes). Chez un fournisseur, vérifiez si l'adresse de l'API est publique et si l'on peut la restreindre.
• etcd contient tous les Secrets. Par défaut, ils y sont stockés sans chiffrement ; un cluster auto-géré doit activer le chiffrement au repos des Secrets dans l'API, et protéger les sauvegardes d'etcd comme des secrets.
• Le kubelet a une API. Elle doit exiger une authentification ; une API de kubelet ouverte permet d'exécuter des commandes dans tous les conteneurs du nœud.
• L'admission est un point de contrôle. C'est là que se branchent les politiques qui refusent les conteneurs privilégiés ou les images non signées (cours Sécurité de Kubernetes).

En production

• Sur Kapsule, Scaleway exploite le plan de contrôle (serveur d'API, etcd, ordonnanceur, contrôleurs), en version mutualisée ou dédiée selon l'offre ; vous gérez des pools de nœuds (type d'instance, taille, mise à l'échelle automatique, réparation automatique) et tout ce qui tourne dessus. Le cours Kapsule : Kubernetes managé chez Scaleway détaille ces choix.
• Les nœuds se remplacent, ils ne se réparent pas. Comme les instances du cours cloud, ce sont du bétail : un nœud malade est retiré et recréé par le pool.
• Surveillez le plan de contrôle même managé : la latence du serveur d'API et le temps d'ordonnancement révèlent des problèmes avant les utilisateurs.
• Répartissez les nœuds sur plusieurs zones, et faites en sorte que les exemplaires d'une application ne soient pas tous sur le même nœud (leçon 5).

Exercices

1. Qui fait quoi ? (niveau 100). Pour chaque situation, dites quel composant est en cause en premier : (a) kubectl apply répond Forbidden ; (b) un Pod reste Pending ; (c) un Pod est assigné à un nœud mais son image ne se télécharge pas ; (d) un Service ne répartit pas le trafic sur les nouveaux Pods ; (e) un Service de type LoadBalancer n'obtient jamais d'adresse externe.

2. Le quorum (niveau 100). Un cluster auto-géré a cinq membres etcd répartis sur trois zones : deux dans la zone A, deux dans la zone B, un dans la zone C. La zone A tombe. Le cluster peut-il encore enregistrer des changements ? Et si la zone B tombe ensuite ?

3. Le nœud perdu (niveau 100). Un nœud qui portait un des trois Pods de Signalements perd son alimentation à 10 h 00. Sans changer aucun réglage par défaut, à partir de quand le nœud est-il marqué NotReady, et à partir de quand un Pod de remplacement est-il créé ailleurs ? Pendant ce temps, que voient les utilisateurs ?

4. Lire un manifeste de Pod statique (niveau 100). Sur le nœud de plan de contrôle de kind, les manifestes des Pods statiques se trouvent sous /etc/kubernetes/manifests. Avec docker exec formation-control-plane ls /etc/kubernetes/manifests, listez-les. Que se passe-t-il si vous supprimez le Pod kube-scheduler-formation-control-plane avec kubectl delete pod -n kube-system ? Pourquoi ?

Récapitulatif

• Un cluster se compose d'un plan de contrôle (kube-apiserver, etcd, kube-scheduler, kube-controller-manager, cloud-controller-manager) et de nœuds (kubelet, runtime de conteneurs, kube-proxy).
• Tout passe par le serveur d'API ; seul lui parle à etcd. Les composants sont informés des changements par le mécanisme list-watch et la resourceVersion.
• kubectl apply réussit dès l'enregistrement dans etcd ; contrôleurs, ordonnanceur et kubelet font le reste ensuite, et leurs échecs se lisent dans les statuts et les événements.
• Une requête traverse authentification (401), autorisation (403), admission (modification puis validation), puis la persistance.
• Le kubelet parle au runtime par la CRI (gRPC, version v1) ; containerd est le runtime courant. Docker Engine n'est plus utilisé comme runtime depuis la 1.24.
• kube-proxy : iptables par défaut, nftables disponible depuis la 1.33, ipvs déprécié depuis la 1.35 ; fixez le mode explicitement.
• etcd s'accorde par Raft et exige une majorité : 3 ou 5 membres, jamais un nombre pair.
• Un nœud silencieux devient NotReady après 40 s ; ses Pods sont évincés après 300 s de tolérance.
• Un Kubernetes managé exploite le plan de contrôle ; les pools de nœuds et les charges de travail restent à vous.

Pour aller plus loin

• La page Kubernetes Components de la documentation, et ses liens vers chaque composant.
• La page Controlling Access to the Kubernetes API, pour le détail des étapes d'une requête.
• La FAQ d'etcd, pour le dimensionnement et le fonctionnement du consensus.
• La leçon suivante, qui crée le cluster et ouvre l'API avec kubectl.