Die dynamische Ressourcenallokation (DRA) in Kubernetes erweitert das Ressourcenmanagement und verändert das Verhalten desSchedulers. In Version 1.36 geht es nicht mehr nur um GPUs, sondern auch um CPUs, Speicher und die Vorhersehbarkeit der Platzierung.
Das Problem zeigt sich in heterogenen Clustern, in denen die Ressourcen in Typ und Zustand variieren. Strikte Anforderungen an bestimmte Geräte verringern den Durchsatz und führen zu Fragmentierung. Der Scheduler findet entweder keine geeignete Ressource oder trifft eine suboptimale Wahl. Darüber hinaus verschlechtert sich das System bei Geräteausfällen, wenn es kein klares Modell ihres Zustands und ihrer Verfügbarkeit gibt. Dies ist besonders auffällig bei AI/ML-Lasten, bei denen Topologie und Verfügbarkeit von Beschleunigern wichtig sind.
In Kubernetes 1.36 entwickelt sich die dynamische Ressourcenallokation in Richtung Flexibilität und Steuerbarkeit. Die Schlüsseländerung ist die Möglichkeit, eine Prioritätenliste für Ressourcen anstelle einer strikten Auswahl festzulegen. Dies verringert die Wahrscheinlichkeit der Blockierung von Pods und erhöht die Auslastung. Parallel dazu wurde die Kompatibilität mit dem Legacy-Ansatz über erweiterte Ressourcen hinzugefügt, was die Migration zu ResourceClaim schrittweise gestaltet. Dies ist ein pragmatischer Kompromiss: Betreiber können DRA implementieren, ohne bestehende Workloads zu beeinträchtigen.
Die Implementierung stützt sich auf mehrere Ebenen. Auf der Ebene der Geräte wurden partitionierbare Geräte eingeführt, die es ermöglichen, physische Hardware in logische Teile zu unterteilen. Dies ist entscheidend für teure Beschleuniger, bei denen die Dichte der Platzierung wichtig ist. Das Management der Ressourcenqualität wird durch Device Taints und Toleranzen verstärkt – fehlerhafte oder reservierte Geräte werden aus dem allgemeinen Pool ausgeschlossen. Parallel dazu verhindern Bindungsbedingungen die vorzeitige Zuweisung von Pods, solange externe Ressourcen nicht bereit sind, was die Anzahl der Ausfälle beim Start verringert.
Die Beobachtbarkeit ist ebenfalls Teil des Modells geworden. Durch den Ressourcen-Gesundheitsstatus spiegelt der Zustand der Geräte nun direkt den Status des Pods wider. Dies beseitigt die Notwendigkeit, Treiberprotokolle zu analysieren, und beschleunigt die Diagnose. Darüber hinaus bietet der Status des Ressourcenpools einen Überblick über die Verfügbarkeit der Ressourcen, was die Kapazitätsplanung vereinfacht. Dabei standardisiert die Geräte-Metadaten die Übertragung von Informationen in Container über JSON-Dateien, wodurch die Notwendigkeit entfällt, während der Ausführung auf die Kubernetes-API zuzugreifen.
Eine separate Schicht von Änderungen betrifft den Scheduler. Es wurde eine lexikographische Reihenfolge zur Bewertung von Ressourcen eingeführt, die es Treibern ermöglicht, die Platzierungsstrategie zu beeinflussen. Dies erhöht die Vorhersehbarkeit und kann die Latenz bei der Entscheidungsfindung verbessern. Auch die Logik der Einschränkungsbewertung wurde aktualisiert: Die Funktionen matchAttribute und distinctAttribute arbeiten nun besser mit Wertemengen, während includes() die Fragilität bei der Änderung des Attributformats verringert.
Die Erweiterung von DRA auf CPU und Speicher ist ein wichtiger Schritt. Dies überträgt fortschrittliche Platzierungsmechanismen, einschließlich des NUMA-aware Ansatzes, auf grundlegende Ressourcen. Allerdings erhöht dies die Komplexität der Konfiguration und die Anforderungen an das Verständnis der Topologie. Ein solcher Ansatz bietet mehr Kontrolle, erfordert jedoch eine sorgfältige Anpassung.
Neue Möglichkeiten für PodGroups mit ResourceClaim beseitigen die Skalierungsbeschränkungen. Zuvor gab es Grenzen für die gemeinsame Nutzung von Ressourcen zwischen Pods. Jetzt wird das Management zentralisierter und weniger abhängig von externen Orchestratoren. Dies ist besonders wichtig für große verteilte Workloads.
Das Ergebnis der Änderungen ist eine evolutionäre Verstärkung von DRA als universeller Schicht für das Ressourcenmanagement. Die Flexibilität der Planung hat sich verbessert, die Transparenz des Zustands ist gestiegen und die Integration mit bestehenden Systemen wurde vereinfacht. Dabei sind Leistungskennzahlen nicht direkt angegeben, sodass die Bewertung der Auswirkungen auf der Ebene architektonischer Vorteile bleibt.