Ein Kubernetes-Cluster ist eine Menge zusammenarbeitender Prozesse. Zu wissen, was jeder tut, macht alles andere, vom Scheduling bis zur Fehlersuche, leichter nachvollziehbar. Diese Anleitung benennt die Komponenten und verfolgt dann eine einzelne Anfrage bis zu einem laufenden Container.

Control Plane und Worker-Knoten

Die Control Plane trifft Entscheidungen über den Cluster. Worker-Knoten führen deine Workloads aus. In einem lokalen Cluster wie minikube übernimmt ein Knoten beide Rollen. Produktive Cluster haben meist mehrere Control-Plane-Knoten für Verfügbarkeit: Verlierst du den einzigen, kannst du nichts mehr im Cluster ändern, obwohl bereits laufende Workloads typischerweise noch eine Weile weiterlaufen. Control-Plane-Knoten sind normalerweise mit einem Taint versehen, damit deine Anwendungs-Pods nicht auf ihnen eingeplant werden.

Komponenten der Control Plane

• kube-apiserver ist die Eingangstür. Jeder Client (kubectl, Dashboards, Skripte und die anderen Komponenten) spricht über eine HTTP-API mit ihm. Er authentifiziert und autorisiert Anfragen, validiert Objekte und ist die einzige Komponente, die etcd liest und schreibt.
• etcd ist ein konsistenter Schlüssel-Wert-Speicher, der den gesamten Cluster-Zustand hält: welche Knoten existieren, welche Pods laufen sollen, ihren aktuellen Status. Behandle ihn wie das Gedächtnis des Clusters. Sichere ihn, denn ihn zu verlieren bedeutet, den Überblick über alles zu verlieren.
• kube-scheduler wählt für jeden Pod, der noch keinen hat, einen Knoten aus, anhand von Ressourcen-Requests, Einschränkungen und verfügbarer Kapazität.
• kube-controller-manager führt die Controller aus, die Regelschleifen, die Soll- und Ist-Zustand vergleichen und auf die Differenz reagieren. Die Controller für Deployment, ReplicaSet und Node leben alle hier.
• cloud-controller-manager (nur bei Cloud-Anbietern) integriert sich mit dem Anbieter für Dinge wie Load Balancer und Knoten-Lebenszyklus.

Komponenten der Knoten

• kubelet ist der Agent auf jedem Knoten. Er beobachtet, welche Pods seinem Knoten zugewiesen sind, stellt sicher, dass ihre Container laufen und gesund sind, und meldet den Status zurück.
• Container-Runtime führt die Container tatsächlich aus. Es ist meist containerd oder CRI-O, über das Container Runtime Interface angebunden. Kubernetes spricht nicht mehr direkt mit der Docker Engine (dockershim wurde in 1.24 entfernt), aber mit Docker gebaute Images laufen weiterhin, weil Images dem offenen OCI-Standard folgen.
• kube-proxy pflegt die Netzwerkregeln auf jedem Knoten, die dafür sorgen, dass Service-Adressen die richtigen Pods erreichen.
• Ein Netzwerk-Plugin (CNI) gibt Pods ihre IP-Adressen und Konnektivität über Knoten hinweg.

Eine Anfrage von kubectl apply bis zu einem laufenden Container verfolgen

Angenommen, du wendest ein Deployment-Manifest an. Das passiert:

1. kubectl liest deine kubeconfig und sendet das Manifest per HTTPS an den API-Server.
2. Der API-Server authentifiziert und autorisiert dich, validiert das Objekt, speichert es in etcd und antwortet.
3. Der Deployment-Controller bemerkt das neue Deployment und erstellt ein ReplicaSet, und der ReplicaSet-Controller erstellt die Pod-Objekte. An diesem Punkt existieren die Pods, sind aber keinem Knoten zugewiesen.
4. Der Scheduler bemerkt Pods ohne Knoten, wählt für jeden einen aus und hält diese Entscheidung über den API-Server fest.
5. Der kubelet auf dem gewählten Knoten sieht einen ihm zugewiesenen Pod und sagt der Container-Runtime, das Image zu pullen und die Container zu starten.
6. Der kubelet meldet den Fortschritt an den API-Server zurück, der ihn in etcd speichert. Das liest kubectl get pods.

Beachte, dass die Komponenten einander nie direkt aufrufen. Jede beobachtet den API-Server auf die Objekte, die sie betreffen, und reagiert. Diese lose Kopplung ist der Grund, warum du die meisten Komponenten neu starten kannst, ohne etwas zu verlieren: Der Zustand, den sie brauchen, liegt in etcd.

Die Abfolge siehst du in den Events, die Kubernetes aufzeichnet:

kubectl create deployment demo --image=nginx:1.25
kubectl get events --sort-by=.metadata.creationTimestamp

Achte auf Scheduled, Pulling, Pulled, Created und Started. Das sind der Scheduler und der kubelet bei ihrer Arbeit.

Die Komponenten im eigenen Cluster ansehen

kubectl get nodes -o wide
kubectl get pods -n kube-system

Auf minikube- und kubeadm-gebauten Clustern siehst du die Control-Plane-Komponenten als Pods im Namespace kube-system laufen, neben kube-proxy und dem Netzwerk-Plugin. Bei verwalteten Diensten (EKS, GKE, AKS) betreibt der Anbieter die Control Plane für dich, und du siehst nur deine Worker-Knoten.

Was dieses Design in der Praxis bedeutet

• Der API-Server ist der Flaschenhals. Alles läuft durch ihn, daher zählt es, ihn abzusichern und angemessen zu dimensionieren.
• Die Gesundheit von etcd ist die Gesundheit des Clusters. Sichere ihn und betreibe ihn in der Produktion redundant.
• Ausfälle werden erwartet. Ein toter Knoten, eine abgestürzte Komponente oder ein gelöschter Pod ist nur eine Abweichung zwischen Soll- und Ist-Zustand, die ein Controller irgendwann behebt.