Kubernetes v1.37 (Garhwal): Das ist neu und besser

TL;DR

Kubernetes v1.37 ("Garhwal") liefert 67 Enhancements: 16 Stable, 23 Beta, 27 Alpha und 1 Entfernung. Die wichtigsten Neuerungen sind In-Place-Resize für Init- und Sidecar-Container (GA), konfigurierbare HPA-Toleranz (GA), Node Declared Features (GA), Scale-to-Zero für den HorizontalPodAutoscaler (Beta), Memory QoS (Beta), Pod-Level Resource Manager (Beta), Gang Scheduling über die neue Workload API (Beta) und der Rootless-Modus für das Kubelet (Beta). Zu den Alpha-Features gehören eine kooperative Eviction Request API und Checkpoint/Restore auf Pod-Ebene sowie weitere Fortschritte bei Dynamic Resource Allocation (DRA). Wichtig: Das SELinux-Mount-Labeling ändert sich in diesem Release standardmäßig und kann bestehende Workloads auf Clustern mit aktiviertem SELinux beeinträchtigen.

Kubernetes v1.37, auch bekannt als "Garhwal", bringt eine starke Reihe von Änderungen für Teams, denen Ressourcenmanagement, Autoscaling und Scheduling wichtig sind. Das Release umfasst 67 Enhancements: 16 davon sind jetzt Stable (GA), 23 Beta, 27 Alpha, und 1 Feature wurde entfernt. Der Name stammt von Garhwal, einer Himalaya-Region im indischen Bundesstaat Uttarakhand. Das Thema dreht sich um Schichten, die miteinander verbunden sind und einander tragen – von Terrassenfeldern bis zu Bergbächen – und passt damit gut zu einem Release, das konsequent auf früheren Versionen aufbaut.

Auf diese Features in Kubernetes v1.37 freuen wir uns besonders: In-Place-Resize für Init- und Sidecar-Container, Scale to Zero für den HorizontalPodAutoscaler, Memory QoS und natives Gang Scheduling über die Workload API. Viele dieser Neuerungen helfen Kubernetes dabei, Ressourcen effizienter zu nutzen, anhand der tatsächlichen Nachfrage zu skalieren und eng gekoppelte Workloads besser zu platzieren.

Das sind die wichtigsten Änderungen in Kubernetes v1.37:

Stable Features in Kubernetes v1.37

1. In-Place Pod Resize für Init- und Sidecar-Container

Feature-Gruppe: SIG Node | KEP: #1287

In-Place Pod Resize wurde in Kubernetes v1.35 Stable (GA). Mit v1.37 wird diese Unterstützung auf Init- und Sidecar-Container ausgeweitet – und auch dieser Teil ist jetzt GA.

Vor dieser Änderung konnten Sie CPU und Arbeitsspeicher eines laufenden App-Containers ohne Neustart anpassen, Init- und Sidecar-Container blieben jedoch außen vor. Ein Sidecar-Container ist ein Init-Container mit restartPolicy: Always und läuft damit über die gesamte Lebensdauer des Pods. Brauchte ein Sidecar mehr CPU oder Speicher, blieb praktisch nur, den Pod neu zu erstellen. Das bedeutete Ausfallzeit auch für die Hauptanwendung, obwohl nur der Sidecar die Änderung benötigte.

Mit v1.37 ist das Feature-Gate InPlacePodVerticalScalingInitContainers GA. Sie können die CPU- und Speicher-Requests oder -Limits eines laufenden Sidecar-Containers ändern, und das Kubelet aktualisiert die cgroup-Einstellungen des Containers im laufenden Betrieb. Der Pod läuft einfach weiter. Über resizePolicy steuern Sie pro Ressource, was passiert: NotRequired wendet die Änderung live an, RestartContainer startet nur diesen einen Container neu. v1.37 ergänzt dasselbe Feature außerdem um zwei Alpha-Bausteine: das In-Place-Resizing von speichergestützten emptyDir-Volumes (Gate InPlacePodVerticalScalingMemoryBackedVolumes) und die Möglichkeit, dass der Scheduler Pods mit niedrigerer Priorität verdrängt, um Platz für ein aufgeschobenes Resize zu schaffen (Gate InPlacePodVerticalScalingSchedulerPreemption).

