In diesem Artikel beschreibe ich meinen persönlichen Einstieg in die Kubernetes Architektur. Ich erkläre den Aufbau von Control Plane, Master Node und Worker Nodes – praxisnah, verständlich und mit konkreten Beispielen aus Minikube.
Warum ich Kubernetes erst verstehen musste, bevor ich es nutzen konnte
Als ich Kubernetes zum ersten Mal benutzt habe, habe ich ehrlich gesagt einfach nur YAML-Dateien angewendet. Es hat funktioniert – aber ich hatte keine Ahnung, was im Hintergrund passiert. Erst als ich mich mit der Architektur beschäftigt habe, wurde Kubernetes für mich logisch.
Dieser Artikel ist genau aus diesem Lernprozess entstanden.
Was ist Kubernetes überhaupt?
Kubernetes ist eine Plattform zur Orchestrierung von Containern. Es kümmert sich darum, Container zu starten, zu überwachen, neu zu starten und über mehrere Rechner zu verteilen.
Wichtig für mein Verständnis war: Kubernetes besteht nicht aus „Magie“, sondern aus klar getrennten Komponenten, die jeweils eine konkrete Aufgabe haben.
Die Kubernetes Gesamtarchitektur im Überblick
Grundsätzlich besteht ein Kubernetes-Cluster aus zwei großen Bereichen:
- Control Plane (früher Master Node)
- Worker Nodes
In Minikube laufen diese Komponenten oft auf einem einzigen Node – logisch sind sie aber klar voneinander getrennt.
Die Control Plane – das Gehirn von Kubernetes
Die Control Plane ist für alle Steuerungsentscheidungen zuständig. Sie entscheidet was laufen soll, wo es läuft und wie der gewünschte Zustand aussieht.
kube-apiserver
Der API Server ist der zentrale Einstiegspunkt. Alles, was ich mit kubectl mache, landet hier.
kubectl get nodes
kubectl get pods
Diese Befehle sprechen ausschließlich mit dem API Server – nie direkt mit einem Node.
etcd
etcd ist die Datenbank von Kubernetes. Hier wird der komplette Zustand des Clusters gespeichert: Pods, Nodes, Secrets, ConfigMaps – alles.
Mir hat es geholfen, etcd als Single Source of Truth zu sehen.
kube-scheduler
Der Scheduler entscheidet, auf welchem Worker Node ein Pod laufen soll. Er berücksichtigt dabei Ressourcen, Regeln und Einschränkungen.
kube-controller-manager
Die Controller überwachen den Zustand des Clusters. Wenn etwas vom gewünschten Zustand abweicht, greifen sie ein.
Beispiel: Ein Pod stirbt – der Controller sorgt dafür, dass ein neuer erstellt wird.
Die Worker Nodes – hier laufen meine Pods
Worker Nodes sind die Maschinen, auf denen meine Anwendungen tatsächlich laufen.
kubelet
Das kubelet ist der Agent auf jedem Worker Node. Es spricht mit der Control Plane und sorgt dafür, dass die definierten Pods laufen.
Container Runtime
Die Container Runtime (z. B. containerd) startet und verwaltet die Container selbst. Kubernetes steuert – die Runtime führt aus.
kube-proxy
kube-proxy kümmert sich um Netzwerkregeln und Services. Ohne kube-proxy gäbe es keine stabile Kommunikation zwischen Pods.
Kubernetes Architektur praktisch mit Minikube erkunden
Minikube war für mich der perfekte Einstieg, um die Architektur live zu sehen.
Cluster-Informationen anzeigen
kubectl cluster-info
Nodes anzeigen
kubectl get nodes -o wide
Auch wenn Minikube meist nur einen Node zeigt, sind Control Plane und Worker logisch getrennt.
System-Pods anzeigen
kubectl get pods -n kube-system
Hier sehe ich die Komponenten der Control Plane als laufende Pods – ein echter Aha-Moment für mich.
Wie alles zusammenspielt – mein mentales Modell
So stelle ich mir Kubernetes heute vor:
- Ich beschreibe einen Wunschzustand (YAML)
- Der API Server nimmt ihn entgegen
- etcd speichert ihn
- Scheduler & Controller setzen ihn um
- Worker Nodes führen ihn aus
Kubernetes ist kein Tool, sondern ein verteiltes System mit klaren Verantwortlichkeiten.
Mein Fazit zur Kubernetes Architektur
Erst als ich die Architektur verstanden habe, konnte ich Kubernetes wirklich sinnvoll nutzen. Besonders geholfen haben mir:
- das mentale Modell von Control Plane und Worker Nodes
- Minikube zum Experimentieren
- der Blick in den Namespace
kube-system
Mit diesem Verständnis waren Pods, Deployments und Services plötzlich logisch – und Kubernetes kein schwarzer Kasten mehr.