Wat zijn de belangrijkste componenten van de Kubernetes-architectuur en waar is elk verantwoordelijk voor?

Een Kubernetes-cluster bestaat uit een controlevlak plus een reeks werkmachines, genaamd nodes, die containerapplicaties uitvoeren in Pods. Elk cluster heeft ten minste één werkknooppunt nodig om Pods uit te voeren.

Conceptueel gezien is Kubernetes declaratief: u verzendt de gewenste status naar de API-server (opgeslagen in etcd), en controllers voeren continue afstemmingslussen uit die op verschillen letten en actie ondernemen om de werkelijke status naar de gewenste status te sturen.

Besturingsvlakcomponenten

Het besturingsvlak neemt globale beslissingen over het cluster (zoals planning) en reageert op clustergebeurtenissen. In de productie draait het meestal over meerdere machines voor een hoge beschikbaarheid.

• kube-apiserver — de kerncomponent die de Kubernetes HTTP API beschikbaar stelt. Het is de front-end van het besturingsvlak en het enige contactpunt: alle authenticatie, autorisatie, aanvraagvalidatie en lees-/schrijfbewerkingen van de clusterstatus stromen er doorheen. Het schaalt horizontaal. Bij normale implementaties is dit de enige Kubernetes-component die de clusterstatus rechtstreeks in etcd leest en schrijft; alle andere componenten communiceren met de status via de API-server.
• etcd — een consistente en zeer beschikbare sleutel/waarde-opslag die wordt gebruikt als back-upopslag van Kubernetes voor alle clustergegevens: configuratie, status en metagegevens. etcd is verplicht en is de enige bron van waarheid; het verliezen ervan betekent dat de hele clusterstatus verloren gaat, dus het moet met quorum (een oneven aantal leden) werken en er moet regelmatig een back-up van worden gemaakt.
• kube-scheduler — let op pods die nog niet aan een knooppunt zijn gebonden en wijst elke pod toe aan een geschikt knooppunt, rekening houdend met bronnen, beperkingen en beleid.
• kube-controller-manager — voert controllers uit die Kubernetes API-gedrag implementeren (bijvoorbeeld Node-controller, Job-controller, EndpointSlice-controller). Elke controleur houdt de gewenste toestand in de gaten en stemt de feitelijke toestand daarmee af.
• cloud-controller-manager (optioneel) — integreert met de onderliggende cloudprovider, waardoor cloudspecifieke logica wordt geïsoleerd van de kerncomponenten van Kubernetes.

Knooppuntcomponenten

Deze draaien op elk knooppunt, waardoor Pods actief blijven en de runtime-omgeving wordt geboden.

• kubelet: de agent die ervoor zorgt dat Pods actief zijn, inclusief hun containers. Het houdt de API-server in de gaten voor Pod-toewijzingen, start containers via de runtime, koppelt volumes, voert liveness/readiness-tests uit en rapporteert de knooppuntstatus.
• kube-proxy — implementeert servicenetwerken door iptables of IPVS-regels op knooppunten te programmeren, zodat verkeer naar een service wordt doorgestuurd naar de juiste Pod-IP's. Het is als optioneel gemarkeerd omdat sommige CNI-plug-ins (bijvoorbeeld Cilium in eBPF-modus) zijn taak overnemen, maar in een standaardcluster is dit vereist.
• Container runtime — de software die verantwoordelijk is voor het uitvoeren van containers (containerd, CRI-O, enz., via de CRI-interface).

Add-ons

Add-ons breiden de clusterfunctionaliteit uit: cluster DNS (standaard CoreDNS), de Dashboard-webgebruikersinterface, monitoring van containerresources en logboekregistratie op clusterniveau.

Gemeenschappelijke follow-up: alle communicatie stroomt via de API-server (de planner, controllers en kubelets kijken er eenvoudig naar en reageren) waardoor de API-server het kritieke knooppunt van het cluster wordt.