apiVersion: v1
kind: Pod
metadata:
  name: app-with-sidecar
spec:
  initContainers:
  - name: log-shipper        # sidecar
    image: log-shipper:1.0
    restartPolicy: Always
    resizePolicy:
    - resourceName: cpu
      restartPolicy: NotRequired
    - resourceName: memory
      restartPolicy: RestartContainer
    resources:
      requests:
        cpu: "100m"
        memory: "128Mi"
      limits:
        cpu: "200m"
        memory: "256Mi"
  containers:
  - name: app
    image: app:1.0
    # ...

Mit diesem Setup können Sie die CPU des Sidecars ganz ohne Neustart erhöhen. Eine Erhöhung des Speichers startet nur diesen einen Container neu – niemals den gesamten Pod.

2. Konfigurierbare Toleranz für HorizontalPodAutoscaler

Feature-Gruppe: SIG Autoscaling | KEP: #4951

In Kubernetes v1.37 hat die konfigurierbare Toleranz für den HorizontalPodAutoscaler (HPA) den Status General Availability (GA) erreicht.

Der HPA passt die Anzahl der Pod-Replikas anhand von Metriken wie CPU oder Arbeitsspeicher an. Vor diesem Feature nutzte der HPA eine feste Toleranz von 10 % für den gesamten Cluster. Er wurde erst aktiv, wenn die Auslastung mehr als 10 % vom Zielwert abwich. Dieser eine Wert passte nicht zu jedem Workload. Sensible Services konnten zu träge reagieren, und um den Wert zu ändern, mussten Sie ein globales Controller-Flag anpassen, das jeden HPA im Cluster betraf.

Mit v1.37 ist das Feature-Gate HPAConfigurableTolerance GA. Sie können die Toleranz pro HPA und pro Skalierungsrichtung im Feld behavior festlegen. Eine enge Toleranz beim Hochskalieren lässt einen kritischen Service schon auf kleine Lastanstiege reagieren. Eine großzügigere Toleranz an anderer Stelle hält ruhigere Workloads stabil. Das Feature war in v1.35 Beta und ist jetzt Standardverhalten.

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: web-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: web
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 60
  behavior:
    scaleUp:
      tolerance: 0.05

Die Toleranz ist ein Verhältnis, keine Angabe in Prozentpunkten. Mit 0.05 und einem Zielwert von 60 % skaliert der HPA hoch, sobald die CPU-Auslastung etwa 63 % übersteigt (60 % mal 1,05). Der HPA reagiert damit früher, als es die alte feste 10-%-Toleranz erlaubt hätte.

3. Node Declared Features

Feature-Gruppe: SIG Node | KEP: #5328

In Kubernetes v1.37 haben Node Declared Features den Status General Availability (GA) erreicht.

Vor diesem Feature ging Kubernetes davon aus, dass ein Node jedes Feature beherrscht, das die Control Plane unterstützt – solange die Versionen innerhalb des unterstützten Skews lagen. Das stimmt aber nicht immer. Wurde ein neues Feature auf der Control Plane aktiviert, konnte der Scheduler einen Pod, der es nutzt, trotzdem auf einem älteren Node platzieren, der es noch nicht unterstützte. Der Pod scheiterte dann zur Laufzeit oder blieb nach dem Scheduling hängen, obwohl die Platzierung korrekt aussah.

Mit v1.37 ist das Feature-Gate NodeDeclaredFeatures GA. Jeder Node veröffentlicht jetzt die Menge der Features, die er versteht, im Feld status.declaredFeatures des Node-Objekts. Scheduler und Admission-Checks nutzen diese Information, um Pods, die ein Feature verwenden, nur auf Nodes zu platzieren, die diese Features unterstützen. So wird aus einem Laufzeitfehler eine klare Scheduling-Entscheidung – besonders wichtig bei Upgrades, wenn Node-Versionen gemischt sind. Node Declared Features war in v1.35 Alpha.

Beta Features in Kubernetes v1.37

4. Scale to Zero für HorizontalPodAutoscaler

Feature-Gruppe: SIG Autoscaling | KEP: #2021

In Kubernetes v1.37 hat Scale to Zero für den HorizontalPodAutoscaler den Beta-Status erreicht und ist standardmäßig aktiviert.

