Der kube-scheduler ist die Kubernetes-Komponente, die entscheidet, auf welchem Node ein neuer Pod gestartet wird. Er nimmt dafür meine eingereichten Pod-Definitionen über den kube-apiserver als gewünschten Zustand entgegen und ordnet sie einer passenden Maschine im Cluster zu.
Wo wird der kube-scheduler betrieben?
Der kube-scheduler läuft als Teil der Kubernetes Control Plane. In selbst installierten Clustern betreibe ich ihn typischerweise auf den Control-Plane-/Master-Nodes, oft als statischen Pod oder Systemcontainer. In Cloud-Umgebungen wie AKS, EKS oder GKE wird „mein“ Scheduler vom Provider automatisch innerhalb der gemanagten Master-Ebene betrieben.
Wichtig für mich im Architekturverständnis: Der Scheduler spricht nicht direkt mit den Worker-Nodes, sondern ausschließlich mit dem kube-apiserver. Er schreibt nur in etcd, welchem Node mein Pod zugewiesen wurde (Feld: spec.nodeName).
Wie funktioniert der kube-scheduler?
Wenn ich einen Pod anlege, besitzt er zunächst keine Node-Zuordnung. Der kube-scheduler überwacht über die API alle Pods mit Status Pending und führt für mich einen mehrstufigen Prozess aus:
1. Filtering / Prädikate
Zuerst prüft der Scheduler, welche Nodes für meinen Pod überhaupt infrage kommen. Für mich werden dabei unter anderem diese Kriterien betrachtet:
- Habe ich genügend CPU und RAM auf dem Node?
- Passen meine Taints und Tolerations?
- Erfüllt der NodeSelector meine Labels?
- Passen Volume- und Storage-Anforderungen?
- Verletze ich keine Affinity/Anti-Affinity-Regeln?
2. Scoring
Aus den gefilterten Kandidaten berechnet der Scheduler für mich eine Rangliste. Jeder Node erhält Punkte, zum Beispiel nach:
- gleichmäßiger Verteilung meiner Pods
- bevorzugten Node-Affinity-Regeln
- Image-Lokalität (für mich schnellere Starts)
- Topologie meiner Zonen/Regionen
3. Binding
Der beste Node wird dann über die API gebunden. Für mich landet nur ein Eintrag im Clusterzustand: nodeName = worker-2. Ab diesem Moment startet kubelet meinen Container.
Was der Scheduler selbst nicht macht
Ich habe gelernt, dass der kube-scheduler für mich ausschließlich Planungsentscheidungen trifft:
- Er startet keine Container für mich
- Er überwacht meine Pods nicht nach dem Start
- Er verwaltet meine ReplicaSets nicht
- Das erledigt kubelet bzw. controller-manager
Typische Beispiele meiner Nutzung
NodeSelector – Ich erzwinge ein Label
Wenn ich in meiner YAML schreibe: nodeSelector: disktype=ssd berücksichtigt der kube-scheduler für mich nur SSD-Nodes.
Taints & Tolerations – Ich schütze Spezial-Nodes
Ich taintete einmal einen GPU-Node: kubectl taint node gpu dedicated=gpu:NoSchedule Für mich starteten normale Pods dort nicht mehr, bis ich eine passende Toleration ergänzte.
Affinity – Ich verteile meine Frontends
Mit PodAntiAffinity sorgte ich dafür, dass „meine“ Web-Pods auf verschiedenen Nodes liegen und ich bei Ausfall weiter online bleibe.
Fazit
Der kube-scheduler ist für mich die Komponente, die meine Pods einer passenden Maschine zuweist. Ich betreibe ihn in der Control Plane, er funktioniert rein über API-Entscheidungen und nutzt Filter- und Scoring-Modelle, um meinen gewünschten Zustand optimal im Cluster zu verteilen.