kubelet ist der wichtigste Prozess auf meinen Kubernetes-Worker-Nodes. Er sorgt dafür, dass die vom kube-apiserver beschriebenen Pods tatsächlich gestartet und dauerhaft ausgeführt werden. Ohne kubelet würde auf meinen Nodes kein einziger Kubernetes-Pod laufen.
Wo ich kubelet betreibe
kubelet läuft auf jeder Worker Node als lokaler Systemdienst. Wenn ich einen Cluster selbst installiere, starte ich kubelet direkt auf dem Betriebssystem meiner Nodes, zum Beispiel über kubeadm oder andere Distributionen. In Cloud-Clustern wie AKS oder EKS wird kubelet für mich ebenfalls auf den Worker-Maschinen betrieben, dort aber vom Provider vorkonfiguriert.
Für mich ist kubelet die einzige Komponente, die direkt mit der Container Runtime meiner Node spricht (über das CRI-Interface wie containerd oder CRI-O).
Wie kubelet für mich funktioniert
Start meiner Pods
Der Prozess folgt für mich diesem Prinzip: Ich beschreibe einen Pod in der Kubernetes API, der Scheduler weist ihm einen Node zu, und kubelet liest diesen Eintrag. Danach startet kubelet über die Container Runtime genau die Container, die in meiner Pod-Spec stehen.
Monitoring und Desired State
kubelet überwacht für mich ständig:
- Laufen meine Container?
- Passen Health-Checks (Liveness/Readiness) zu meiner Definition?
- Sind Volumes korrekt eingebunden?
- Wurden Images aktualisiert?
Der Status meiner Pods wird vom kubelet wieder an kube-apiserver gemeldet und landet damit in etcd. So bleibt der Zustand für mich aktuell.
Was kubelet selbst nicht macht
- kubelet entscheidet nicht, wo ein Pod laufen soll
- Er verwaltet keine Deployments oder ReplicaSets
- Er ist nur der Ausführungs-Agent meiner Node
Wie kubelet meine Container startet – Beispiel
Wenn ich einen Pod mit Liveness-Probe beschreibe, führt kubelet für mich automatisch den Health-Check aus und startet den Container neu, wenn die Probe fehlschlägt.
Bei einem ConfigMap-Update mounted kubelet für mich die neue Konfiguration ohne Node-Neustart.
Fazit
kubelet ist für mich der lokale Kubernetes-Agent, den ich auf jeder Worker Node betreibe. Er liest meine Pod-Vorgaben aus der API, spricht direkt mit containerd/CRI-O und überwacht dauerhaft den Lifecycle meiner Pods. Für mein Kubernetes-Verständnis ist kubelet die Brücke zwischen Control Plane und der realen Container-Ausführung.