Der cloud-controller-manager ist die Kubernetes-Komponente, die meinen Cluster mit Diensten des Cloud-Providers verbindet. Er sorgt dafür, dass Kubernetes-Funktionen wie LoadBalancer, Persistent Volumes und das Node-Lifecycle für mich in AWS, Azure, Google Cloud oder anderen Plattformen umgesetzt werden.
Wo wird der cloud-controller-manager betrieben?
Ich betreibe den cloud-controller-manager innerhalb der Kubernetes Control Plane. In selbst installierten Clustern läuft er auf meinen Master- bzw. Control-Plane-Nodes als eigener Prozess oder Pod. In gemanagten Clustern wie EKS, AKS oder GKE wird „mein“ Cloud-Controller automatisch vom Provider auf der verwalteten Master-Ebene betrieben, ohne dass ich ihn manuell installieren muss.
Für mein Verständnis ist wichtig: Der Dienst spricht – genau wie scheduler und controller-manager – ausschließlich mit dem kube-apiserver und schreibt seine Ergebnisse über die API in etcd.
Aus welchen Teil-Controllern besteht er?
Der cloud-controller-manager bündelt für mich mehrere spezialisierte Controller:
- Node Controller: Wenn ich einen neuen Cloud-Server starte, wird dieser für mich automatisch als Node im Kubernetes-Cluster registriert.
- Service Controller: Lege ich einen Service vom Typ
LoadBalanceran, erstellt der Controller für mich einen echten Cloud-LoadBalancer. - Route Controller: Erzeugt für mich Netzwerk-Routen, damit meine Pods über Cloud-Netze erreichbar sind.
- Volume Controller: Bindet meine Kubernetes-PersistentVolumes an Cloud-Storage wie AWS EBS oder Azure Disk.
Wie funktioniert der cloud-controller-manager?
Kubernetes arbeitet für mich immer nach dem Desired-State-Prinzip. Der cloud-controller-manager übersetzt diesen Zustand in konkrete Cloud-Operationen:
- Ich reiche meine Objekte über kube-apiserver ein.
- Der Cloud-Controller beobachtet Änderungen.
- Für mich werden Provider-Ressourcen erstellt.
- Status landet wieder in etcd.
- Andere Komponenten reagieren darauf.
Der Prozess läuft für mich vollständig automatisch und idempotent: Ich beschreibe nur, was ich möchte, nicht wie es im Cloud-System umgesetzt wird.
Beispiele meiner Nutzung
Beispiel 1 – Ich erstelle einen LoadBalancer
apiVersion: v1
kind: Service
spec:
type: LoadBalancer
Für mich erzeugt der cloud-controller-manager danach automatisch einen LoadBalancer im Provider und verbindet ihn mit meinen Pods.
Beispiel 2 – Ich registriere einen Node
Starte ich für mich eine neue VM in Azure, meldet der Node-Controller diese sofort über kube-apiserver an – mein Node erscheint ohne manuelles Zutun.
Beispiel 3 – Volume binden
Lege ich für mich eine PVC an, bindet Volume-Controller diese an echtes AWS EBS-Storage, inklusive Provider-ID und Zone.
Was der cloud-controller-manager nicht macht
- Ich starte meine Container über kubelet, nicht über Cloud-Controller
- Reines Pod-Scheduling erledigt für mich kube-scheduler
- Anwendungs-Monitoring ist für mich ein Add-on
- Cloud-Controller ist nur die Provider-Integration
Fazit
Der cloud-controller-manager ist für mich die zentrale Cloud-Native-Schnittstelle der Kubernetes Control Plane. Ich betreibe ihn auf Master-Nodes, er funktioniert rein über kube-apiserver und verbindet meine Kubernetes-Ressourcen mit echten Provider-Diensten wie LoadBalancer, Routen und Volumes.