Wie entscheidet der Kubernetes-Scheduler, wo ein Pod läuft?

Er läuft in zwei Phasen. Filtering entfernt Nodes, die den Pod nicht hosten können, auf Basis von Resource Requests gegen allocatable Kapazität, Node Selectors, Taints ohne passende Toleration und Volume- oder Affinity-Constraints. Scoring rankt dann die Übrigen nach Regeln wie Verteilung über Nodes und Bevorzugung weniger ausgelasteter. Der Gewinner wird gebunden, und das kubelet auf dem Node startet den Pod tatsächlich.

Der Scheduler achtet auf Pods ohne zugewiesenen Node und schickt sie durch Filtering und Scoring. Filtering wirft jeden Node raus, der unmöglich funktionieren kann: zu wenig allocatable CPU oder Memory für die Requests des Pods, ein Node Selector, der nicht passt, ein Taint ohne passende Toleration, ein Volume, das in dieser Zone nicht attachen kann. Scoring rankt dann den Rest, bevorzugt Verteilung und ausgeglichene Auslastung, und der oberste Node gewinnt und wird gebunden. Das operativ entscheidende Detail ist, dass nach Requests geplant wird und nicht nach dem, was der Pod tatsächlich verbraucht. Ein Cluster kann also in den Dashboards nach fünfzehn Prozent Auslastung aussehen und trotzdem nichts mehr schedulen, weil alle ihre Requests weit über dem echten Verbrauch gesetzt haben. Wenn ein Pod in Pending hängt, gehe ich direkt auf die Events am Pod, denn der Scheduler sagt dir genau, welches Predicate auf wie vielen Nodes gescheitert ist. Zum Formen der Platzierung nutze ich Topology Spread Constraints über Zonen für Verfügbarkeit und Taints mit Tolerations, um normale Workloads von Nodes mit spezieller Hardware fernzuhalten.