Kubernetes 003 – Schema de l’architecture : comment ca marche ?

TL;DR

Un cluster Kubernetes est organise autour d’un plan de controle et de noeuds. L’API Server est le point d’entree. etcd stocke l’etat. Le scheduler place les pods. Les controleurs reconciliant l’etat desire. Les kubelets appliquent localement les decisions sur chaque noeud.

La video de reference

Video: https://www.youtube.com/watch?v=PlraENp_bMk

Elle donne le schema mental necessaire avant de comprendre le scheduling et le cycle de vie d’un pod.

Le plan de controle

Le plan de controle regroupe les composants qui prennent les decisions globales du cluster. L’API Server recoit les requetes, valide les objets et expose l’API. etcd conserve l’etat du cluster. Le scheduler choisit un noeud pour les pods non assignes. Les controleurs surveillent les objets et declenchent les actions necessaires.

Les noeuds de travail

Sur chaque noeud, le kubelet discute avec l’API Server et s’assure que les pods prevus pour ce noeud tournent bien. Il travaille avec un runtime de conteneurs, par exemple containerd, pour creer et superviser les conteneurs.

Le flux simplifie

• L’utilisateur applique un manifest avec kubectl.
• La requete arrive sur l’API Server.
• L’objet est stocke dans etcd.
• Un controleur detecte le besoin.
• Le scheduler choisit un noeud.
• Le kubelet lance les conteneurs.

Pourquoi ce schema est important

Quand un pod ne demarre pas, le probleme peut venir de plusieurs endroits: objet invalide, image inaccessible, scheduling impossible, noeud indisponible, erreur applicative. Avoir le schema en tete aide a poser les bonnes questions.

Liens utiles

• Video: https://www.youtube.com/watch?v=PlraENp_bMk
• Composants Kubernetes: https://kubernetes.io/docs/concepts/overview/components/
• Architecture du cluster: https://kubernetes.io/docs/concepts/architecture/
• Formation Enix Kubernetes: https://2026-05-enix.container.training/2.yml.html

FAQ

etcd lance-t-il les conteneurs ?

Non. etcd stocke l’etat. Les conteneurs sont lances sur les noeuds via le kubelet et le runtime.

Le scheduler redemarre-t-il les pods ?

Non. Le scheduler choisit le noeud. Les controleurs et kubelets interviennent ensuite pour maintenir l’etat.

Peut-on utiliser Kubernetes sans comprendre l’architecture ?

Pour quelques commandes, oui. Pour diagnostiquer correctement, non.

Lecture detaillee des composants

L’API Server est le point d’entree logique. Meme quand on utilise kubectl, Helm ou un operateur, l’action finit par devenir une requete vers l’API. C’est aussi lui qui applique l’authentification, l’autorisation, la validation et les admissions.

etcd est la base cle-valeur qui conserve l’etat du cluster. Il ne faut pas le voir comme une base applicative: il stocke les objets Kubernetes et doit etre protege, sauvegarde et traite comme un composant critique.

Le scheduler ne lance rien lui-meme. Il prend une decision de placement. Il observe les pods sans noeud, evalue les contraintes, puis inscrit le noeud choisi dans la specification du pod.

Les controleurs sont les ouvriers de la reconciliation. Un controleur de ReplicaSet verifie le nombre de pods. Un controleur de noeud observe les noeuds. Un controleur de endpoints met a jour les associations entre Services et pods. Kubernetes est une collection de boucles de controle.

Enfin, le kubelet est le relais local. Il tourne sur chaque noeud et fait le lien entre l’etat attendu dans l’API et l’execution reelle des conteneurs.

Exemple de diagnostic avec le schema

Si un pod reste bloque, on peut suivre le schema:

kubectl get pod mon-pod -o wide
kubectl describe pod mon-pod
kubectl get events --sort-by=.lastTimestamp
kubectl describe node <node>

Si le pod n’a pas de noeud, on pense scheduler. S’il a un noeud mais ne demarre pas, on pense kubelet, image, runtime, volume ou configuration applicative. Si la ressource n’existe pas, on revient a l’API Server et au manifest applique.

Ce qui se passe quand on applique un manifest

Quand on lance kubectl apply -f fichier.yaml, kubectl lit le fichier, construit une requete vers l’API Server, puis l’API valide et stocke l’objet. A partir de la, kubectl n’est plus le moteur principal. Les composants du cluster prennent le relais.

C’est une erreur classique de croire que kubectl garde un processus actif. En realite, une fois la requete acceptee, Kubernetes travaille de maniere autonome.

A retenir

• Le plan de controle decide et stocke l’etat.
• Les noeuds executent les workloads.
• Les controleurs corrigent les ecarts entre etat voulu et etat reel.
• kubectl est un client, pas le cerveau du cluster.

Control plane et data plane

Une maniere simple de lire l’architecture est de distinguer le control plane et le data plane. Le control plane porte les decisions, l’API, l’etat et les boucles de controle. Le data plane correspond aux noeuds qui executent les workloads applicatifs.

