Kubernetes v1.32 aktiviert QueueingHint zur Optimierung des Durchsatzes der Pod-Scheduling

In einem Beitrag im Kubernetes Blog im Dezember 2024 beschrieb Kensei Nakada von Tetrate.io eine bedeutende interne Verbesserung des Kubernetes Schedulers, die in Version 1.32 eingeführt wurde. Dieses Update stabilisiert den Mechanismus QueueingHint und aktiviert ihn standardmäßig. Diese Funktion ist darauf ausgelegt, die unnötige Verarbeitungslast auf dem Scheduler zu reduzieren, indem sie intelligent verwaltet, wann nicht planbare Pods erneut versucht werden.

Was passiert ist

Der Kubernetes Scheduler ist dafür verantwortlich, neue Pods Knoten innerhalb eines Clusters zuzuweisen. Er verarbeitet diese Pods sequenziell, was bedeutet, dass mit zunehmender Größe der Cluster der Durchsatz des Schedulers zu einem kritischen Leistungsengpass wird. Über mehrere Jahre hinweg hat die Kubernetes SIG Scheduling Gruppe verschiedene Verbesserungen implementiert, um diesen Durchsatz zu steigern. Die neueste große Verbesserung, enthalten in Kubernetes v1.32, führt ein Element des Scheduling-Kontexts namens QueueingHint ein.

Vor dieser Release verwaltete der Scheduler nicht geplante Pods über drei interne Datenstrukturen: ActiveQ für neue oder bereit zum erneuten Versuch stehende Pods, BackoffQ für Pods, die nach fehlgeschlagenen Versuchen eine Backoff-Periode abwarten, und den Unschedulable Pod Pool für Pods, die derzeit nicht geplant werden können. Wenn ein Pod einen Scheduling-Zyklus fehlschlägt, wechselt er typischerweise in den Unschedulable Pod Pool. Der Scheduler verschiebt diese Pods nur dann zurück in ActiveQ oder BackoffQ, wenn spezifische Cluster-Änderungen auftreten, die den Scheduling-Fehler möglicherweise beheben könnten.

Zuvor war die Logik zur Bestimmung, welche Cluster-Ereignisse einen Fehler beheben könnten, breit gefächert und oft ineffizient. Plugins registrierten allgemeine Cluster-Ereignisse, wie das Erstellen oder Löschen von Objekten, über EnqueueExtensions. Wenn eines der registrierten Ereignisse auftrat, wiederholte der Scheduler den Versuch für den Pod, selbst wenn das Ereignis für den spezifischen Grund des vorherigen Fehlers irrelevant war. Zusätzlich versuchte eine interne Funktion namens preCheck, Ereignisse basierend auf Kernbeschränkungen zu filtern, war aber nicht für benutzerdefinierte Plugins erweiterbar und lacked Präzision.

Wie es funktioniert

QueueingHint verfeinert diesen Wiederholungsmechanismus, indem es jedem Plugin erlaubt, sich auf spezifische Cluster-Ereignisse zu abonnieren und eine granulare Entscheidung darüber zu treffen, ob ein eingehendes Ereignis einen bestimmten Pod tatsächlich planbar machen könnte. Anstatt einen Pod pauschal neu zu versuchen, wann immer ein registriertes Ereignis auftritt, fragt der Scheduler nun das relevante Plugin, ob die spezifische Änderung relevant ist.

Betrachten Sie beispielsweise einen Pod namens pod-a, der eine bestimmte Pod-Affinität erfordert. Wenn das InterPodAffinity-Plugin pod-a ablehnt, weil kein vorhandener Knoten einen passenden Pod hat, gelangt pod-a in den Unschedulable Pod Pool. Der Scheduler protokolliert, dass InterPodAffinity die Ablehnung verursacht hat. Mit QueueingHint abonniert das InterPodAffinity-Plugin Updates für Pod-Labels. Wenn ein laufender Pod ein Label-Update erhält, das jetzt mit der Affinitätsanforderung von pod-a übereinstimmt, erkennt der QueueingHint-Callback des Plugins diese Übereinstimmung und veranlasst den Scheduler, pod-a zurück in ActiveQ oder BackoffQ zu verschieben. Wenn das Label-Update nicht übereinstimmt, bleibt der Pod im Pool, was einen Scheduling-Zyklus spart.

