Kubernetes v1.36: In-Place Vertikales Skalieren für Pod-Level Ressourcen erreicht Beta

TL;DR

Kubernetes v1.36 hat das In-Place Vertikale Skalieren von Pod-Level Ressourcen auf Beta-Status angehoben. Diese Funktion erlaubt es, Ressourcenbudget eines laufenden Pods dynamisch zu aktualisieren, oft ohne einen Neustart der Container. Dies vereinfacht das Management von komplexen Pods und verbessert die Ressourcennutzung während hoher Last.

Hauptinhalt

In der neuesten Version von Kubernetes, v1.36, wurde das In-Place Vertikale Skalieren von Pod-Level Ressourcen auf den Beta-Status angehoben. Diese Funktion ist standardmäßig über das Feature Gate InPlacePodLevelResourcesVerticalScaling aktiviert und ermöglicht es Nutzern, das aggregierte Ressourcenbudget eines laufenden Pods zu ändern. Ein wesentlicher Vorteil dieser Funktion ist, dass sie oft ohne einen Neustart der Container durchgeführt werden kann.

Das Pod-Level Ressourcenmodell vereinfacht die Verwaltung komplexer Pods, insbesondere solcher mit Sidecars, indem es den Containern erlaubt, einen gemeinsamen Pool von Ressourcen zu nutzen. In v1.36 können Administratoren die Grenzen dieses gemeinsamen Pools in Echtzeit anpassen, was besonders nützlich ist, wenn für die Container keine individuellen Limits definiert sind. Bei einer Anpassung der Pod-Level Dimensionen passen sich die Container automatisch an die neuen Grenzen an, was eine flexible Skalierung während Spitzenlasten ermöglicht.

Ein zentrales Element dieser Funktion ist die resizePolicy, die bestimmt, ob ein Neustart der Container erforderlich ist, um die neuen Ressourcenlimits anzuwenden. Der Kubelet überprüft diese Policy für jeden Container, der seine Limits vom Pod-Level Budget erbt. Ist die restartPolicy eines Containers auf NotRequired gesetzt, versucht der Kubelet, die cgroup-Limits dynamisch über die Container Runtime Interface (CRI) zu aktualisieren. Bei der Einstellung RestartContainer wird der Container neu gestartet, um die neuen Grenzen sicher anzuwenden.

Ein Beispiel verdeutlicht die Funktionsweise: Ein Pod wird mit einem CPU-Limit von 2 CPUs definiert. Da die einzelnen Container keine eigenen Limits haben, teilen sie sich diesen Pool. Um die CPU-Kapazität auf 4 CPUs zu verdoppeln, kann ein Patch angewendet werden, der die Spezifikation des Pods aktualisiert.

Technische Details/Implikationen

Bei der Anwendung eines Resize-Patches führt der Kubelet mehrere Prüfungen durch, um die Stabilität des Nodes sicherzustellen. Zunächst erfolgt eine Machbarkeitsprüfung, die sicherstellt, dass die neuen aggregierten Anforderungen innerhalb der verfügbaren Kapazität des Nodes liegen. Sollte der Node überlastet sein, wird der Status PodResizePending angezeigt, um sofortiges Feedback zu geben.

Die Aktualisierung der cgroups erfolgt in einer bestimmten Reihenfolge, um ein Übermaß an Ressourcen zu vermeiden. Bei einer Erhöhung wird zuerst die Pod-Level cgroup erweitert, bevor die cgroups der einzelnen Container vergrößert werden. Bei einer Verringerung werden die cgroups der Container zuerst gedrosselt, bevor die aggregierte Pod-Level cgroup verkleinert wird.

Die Überwachbarkeit des Resize-Status erfolgt durch die Verwendung von Pod-Bedingungen, die den Lebenszyklus eines Resizes verfolgen. Diese Bedingungen geben Auskunft darüber, ob die Spezifikation aktualisiert wurde, ob der Node die Änderung angenommen hat und ob die Änderungen vollständig auf die cgroups angewendet wurden.

Fazit/Ausblick

Die Einführung des In-Place Vertikalen Skalierens in Kubernetes v1.36 stellt einen bedeutenden Fortschritt in der Ressourcennutzung dar und wird voraussichtlich in künftigen Versionen weiter verbessert, insbesondere durch die Integration des Vertical Pod Autoscalers (VPA), der Empfehlungen für Pod-Level Ressourcen abgeben und automatische Anpassungen auslösen kann.