Décrivez l'architecture de Kubernetes : control plane vs worker nodes et leurs composants.

Question

IT Interview Practice · Accepted Answer

Un cluster Kubernetes comporte deux sortes de machines : le **control plane** (le « cerveau » qui prend les décisions et stocke l'état) et les **worker nodes** (où vos Pods s'exécutent réellement). Chacun possède un petit ensemble de composants bien définis.

## La vue d'ensemble

```text
┌──────────────── CONTROL PLANE (the brain) ────────────────┐
│                                                            │
│   kube-apiserver ── the front door; ALL comms go through it│
│        │                                                   │
│   etcd ───────── key-value store: the cluster's SOURCE OF  │
│                  TRUTH (all objects & desired state)       │
│   kube-scheduler ── decides WHICH node a new Pod runs on   │
│   controller-manager ── runs control loops (reconcilers)   │
└──────────────────────────┬─────────────────────────────────┘
                           │ (apiserver)
   ┌───────────────────────┼───────────────────────┐
┌──┴─── WORKER NODE ──┐ ┌──┴─── WORKER NODE ──┐  ...
│ kubelet             │ │ kubelet             │
│ kube-proxy          │ │ kube-proxy          │
│ container runtime   │ │ container runtime   │
│  └ Pods (your apps) │ │  └ Pods (your apps) │
└─────────────────────┘ └─────────────────────┘
```

## Composants du control plane

```text
kube-apiserver        Le point d'entrée unique. Expose l'API REST ; valide et
                      persiste les objets dans etcd. kubectl, les controllers et les kubelets
                      ne parlent QU'À l'apiserver.
etcd                  Key-value store distribué et cohérent. Contient l'ENTIER
                      état du cluster (désiré + actuel). Perdre etcd = perdre le cluster.
kube-scheduler        Surveille les Pods sans node assigné et choisit le meilleur node
                      (selon les resource requests, l'affinity, les taints, etc.).
kube-controller-      Exécute les boucles de contrôle : node controller, replication (ReplicaSet),
manager               deployment, job, endpoints, etc. Chaque boucle amène l'actuel → désiré.
cloud-controller-     (Sur cloud) intègre avec le provider : load balancers, routes,
manager               cycle de vie des nodes.
```

## Composants d'un worker node

```text
kubelet          L'agent du node. Parle à l'apiserver, démarre/arrête les conteneurs via
                 le runtime, et remonte le statut des Pods et du node. Il fait correspondre la
                 réalité du node aux Pods qui lui sont assignés.
kube-proxy       Programme le networking du node (iptables/IPVS) pour que les IP virtuelles
                 des Services soient load-balancées vers les bons endpoints de Pods.
container runtime Le logiciel qui exécute réellement les conteneurs (containerd, CRI-O).
```

## Comment un « kubectl apply » circule dans le système

```text
1. kubectl → kube-apiserver : « Je veux un Deployment avec 3 replicas »
2. l'apiserver valide et écrit l'objet dans etcd
3. le controller-manager (deployment→replicaset controller) le voit, crée 3 objets Pod
4. le scheduler voit 3 Pods non assignés, affecte chacun à un node (réécrit via l'apiserver)
5. le kubelet de chaque node voit ses Pods, dit au runtime de tirer les images et démarrer les conteneurs
6. kube-proxy câble le networking du Service pour que le trafic atteigne les nouveaux Pods
Tout est une boucle WATCH + RECONCILE médiatisée par l'apiserver.
```

```bash
kubectl get nodes                 # lister les nodes (control-plane + workers)
kubectl get pods -n kube-system   # voir les composants control-plane / système
kubectl get componentstatuses     # santé des pièces centrales du control-plane
```

## Pourquoi c'est important

Comprendre la séparation entre le control plane et les worker nodes — et le rôle de chaque composant — est ce qui transforme Kubernetes d'une boîte noire en un système sur lequel vous pouvez raisonner et que vous pouvez exploiter, ce qui en fait une connaissance centrale pour tout ingénieur de niveau intermédiaire ou supérieur. Le **control plane** est le cerveau décisionnel : le **kube-apiserver** est l'unique porte d'entrée par laquelle chaque composant et utilisateur communique ; **etcd** est le key-value store cohérent qui contient l'ensemble de l'état du cluster et fait office de source de vérité (le perdre revient à perdre le cluster) ; le **scheduler** décide sur quel node chaque nouveau Pod atterrit ; et le **controller-manager** exécute les boucles de réconciliation qui amènent en continu l'état réel vers l'état désiré. Sur chaque **worker node**, le **kubelet** est l'agent qui fait correspondre les conteneurs du node aux Pods qui lui sont assignés, **kube-proxy** programme le networking qui fait router les IP virtuelles des Services vers les bons Pods, et un **container runtime** (containerd, CRI-O) exécute réellement les conteneurs. Voir comment un simple `kubectl apply` circule dans ce système — de l'apiserver à etcd, les controllers créant des objets, le scheduler plaçant les Pods, les kubelets démarrant les conteneurs, kube-proxy câblant le networking, le tout sous forme de boucles watch-and-reconcile — révèle la conception élégante et cohérente derrière la plateforme. Ce modèle mental est exactement ce dont vous avez besoin pour déboguer pourquoi un Pod reste bloqué en Pending (scheduler), pourquoi le cluster ne répond plus (apiserver/etcd) ou pourquoi un Service ne route pas (kube-proxy), ce qui le rend indispensable pour exploiter et dépanner de vrais clusters.

La vue d'ensemble

Composants du control plane

Composants d'un worker node

Comment un « kubectl apply » circule dans le système

Pourquoi c'est important

Questions connexes