Der kube-controller-manager ist ein zentraler Dienst in Kubernetes, der eine ganze Sammlung von Controllern bündelt. Für Kubernetes übernimmt er die Aufgabe, den von mir über den kube-apiserver beschriebenen gewünschten Zustand (Desired State) ständig mit der realen Umgebung im Cluster abzugleichen.
Wo wird der kube-controller-manager betrieben?
Der kube-controller-manager läuft innerhalb der Kubernetes Control Plane. Wenn ich selbst Cluster mit kubeadm oder auf Bare Metal installiere, wird dieser Dienst für mich typischerweise auf den Master- bzw. Control-Plane-Nodes als statischer Pod gestartet. In Cloud-Umgebungen wie AKS, EKS oder GKE betreibe ich ihn nicht direkt – dort wird „mein“ kube-controller-manager automatisch vom Provider in der gemanagten Master-Ebene betrieben.
Für mich ist wichtig: Der Dienst spricht ausschließlich mit dem kube-apiserver. Er greift im Alltag nicht direkt auf Worker-Nodes zu, sondern liest und schreibt alle Informationen über die API und damit letztlich in etcd.
Wie funktioniert der kube-controller-manager?
Für mich besteht Kubernetes aus vielen kleinen Regelkreisen. Jeder Controller überwacht über die API bestimmte Objekte und sorgt dafür, dass sie korrekt umgesetzt werden. Der kube-controller-manager fasst diese Controller als einen Prozess zusammen.
Die wichtigsten Controller, die ich nutze
- Node Controller: Wenn für mich ein Node ausfällt, markiert er ihn als „NotReady“ und löst für mich Neuplanung von Pods aus.
- ReplicaSet Controller: Ich schreibe replicas=3 in mein Deployment, der Controller erzeugt oder löscht für mich Pods, bis exakt drei laufen.
- Endpoints Controller: Ich lege einen Service an, der Controller pflegt für mich die Liste der erreichbaren Pod-IP-Adressen.
- Service Account & Token Controller: Für mich werden automatisch Accounts und Tokens erstellt, die meine Pods später nutzen können.
Abgleich zwischen Wunsch und Realität
Wenn ich über kube-apiserver ein Objekt ändere, passiert für mich folgendes:
- Ich reiche meinen Zustand in der API ein.
- Der passende Controller beobachtet „meine“ Ressource.
- Er berechnet, was konkret zu tun ist.
- Neue Pods/Objekte werden für mich angelegt oder entfernt.
- Status wird wieder in etcd geschrieben.
Für mich ist dieser permanente Loop die eigentliche Stärke von Kubernetes – und controller-manager ist die Umsetzung davon.
Wie er arbeitet – technisch für mich erklärt
- Er nutzt Watch-Mechanismen des kube-apiserver.
- Jeder Controller arbeitet gegen ResourceVersions.
- Er führt Änderungen idempotent für mich aus.
- Bei Konflikten entscheidet für mich die API (Optimistic Locking).
Was der kube-controller-manager nicht macht
Ich trenne inzwischen klar:
- Er startet meine Container nicht selbst
- kubelet betreibt „meine“ Pods auf Nodes
- scheduler weist Node zu
- controller-manager ist nur die Abgleich-Automatik
Fazit
Der kube-controller-manager ist für mich die Automatik der Kubernetes Control Plane. Ich betreibe ihn auf Master-/Control-Plane-Nodes, er spricht ausschließlich mit kube-apiserver und sorgt in vielen parallelen Loops dafür, dass mein gewünschter Zustand im Cluster dauerhaft erhalten bleibt.