Diese Funktion befindet sich seit Kubernetes v1.28 in der Entwicklung. Sie war zunächst standardmäßig aktiviert, wurde aber in einem Patch-Release aufgrund eines gemeldeten Speicherlecks deaktiviert. Zwischen v1.28 und v1.31 haben Mitwirkende das Speicherleck behoben und QueueingHints in allen In-Tree-Plugins implementiert. In v1.32 ist die Funktion wieder standardmäßig aktiviert, wobei die Implementierung abgeschlossen und die Stabilitätsprobleme gelöst sind.

Wichtige Details

• Version: Die QueueingHint-Funktion ist in Kubernetes v1.32 standardmäßig aktiviert.
• Mechanismus: QueueingHint ermöglicht es Plugins, spezifische Cluster-Ereignisse auszuwerten, um zu entscheiden, ob ein nicht planbarer Pod erneut versucht werden sollte.
• Früheres Problem: Ältere Methoden nutzten breite Ereignisregistrierungen, was zu unnötigen Scheduling-Wiederholungen für Pods führte, die weiterhin nicht planbar blieben.
• Erweiterbarkeit: Im Gegensatz zur älteren preCheck-Funktion ist QueueingHint erweiterbar und funktioniert mit benutzerdefinierten Plugins, wodurch Issue #110175 adressiert wird.
• Geschichte: Die Funktion wurde experimentell in v1.28 eingeführt, aufgrund eines Speicherlecks deaktiviert und in nachfolgenden Versionen stabilisiert.
• Komponente: Die Optimierung zielt auf die Scheduling-Warteschlange ab, insbesondere auf die Bewegung von Pods zwischen dem Unschedulable Pod Pool und ActiveQ/BackoffQ.

Warum es wichtig ist

Für Ingenieure, die großskalige Kubernetes-Cluster verwalten, beeinflusst der Scheduler-Durchsatz direkt die Geschwindigkeit der Anwendungs-Bereitstellung und die Ressourcennutzung. Jedes Mal, wenn der Scheduler versucht, einen Pod zu platzieren, der keine Chance hat, geplant zu werden, verbraucht er CPU-Zyklen und erhöht die Latenz bei der Verarbeitung anderer ausstehender Pods. Durch die Beseitigung dieser vergeblichen Wiederholungen reduziert QueueingHint den Rechenaufwand auf der Control Plane.

Diese Optimierung ist besonders wertvoll für Cluster mit komplexen Scheduling-Anforderungen, wie solche, die umfangreiche Pod-Affinitäts- oder Anti-Affinitätsregeln verwenden. In solchen Umgebungen gelangen Pods häufig in den Unschedulable Pod Pool. Ohne präzise Wiederholungslogik könnte der Scheduler diese Pods wiederholt für irrelevante Cluster-Änderungen wecken, was Rauschen erzeugt und das Scheduling von viable Pods verzögert. QueueingHint stellt sicher, dass nur bedeutsame Änderungen eine Wiederholung auslösen und die Scheduling-Pipeline effizient halten.

Darüber hinaus kommt die Erweiterbarkeit von QueueingHint Entwicklern zugute, die benutzerdefinierte Scheduling-Plugins schreiben. Zuvor konnten benutzerdefinierte Plugins das effiziente Filtern durch preCheck nicht nutzen, was sie dazu zwang, sich auf breitere, weniger effiziente Ereignisauslöser zu verlassen. Jetzt können benutzerdefinierte Plugins ihre eigene QueueingHint-Logik implementieren, um sicherzustellen, dass sie nahtlos in den optimierten Wiederholungsmechanismus des Schedulers integriert werden. Dies führt zu einer konsistenteren Leistung sowohl in Standard- als auch in benutzerdefinierten Scheduling-Workflows.

Was Sie tun können

• Aktualisieren Sie Ihre Testcluster auf Kubernetes v1.32, um das stabilisierte QueueingHint-Verhalten zu beobachten.
• Überprüfen Sie benutzerdefinierte Scheduling-Plugins, um sicherzustellen, dass sie QueueingHint-Callbacks für präzises Event-Handling implementieren.
• Überwachen Sie Scheduler-Metriken auf reduzierte Wiederholungsraten und verbesserten Durchsatz in Hochlast-Szenarien.
• Prüfen Sie auf verbleibende Speichernutzungsmuster, wenn Sie zuvor Probleme mit der experimentellen v1.28-Implementierung hatten.
• Konsultieren Sie die Dokumentation der Kubernetes SIG Scheduling für detaillierte Anleitungen zur Implementierung von QueueingHint in benutzerdefinierten Plugins.
• Bewerten Sie die Cluster-Leistung vor und nach dem Upgrade, um die Reduktion unnötiger Scheduling-Zyklen zu quantifizieren.