Beschrijf de Kubernetes-architectuur: control plane versus worker nodes en hun componenten.

Question

IT Interview Practice · Accepted Answer

Een Kubernetes-cluster heeft twee soorten machines: het **control plane** (het "brein" dat beslissingen neemt en state opslaat) en **worker nodes** (waar je Pods daadwerkelijk draaien). Elk heeft een kleine set welgedefinieerde componenten.

## Het grote plaatje

```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) │
└─────────────────────┘ └─────────────────────┘
```

## Control-plane-componenten

```text
kube-apiserver        Het enige toegangspunt. Biedt de REST API; valideert &
                      persisteert objecten naar etcd. kubectl, controllers en kubelets
                      praten ALLEEN met de apiserver.
etcd                  Gedistribueerde, consistente key-value store. Bevat de HELE
                      clustertoestand (desired + huidig). etcd kwijt = cluster kwijt.
kube-scheduler        Bewaakt Pods zonder toegewezen node en kiest de beste node
                      (o.b.v. resource requests, affinity, taints, enz.).
kube-controller-      Draait de control loops: node controller, replication (ReplicaSet),
manager               deployment, job, endpoints, enz. Elke loop stuurt actueel → desired.
cloud-controller-     (Op cloud) integreert met de provider: load balancers, routes,
manager               node-lifecycle.
```

## Worker-node-componenten

```text
kubelet          De node-agent. Praat met de apiserver, start/stopt containers via
                 de runtime, en rapporteert Pod- & node-status. Hij laat de
                 werkelijkheid van de node overeenkomen met de toegewezen Pods.
kube-proxy       Programmeert het netwerk van de node (iptables/IPVS) zodat virtuele
                 Service-IP's worden load-balanced naar de juiste Pod-endpoints.
container runtime De software die containers daadwerkelijk draait (containerd, CRI-O).
```

## Hoe een "kubectl apply" door het systeem stroomt

```text
1. kubectl → kube-apiserver: "Ik wil een Deployment met 3 replicas"
2. apiserver valideert & schrijft het object naar etcd
3. controller-manager (deployment→replicaset controller) ziet het, maakt 3 Pod-objecten
4. scheduler ziet 3 niet-toegewezen Pods, wijst elk aan een node toe (schrijft terug via apiserver)
5. de kubelet van elke node ziet zijn Pods, laat de runtime images pullen & containers starten
6. kube-proxy bedraadt het Service-netwerk zodat verkeer de nieuwe Pods bereikt
Alles is een WATCH + RECONCILE loop, gemedieerd door de apiserver.
```

```bash
kubectl get nodes                 # lijst nodes (control-plane + workers)
kubectl get pods -n kube-system   # bekijk de control-plane / systeemcomponenten
kubectl get componentstatuses     # gezondheid van kern-control-plane-onderdelen
```

## Waarom het belangrijk is

De splitsing tussen het control plane en de worker nodes begrijpen — en de rol van elk component — is wat Kubernetes van een black box verandert in een systeem waarover je kunt redeneren en dat je kunt bedienen, dus het is kernkennis voor elke engineer op medior-niveau of hoger. Het **control plane** is het beslissende brein: de **kube-apiserver** is de enige voordeur waarlangs elk component en elke gebruiker communiceert; **etcd** is de consistente key-value store die de hele clustertoestand bevat en de source of truth is (die kwijtraken betekent het cluster kwijtraken); de **scheduler** beslist op welke node elke nieuwe Pod belandt; en de **controller-manager** draait de reconciliation loops die de werkelijke toestand continu naar de gewenste sturen. Op elke **worker node** is de **kubelet** de agent die de containers van de node laat overeenkomen met de toegewezen Pods, programmeert **kube-proxy** het netwerk dat virtuele Service-IP's naar de juiste Pods routeert, en draait een **container runtime** (containerd, CRI-O) de containers daadwerkelijk. Zien hoe één `kubectl apply` door dit systeem stroomt — apiserver naar etcd, controllers die objecten aanmaken, scheduler die Pods plaatst, kubelets die containers starten, kube-proxy die het netwerk bedraadt, alles als watch-and-reconcile loops — onthult het elegante, consistente ontwerp achter het platform. Dit mentale model is precies wat je nodig hebt om te debuggen waarom een Pod op Pending blijft hangen (scheduler), waarom het cluster niet reageert (apiserver/etcd), of waarom een Service niet routeert (kube-proxy), waardoor het onmisbaar is voor het bedienen en oplossen van problemen in echte clusters.

Het grote plaatje

Control-plane-componenten

Worker-node-componenten

Hoe een "kubectl apply" door het systeem stroomt

Waarom het belangrijk is

Gerelateerde vragen