« Mes Pods tournent “dans Kubernetes”, peu importe où. »
Un Pod tourne toujours sur une machine réelle — un node. Ton cluster en a deux : un master et un worker. Comprendre où et pourquoi un Pod atterrit sur tel node, c’est comprendre ce que fait vraiment Kubernetes quand tu déclares un état voulu.
À la fin de ce module, tu sauras…
- Définir un node et distinguer control plane et worker
- Voir les nodes de ton cluster et sur lequel tourne chaque Pod
- Expliquer le rôle du scheduler
- Comprendre ce que « scaler » fait réellement
01Qu’est-ce qu’un node ?
Comprends ce qu’un node fournit
Un node apporte le CPU et la RAM, la connectivité réseau (CNI), et un runtime de conteneurs (en K3s, typiquement containerd) pour exécuter les conteneurs dans les Pods. C’est la ressource de calcul où Kubernetes place les Pods. Sur un petit cluster K3s, le master peut aussi héberger des Pods, mais le concept reste le même.
02Voir les nodes de ton cluster
Les machines réelles derrière le cluster
Manipulekubectl get nodes -o wideNAME STATUS ROLES AGE VERSION INTERNAL-IP
master-k3s Ready control-plane,master 5d v1.31.x+k3s1 192.168.10.30
worker-k3s Ready <none> 5d v1.31.x+k3s1 192.168.10.31Ready.Comprends la colonne ROLES
control-plane,master désigne le nœud qui héberge le cerveau du cluster (API server, scheduler, contrôleurs). <none> est un worker « pur ». En K3s, le master peut aussi exécuter des workloads, sauf si on l’en empêche explicitement.
03Où tourne chaque Pod ?
La colonne NODE
Manipulekubectl get pods -o wideNAME READY STATUS NODE IP
demo-deploy-7c9f8b6d4-fghij 1/1 Running worker-k3s 10.42.1.7
demo-deploy-7c9f8b6d4-klmno 1/1 Running master-k3s 10.42.0.9Comprends qui a décidé de ce placement ?
C’est le scheduler du control plane. Quand un Pod doit être créé, il choisit un node adapté (ressources disponibles, contraintes éventuelles), puis le kubelet de ce node démarre le conteneur. Tu déclares « je veux N Pods » ; le scheduler décide « où ».
04Ce que « scaler » fait vraiment
De 2 à 4 replicas
Manipulekubectl scale deployment demo-deploy --replicas=4
kubectl get pods -o widedemo-deploy-7c9f8b6d4-fghij 1/1 Running worker-k3s
demo-deploy-7c9f8b6d4-klmno 1/1 Running master-k3s
demo-deploy-7c9f8b6d4-pqrst 1/1 Running worker-k3s
demo-deploy-7c9f8b6d4-uvwxy 1/1 Running master-k3sComprends scaler ≠ démarrer des conteneurs
Scaler ne « démarre » pas directement des conteneurs. Ça met à jour l’état voulu (replicas: 4). Le contrôleur crée alors de nouveaux objets Pod, et le scheduler les place sur des nodes. Toujours la même logique : état voulu → réconciliation → placement. Le « quoi » et le « où » sont deux étapes distinctes.
✓Ce que tu retiens
Un node est une machine réelle du cluster ; le control plane décide, les workers exécutent. Le scheduler choisit où placer chaque Pod. Scaler modifie l’état voulu (replicas) ; le contrôleur crée les Pods, le scheduler les répartit. Le « quoi » et le « où » sont séparés — c’est ce qui permet à Kubernetes de répartir la charge.
Cartographie ton cluster
À faire
- Liste tes nodes avec
-o wideet identifie master et worker. - Affiche sur quel node tourne chaque Pod de
demo-deploy. - Scale à 4, puis observe la répartition des nouveaux Pods.
- Reviens à 2 (
–replicas=2) et note quels Pods disparaissent. - Documente dans BookStack : node, scheduler, ce que fait « scale ».
?Auto-évaluation
1. Quelle est la différence entre control plane et worker ?
Le control plane décide (API, scheduler, contrôleurs) ; les workers exécutent réellement les Pods.
2. Quel composant choisit le node d’un Pod ?
Le scheduler du control plane, selon les ressources et contraintes.
3. Que fait réellement kubectl scale ?
Il met à jour l’état voulu (replicas). Le contrôleur crée alors les Pods et le scheduler les place sur les nodes.