Vor diesem Feature konnte ein HPA einen Workload nicht auf null Replikas herunterskalieren. Das Minimum lag bei eins. Für einen Service, der nur zeitweise Arbeit hat – etwa einen Queue-Consumer oder einen Batch-Worker – hieß das: mindestens einen laufenden Pod bezahlen, selbst wenn es nichts zu tun gab.

Mit v1.37 können Sie spec.minReplicas: 0 auf einem HPA setzen und den Workload im Leerlauf auf null herunterskalieren lassen – und wieder hochfahren, sobald die Nachfrage zurückkehrt. Das funktioniert für Workloads, die über Object- oder External-Metriken gesteuert werden, etwa eine Queue-Länge. Für CPU- oder Speichermetriken funktioniert es nicht, weil diese Metriken von laufenden Pods stammen – und bei null gibt es keine. Das kann die Kosten für Queue-Consumer, Batch-Jobs und GPU-Workloads senken, die zwischen den Läufen brachliegen. Solange der HPA einen Workload bei null hält, setzt er eine ScaledToZero-Condition auf True. So lässt sich unterscheiden, ob ein Workload vom HPA auf null skaliert oder von Hand abgeschaltet wurde. Skaliert er wieder hoch, wechselt die Condition auf False mit dem Grund NotScaledToZero.

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: worker-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: queue-worker
  minReplicas: 0
  maxReplicas: 20
  metrics:
  - type: External
    external:
      metric:
        name: queue_messages
      target:
        type: AverageValue
        averageValue: "30"

Mit dieser Konfiguration fällt der Workload auf null Pods, wenn die Queue leer ist, und der HPA skaliert ihn wieder hoch, sobald Nachrichten eintreffen.

5. Memory QoS

Feature-Gruppe: SIG Node | KEP: #2570

In Kubernetes v1.37 hat Memory QoS den Beta-Status erreicht.

Vor diesem Feature setzte das Kubelet für einen Container ein hartes Speicherlimit (cgroup memory.max), gab dem Kernel aber keine weicheren Signale. Ein Container konnte Speicher bis knapp ans Limit verbrauchen und wurde dann fast ohne Vorwarnung per OOM-Kill beendet. Außerdem gab es keinen Speicherschutz, der an den Request eines Containers gekoppelt war – unter Speicherdruck konnte der Kernel also Seiten von einem Container zurückfordern, der noch innerhalb seines Requests lag.

Mit v1.37 ist das Feature-Gate MemoryQoS Beta. Es nutzt die Speicher-Controls von cgroup v2, um dem Kernel bessere Signale zu geben. Das Kubelet setzt memory.min anhand des Memory-Requests eines Containers und schützt diesen Speicher damit vor Reclaim. Wenn Sie memoryThrottlingFactor in der Kubelet-Konfiguration setzen, setzt das Kubelet zusätzlich memory.high als Drosselungsschwelle unterhalb des Limits. Der Kernel bremst den Container dann und fordert Seiten zurück, bevor er das harte Limit erreicht und per OOM-Kill beendet wird. Standardmäßig ist memoryThrottlingFactor nicht gesetzt, und memory.high bleibt deaktiviert, solange Sie es nicht konfigurieren. Voraussetzung ist cgroup v2 – seit v1.35 ohnehin der einzige unterstützte Modus.

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
memoryThrottlingFactor: 0.9

Mit dieser Einstellung setzt das Kubelet memory.high für Container unterhalb ihres Speicherlimits, basierend auf dem Faktor 0.9. Der Kernel fordert Speicher zurück und drosselt den Container, bevor er das harte Limit erreicht – OOM-Kills unter Last werden dadurch unwahrscheinlicher.

6. Pod-Level Resource Manager

Feature-Gruppe: SIG Node | KEP: #5526

In Kubernetes v1.37 haben die Pod-Level Resource Manager den Beta-Status erreicht.