Cette separation n’est pas seulement theorique. Quand l’API Server est indisponible, les pods deja lances peuvent continuer a tourner, mais il devient difficile de piloter le cluster. Quand un noeud de travail tombe, le control plane peut detecter le probleme et demander le remplacement des pods ailleurs, si les controleurs le permettent.

Les communications importantes

Plusieurs communications structurent le fonctionnement du cluster:

• kubectl contacte l’API Server;
• l’API Server lit et ecrit dans etcd;
• les controleurs regardent l’API Server;
• le scheduler ecrit la decision de placement dans l’objet pod;
• le kubelet observe les pods assignes a son noeud;
• le runtime lance les conteneurs localement.

Comprendre ces flux aide a localiser les problemes. Une erreur d’authentification concerne l’acces API. Un pod sans noeud concerne souvent le scheduling. Un conteneur qui ne demarre pas concerne plutot le kubelet, l’image, le runtime ou l’application.

Pourquoi etcd est critique

etcd contient l’etat du cluster. Si cette base est perdue sans sauvegarde, le cluster perd sa memoire. Pour un lab, ce n’est pas dramatique si le cluster peut etre reconstruit. Pour une production, c’est un composant a sauvegarder et proteger serieusement.

Il ne faut pas y stocker directement des donnees applicatives. Kubernetes l’utilise pour ses objets internes: pods, services, deployments, secrets, configmaps et autres ressources API. La sante d’etcd conditionne donc la fiabilite du plan de controle.

Exercice mental: suivre un pod

Quand un pod est cree, essayez de raconter son parcours:

• le manifest est envoye a l’API Server;
• l’objet est valide et stocke;
• le scheduler choisit un noeud;
• le kubelet du noeud lit la specification;
• le runtime tire l’image et lance le conteneur;
• le kubelet remonte le status.

Si vous savez situer une erreur dans ce parcours, vous avez deja une bonne base de debug Kubernetes.

Notions et definitions

• API Server: porte d’entree de toutes les operations Kubernetes.
• Objet declaratif: document qui decrit l’etat voulu plutot qu’une suite d’actions imperatives.
• Controleur: composant qui agit pour rapprocher le reel du desire.

Ces definitions donnent le vocabulaire minimal pour suivre l’article sans reduire Kubernetes a une simple commande. Chaque notion doit etre reliee a un objet visible avec kubectl ou a un composant du cluster.

Exemple concret

Un manifest Deployment ne dit pas comment creer chaque pod pas a pas; il declare le resultat attendu, et Kubernetes se charge de converger vers cet etat.

Cet exemple sert de fil conducteur: il montre quel probleme operationnel Kubernetes cherche a resoudre et quelle ressource permet de le formaliser.

How-to rapide

• Explorer le schema de l’objet avec kubectl explain.
• Creer l’objet declarativement avec kubectl apply -f.
• Observer status, conditions et events.
• Modifier le YAML puis reappliquer pour comprendre la reconciliation.

Le how-to est volontairement court: l’idee est d’obtenir un resultat observable, puis d’utiliser les commandes de verification pour comprendre ce qui s’est passe.

Approfondir cet article

Cet episode doit surtout permettre de maitriser le modele mental Kubernetes: API declarative, etat desire, controleurs et observation continue du cluster. L’objectif n’est pas seulement de refaire les commandes, mais de comprendre quel objet Kubernetes est cree, quel composant le prend en charge et comment verifier le resultat.

Questions a se poser

• Quel est l’etat desire exprime dans Kubernetes ?
• Quel composant observe cet etat et tente de le reconciler ?
• Quels symptomes montrent que l’objet est cree mais pas encore operationnel ?
• Quelle commande donne l’information la plus fiable pour diagnostiquer ?

Commandes de verification

• kubectl api-resources pour lister les objets disponibles
• kubectl explain <ressource> pour comprendre le schema d’un objet
• kubectl get events --sort-by=.lastTimestamp pour suivre ce que le cluster decide

Ces commandes ne sont pas a apprendre par coeur. Elles servent a construire un reflexe: partir de l’objet Kubernetes, lire son etat, puis descendre vers les pods, les events, les logs ou le noeud uniquement si c’est necessaire.

Points de vigilance

• voir Kubernetes comme une suite de commandes au lieu d’une API d’etat
• oublier la difference entre creer un objet et obtenir un workload fonctionnel
• ne pas regarder les events et les conditions avant de chercher trop loin

Exercice conseille

Prenez un objet simple, creez-le en imperatif, exportez son YAML, supprimez-le, puis recréez-le en declaratif pour comparer les deux approches.

Pour valider la comprehension, gardez une trace courte: manifest utilise, commandes lancees, resultat attendu, resultat observe et correction appliquee. Cette methode rend les episodes suivants beaucoup plus faciles a enchainer.

Lien interne conseille

Pour poursuivre la progression, consultez aussi Kubernetes 004 – Scheduling : de l’ETCD au container.

Conclusion

Ce schema donne la carte du territoire. Une fois API Server, etcd, scheduler, controleurs et kubelet situes, les episodes suivants deviennent beaucoup plus concrets.