Kubernetes-architectuur: control plane en worker nodes uitgelegd
De bouwstenen van een Kubernetes-cluster: wat doet de control plane, wat doen worker nodes, en hoe werken ze samen om een gewenste staat te bewaken?
Kubernetes draait om één simpel idee: jij beschrijft wat je wilt (bijvoorbeeld "3 replica's van deze applicatie"), en het cluster zorgt er continu voor dat de werkelijkheid overeenkomt met die beschrijving. Om dat te snappen, moet je weten uit welke onderdelen een cluster bestaat.
Twee soorten machines: control plane en worker nodes
Een Kubernetes-cluster bestaat altijd uit twee soorten machines (nodes). De control plane neemt beslissingen over het cluster; de worker nodes draaien de daadwerkelijke workloads.
De control plane: het brein van het cluster
- API server — de enige ingang tot het cluster. Alle commando's (via
kubectl, dashboards, of andere componenten) gaan hierdoorheen. Het valideert verzoeken en slaat de gewenste staat op. - etcd — een gedistribueerde key-value store die de volledige clusterstaat bevat: welke pods er zouden moeten draaien, welke configuratie ze hebben, enzovoort. Dit is de "waarheid" van het cluster.
- Scheduler — kijkt welke pods nog geen node hebben toegewezen gekregen, en beslist op welke worker node ze het beste kunnen draaien (op basis van resources, constraints, affinity-regels).
- Controller manager — draait continu controle-lussen (reconciliation loops) die de huidige staat vergelijken met de gewenste staat. Klopt er iets niet (bijv. een pod is gecrasht), dan onderneemt de controller actie om dat te herstellen.
De worker node: waar de workload echt draait
- kubelet — de agent die op elke worker node draait. Hij praat met de API server, ontvangt instructies over welke pods lokaal moeten draaien, en zorgt dat de container runtime ze start.
- kube-proxy — regelt netwerkregels zodat verkeer naar een Service bij de juiste pod terechtkomt, ongeacht op welke node die draait.
- Container runtime — de software (zoals containerd of CRI-O) die daadwerkelijk containers start en stopt binnen een pod.
Waarom dit ontwerp zo krachtig is
Omdat de gewenste staat centraal is vastgelegd in etcd en constant bewaakt wordt, is Kubernetes zelfherstellend. Valt een node uit, dan detecteert de controller manager dat de gewenste replica's niet meer kloppen en laat de scheduler nieuwe pods inplannen op een andere node — zonder dat een mens hoeft in te grijpen.
Examentip: Vragen over "welke component doet wat" komen vaak terug. Onthoud de vuistregel: API server = ingang, etcd = geheugen, scheduler = planner, controller manager = bewaker, kubelet = uitvoerder op de node.