Kubernetes v1.34 führte Pod-Level Resources ein (KEP #2837), mit denen sich CPU- und Speicher-Requests und -Limits für den gesamten Pod statt nur pro Container festlegen lassen. Die Resource Manager des Kubelets verstanden diese Pod-Level-Werte allerdings noch nicht. Vor diesem Feature betrachteten CPU Manager, Memory Manager und Topology Manager nur die Requests einzelner Container. Ein Pod, der Ressourcen auf Pod-Ebene definierte, konnte dadurch exklusives CPU-Pinning oder NUMA-Alignment verpassen.

Mit v1.37 ist das Feature-Gate PodLevelResourceManagers Beta. In v1.37 ist es standardmäßig deaktiviert: Es war zunächst aktiviert, wurde aber spät im Release-Zyklus wieder abgeschaltet, nachdem das Team kritische Probleme gefunden hatte. Wer es nutzen möchte, aktiviert es also selbst. Ist es aktiv, berücksichtigen der CPU Manager (Static Policy), der Memory Manager und der Topology Manager Pod-Level-Ressourcen bei der Zuweisung von CPUs, Speicher und Hardware-Lokalität. Das hilft latenzsensiblen und anspruchsvollen Workloads, die Ressourcen auf Pod-Ebene definieren – sie bekommen weiterhin exklusive Cores und NUMA-ausgerichteten Speicher.

apiVersion: v1
kind: Pod
metadata:
  name: guaranteed-pod
spec:
  resources:              # pod-level resources
    requests:
      cpu: "2"
      memory: "4Gi"
    limits:
      cpu: "2"
      memory: "4Gi"
  containers:
  - name: app
    image: app:1.0
    # containers can set their own resources, or use the pod-level ones

Mit dieser Konfiguration ist der Pod auf Pod-Ebene Guaranteed, und die Manager des Kubelets können ganze CPUs pinnen und Speicher für ihn ausrichten – selbst wenn der Container keine eigenen Requests setzt.

7. Gang Scheduling mit der Workload API

Feature-Gruppe: SIG Scheduling | KEP: #4671

In Kubernetes v1.37 hat natives Gang Scheduling über die Workload API den Beta-Status erreicht.

Vor diesem Feature plante Kubernetes Pods einzeln ein. Bei eng gekoppelten Jobs – etwa einem verteilten Trainingslauf, bei dem alle Worker gemeinsam starten müssen – führte das zu partiellem Scheduling: Einige Pods starteten, andere blieben pending, belegten Ressourcen und leisteten nichts. Teams mussten einen externen Scheduler ergänzen, um Alles-oder-nichts-Verhalten (Gang) zu bekommen. Kubernetes v1.35 führte natives Gang Scheduling als Alpha über eine neue Workload API ein.

Mit v1.37 lautet die API jetzt scheduling.k8s.io/v1beta1. Aktiviert wird sie über das Feature-Gate GenericWorkload. In v1.37 wurden die älteren Gates GangScheduling und WorkloadAwarePreemption in GenericWorkload zusammengeführt – ein Gate deckt jetzt sowohl Gang Scheduling als auch Workload-aware Preemption ab. Das Modell besteht aus drei Teilen: Ein Workload enthält ein oder mehrere podGroupTemplates, jeweils mit einer Scheduling-Policy wie gang und einem minCount. Eine PodGroup wird aus einem Template erzeugt und verfolgt eine laufende Gruppe. Jeder Pod verweist über schedulingGroup.podGroupName auf seine Gruppe. Der Scheduler hält die Pods zurück, bis mindestens minCount von ihnen gemeinsam laufen können, und platziert sie dann. Kann er minCount nicht erreichen, wird keiner gebunden, und die Pods warten, bis Platz ist. Das Feld minCount bleibt nach der Erstellung änderbar – hilfreich für elastische Jobs, die hoch- oder herunterskalieren.

Der Workload definiert das Template:

apiVersion: scheduling.k8s.io/v1beta1
kind: Workload
metadata:
  name: training-job
spec:
  podGroupTemplates:
  - name: workers
    schedulingPolicy:
      gang:
        minCount: 4

Eine PodGroup wird aus diesem Template erzeugt:

apiVersion: scheduling.k8s.io/v1beta1
kind: PodGroup
metadata:
  name: training-job-workers-0
spec:
  workloadRef:
    workloadName: training-job
    templateName: workers
  schedulingPolicy:
    gang:
      minCount: 4

Jeder Pod tritt der Gruppe über ihren Namen bei:

apiVersion: v1
kind: Pod
metadata:
  name: worker-0
spec:
  schedulingGroup:
    podGroupName: training-job-workers-0
  containers:
  - name: trainer
    image: trainer:1.0
    # ...

Mit diesem Setup plant Kubernetes die Worker erst ein, wenn mindestens vier von ihnen gemeinsam laufen können. Finden im Cluster keine vier Platz, startet keiner von ihnen.

8. Kubelet im User Namespace (Rootless-Modus)

Feature-Gruppe: SIG Node | KEP: #2033

In Kubernetes v1.37 hat der Betrieb des Kubelets in einem User Namespace, auch Rootless-Modus genannt, den Beta-Status erreicht.

Vor diesem Feature liefen Node-Komponenten wie das Kubelet als Root auf dem Host. Wurde das Kubelet kompromittiert, konnte ein Angreifer Root-Rechte auf dem gesamten Node erlangen.

Mit v1.37 ist das Feature-Gate KubeletInUserNamespace Beta. Es lässt das Kubelet und die übrigen Node-Komponenten in einem Linux User Namespace laufen. Innerhalb des Namespace erscheinen sie weiterhin als Root, auf dem Host sind sie jedoch einem unprivilegierten Benutzer zugeordnet. Das schafft eine zusätzliche Isolationsschicht, ohne die tägliche Arbeit mit dem Kubelet zu verändern. Dieses Feature ist seit v1.22 in Arbeit – der Sprung auf Beta ist also ein großer Schritt.

Alpha Features in Kubernetes v1.37

9. Eviction Request API

Feature-Gruppe: SIG Node | KEP: #4563

Vor diesem Feature war das Drainen eines Nodes für Wartungsarbeiten eine clientseitige Aktion. Ein Tool wie kubectl drain entfernte Pods nacheinander per Eviction und respektierte dabei PodDisruptionBudgets, aber die Absicht lag im Client, nicht im Cluster. Controller und Anwendungen konnten weder erkennen, dass ein Node gedraint wird, noch einen sicheren Handoff koordinieren oder an der Entscheidung mitwirken. Eine Stateful-App konnte zum denkbar ungünstigsten Zeitpunkt verdrängt werden, weil sie von der anstehenden Wartung nichts erfuhr.

Mit v1.37 ergänzt ein Alpha-Feature die EvictionRequest API, damit Eviction kooperativ ablaufen kann statt als hartes Löschen. Ein Requester erstellt einen EvictionRequest für einen Pod, und Komponenten, die sich über das neue Pod-Feld spec.evictionResponders registriert haben, kümmern sich um einen sauberen Handoff. v1.37 ergänzt außerdem neue Node-Lifecycle-Conditions (MaintenancePlanned, MaintenanceInProgress, GracefulNodeShutdownInProgress, DrainInProgress und Drained), über die Controller nachvollziehen können, wo sich ein Node im Wartungsablauf befindet. Zusammen ermöglicht das Anwendungen und Operatoren, das Drainen zu ihren eigenen Bedingungen abzuwickeln – etwa indem sie einen Leader verschieben oder ihren State wegschreiben, bevor ihr Pod verschwindet.

10. Checkpoint und Restore auf Pod-Ebene

Feature-Gruppe: SIG Node | KEP: #5823

Vor diesem Feature konnte Kubernetes nur von einem einzelnen Container einen Checkpoint erstellen (KEP #2008), vor allem für forensische Analysen. Sie konnten den Zustand eines Containers als Snapshot sichern, aber nicht einen ganzen Pod auf einmal – ein Multi-Container-Pod ließ sich also nicht als eine Einheit erfassen.

Mit v1.37 ergänzt ein Alpha-Feature Checkpoint und Restore auf Pod-Ebene. Es erweitert das Container Runtime Interface (CRI) um die Aufrufe CheckpointPod und RestorePod, sodass das Kubelet und eine kompatible Runtime alle Container eines Pods gemeinsam sichern und anschließend wiederherstellen können. Das ist heute für forensische Arbeit nützlich und legt den Grundstein für künftige Anwendungsfälle wie das Verschieben eines laufenden Pods zwischen Nodes. Das Feature setzt eine Container-Runtime voraus, die die neuen CRI-Aufrufe unterstützt.