Die Landkarte: Control Plane, Worker, etcd, kubelet

Worum es geht

Bevor wir etwas installieren, die Landkarte: Welches Bauteil hat welche Aufgabe, und was passiert eigentlich zwischen dem Moment, in dem du Enter drückst, und dem Moment, in dem ein Container läuft.

Die Teile

Control Plane — das Gehirn. Vier Bestandteile:

• API-Server: das einzige Tor. Jeder Befehl, jeder Agent und jeder Controller spricht ausschließlich mit ihm. Nichts im Cluster redet direkt mit etcd.
• etcd: der Speicher. Hier steht der komplette Zustand des Clusters — und nur hier.
• Scheduler: entscheidet, auf welchem Knoten ein neuer Pod laufen soll. Er startet nichts, er schreibt nur seine Entscheidung zurück.
• Controller Manager: eine Sammlung von Regelkreisen. Jeder vergleicht ununterbrochen Soll und Ist und arbeitet gegen die Abweichung an.

Worker — die Arbeiter. Zwei Bestandteile:

• kubelet: der Agent, der die Container tatsächlich startet und dem API-Server meldet, was auf seinem Knoten los ist.
• kube-proxy bzw. das CNI: sorgt dafür, dass Pods sich erreichen.

Der Weg eines Befehls

kubectl run hallo --image=nginx sieht aus wie eine Anweisung. Es ist aber nur ein Eintrag in eine Datenbank:

1. kubectl schickt das Objekt an den API-Server
2. Der prüft Rechte und Form und schreibt es nach etcd — fertig, der Befehl ist zurück. Es läuft noch gar nichts.
3. Der Scheduler sieht einen Pod ohne Knoten, sucht einen passenden aus und schreibt den Namen in dasselbe Objekt
4. Das kubelet auf diesem Knoten sieht, dass ihm etwas zugewiesen wurde, holt das Image und startet den Container
5. Es meldet den Zustand zurück an den API-Server, der ihn wieder nach etcd schreibt

Kein Bauteil ruft ein anderes auf. Alle lesen und schreiben denselben Zustand und reagieren auf Änderungen. Das ist der ganze Trick — und der Grund, warum ein ausgefallener Knoten nichts Besonderes ist: Die Abweichung zwischen Soll und Ist wird einfach wieder abgearbeitet.

Warum etcd das empfindlichste Teil ist

etcd ist streng konsistent. Jede Änderung wird zuerst in ein Write-Ahead-Log geschrieben und mit fsync auf das Medium gezwungen — nicht in den Schreibcache, sondern wirklich auf die Platte — bevor sie als erledigt gilt.

Das macht die Platte zum Flaschenhals, und zwar nicht über die Bandbreite, sondern über die Latenz:

Medium	fsync-Dauer, typisch
Festplatte, 7200 U/min	5–15 ms
SATA-SSD	0,1–1 ms
NVMe	0,02–0,1 ms

Die Empfehlung von etcd lautet: Das 99. Perzentil von etcd_disk_wal_fsync_duration_seconds soll unter 10 ms bleiben. Eine drehende Platte liegt im Leerlauf genau an dieser Grenze — und reißt sie, sobald nebenher etwas anderes schreibt.

Was dann passiert, sieht nicht nach einem Plattenproblem aus: Der Leader schickt alle 100 ms Heartbeats, die Wahlfrist liegt bei 1000 ms. Verzögern sich die Schreibvorgänge, verpasst er Heartbeats — und das Cluster wählt einen neuen Leader, obwohl nichts kaputt ist. Im Log steht dann apply entries took too long, und man sucht überall, nur nicht bei der Platte.

Der Sprung von der Festplatte zur SSD ist gewaltig. Der Sprung von SATA-SSD zu NVMe ist für ein Labor bedeutungslos. Deshalb bekommt die Control Plane hier eine SSD — und nur sie.

Und was ist mit CPU und RAM?

CPU ist bei kleinen Clustern praktisch nie der Engpass. Der API-Server braucht Rechenzeit vor allem für TLS-Handshakes und das Serialisieren großer Listenabfragen. Bei vier Knoten sind das wenige Prozent eines Kerns.

RAM entscheidet dagegen darüber, was zusätzlich auf die Control Plane passt: Grundlast rund 2 GB, Prometheus nochmal 1–2 GB, Argo CD etwa 1 GB. Wer aufrüsten will, kauft Speicher — nicht Takt.

Selbst messen

# Zustand aller Bauteile (der alte Befehl componentstatuses ist veraltet)
kubectl get --raw='/readyz?verbose'

# Die Control Plane laeuft selbst als Pods
kubectl -n kube-system get pods -o wide

# Der eingebaute Pruefstand von etcd
etcdctl check perf

Zum Nachlesen

• Kubernetes Components
• Operating etcd for Kubernetes
• etcd: Hardware recommendations

Eine geordnete Übersicht über die offizielle Dokumentation — welcher Bereich wann hilft und was zu welchem Modul gehört — steht unter Nachlesen.