Kubernetes 1.37 Release: Neue Features, Beta- und Stable-Änderungen

Kubernetes 1.37: Stabile (GA) Features

1. Metrics API wird stabil

Feature Group: SIG Instrumentation | KEP: KEP-5207

Die metrics.k8s.io-API war jahrelang in der Beta. Sie ist die API hinter kubectl top und den CPU- und Speichermetriken des Horizontal Pod Autoscalers. In v1.37 erreicht sie endlich den Stable-Status.

Funktional ändert sich nichts. Sowohl v1 als auch v1beta1 funktionieren weiterhin, Sie müssen also derzeit nichts anpassen. Wenn Sie jedoch Tools entwickeln, die diese API nutzen, können Sie jetzt bedenkenlos auf v1 setzen – sie ist stabil und ändert sich nicht mehr unerwartet.

2. Ressourcen auf Pod-Ebene

Bisher mussten Sie Resource Requests und Limits für jeden Container in einem Pod einzeln festlegen, selbst wenn die Container zusammenarbeiten sollten.

Pod-level Resources ermöglichen es, CPU-, Speicher- und Hugepages-Requests/-Limits auf Pod-Ebene statt auf (oder zusätzlich zur) Container-Ebene zu definieren.

spec:
  resources:
    requests:
      cpu: "1"
      memory: "512Mi"
    limits:
      cpu: "2"
      memory: "1Gi"
  containers:
  - name: app
    image: my-app
  - name: sidecar
    image: my-sidecar

Alle Container im Pod können sich dann denselben Ressourcenpool teilen, statt jeweils eine eigene feste Zuweisung zu haben. Das reduziert ungenutzte Ressourcen und eignet sich besser für Multi-Container-Workloads mit stark schwankender Ressourcennutzung.

3. DRA: Device Taints und Tolerations

Feature Group: SIG Scheduling | KEP: KEP-5055

Damit kommt das Taint-Modell der Nodes zur Dynamic Resource Allocation (DRA). DRA-Treiber oder eine selbst erstellte DeviceTaintRule können ein bestimmtes Gerät tainten (etwa eine GPU, die überhitzt oder für Wartungsarbeiten geleert wird).

Ein NoSchedule-Taint verhindert, dass neue Pods das Gerät nutzen, während ein NoExecute-Taint Pods entfernt, die es bereits verwenden. Wenn ein Workload das Gerät dennoch benötigt, kann er in seinem ResourceClaim eine passende Toleration hinzufügen.

So lässt sich eine einzelne GPU oder NIC isolieren, statt den gesamten Node zu sperren.

4. Konfigurierbare Toleranz für den HPA

Feature Group: SIG Autoscaling | KEP: KEP-4951

Der Horizontal Pod Autoscaler (HPA) hat bisher clusterweit eine feste Toleranz von 10 % verwendet, um Skalierungen aufgrund kleiner Metrik-Schwankungen zu vermeiden. Aber dieselben 10 % passen nicht für jeden Workload. Eine Änderung von 10 % bei einem Workload mit 500 Pods ist etwas ganz anderes als bei einem mit 5 Pods.

Da dieses Feature jetzt stabil ist, können Sie für jeden HPA eine eigene Toleranz festlegen – mit separaten Werten für Scale-up und Scale-down unter spec.behavior.scaleUp und spec.behavior.scaleDown. So skaliert jeder Workload passender, ohne den clusterweiten Standardwert zu ändern.

5. Pod Certificates

Feature Group: SIG Auth | KEP: KEP-4317

Damit erhalten Pods eine native Möglichkeit, kurzlebige X.509-Zertifikate zu beziehen, ohne den Umweg über Bearer Tokens. Eine neue PodCertificateRequest-API übernimmt die Ausstellung, und ein PodCertificate Projected Volume ermöglicht es dem kubelet, Schlüssel und Zertifikat direkt an den Pod zu übergeben – inklusive automatischer Rotation.

Das macht mTLS-Setups (auch mit Drittanbieter-Tools wie HashiCorp Vault) nativ deutlich einfacher, ohne den zusätzlichen Sidecar- oder Webhook-Unterbau, den viele Service Meshes heute nutzen.

6. KYAML-Ausgabe für kubectl

Feature Group: SIG CLI | KEP: KEP-5295

KYAML ist ein strengeres, Kubernetes-spezifisches Subset von YAML: geschweifte Klammern für Maps, eckige Klammern für Listen, doppelte Anführungszeichen für Strings. Kommentare und nachgestellte Kommas sind weiterhin erlaubt, aber die klassischen YAML-Fallstricke entfallen – etwa das stillschweigende Parsen als boolesches false (das "Norway problem").

KYAML ist jetzt eine stabile Ausgabeoption für kubectl, sodass Sie Manifeste in diesem Format erzeugen können, ohne dass versehentliche Typumwandlungen Ihre Konfiguration zerschießen.

7. Schnellere rekursive SELinux-Label-Änderungen (SELinuxMount)

Feature Group: SIG Storage | KEP: KEP-1710

Auf Nodes mit aktiviertem SELinux hat Kubernetes bisher jede Datei eines Volumes einzeln neu gelabelt, bevor ein Pod starten konnte. Bei einem Volume mit Millionen von Dateien konnte das allein Minuten dauern.

SELinuxMount erreicht GA-Status und ist in v1.37 standardmäßig aktiviert. Statt Datei für Datei neu zu labeln, werden Volumes mit -o context=<label> gemountet; das gesamte Volume erhält das richtige Label in einer einzigen Mount-Operation. Das greift nur, wenn der CSI-Treiber des Volumes dies über CSIDriver.spec.seLinuxMount: true aktiviert.

Wichtig zu wissen: Ein einzelner Mount kann nur einen SELinux-Kontext tragen. Wenn sich derzeit Pods mit unterschiedlichen SELinux-Labels dasselbe Volume auf demselben Node teilen (was mit dem alten rekursiven Relabeling problemlos funktionierte), starten diese Pods jetzt möglicherweise nicht mehr. Wenn Sie das alte Verhalten für einen bestimmten Workload benötigen, setzen Sie seLinuxChangePolicy: Recursive in der Pod-Spezifikation. Cluster ohne aktiviertes SELinux sind davon überhaupt nicht betroffen.

Kubernetes 1.37: Beta-Features

8. Kubelet im User Namespace (Rootless-Modus)

Feature Group: SIG Node | KEP: KEP-2033

Node-Komponenten wie das kubelet laufen normalerweise als Root auf dem Host. Wird das kubelet kompromittiert, könnte ein Angreifer Root-Zugriff auf den Node erlangen.

Kubelet in UserNS führt das kubelet stattdessen in einem Linux User Namespace aus. Innerhalb des Namespace erscheint es weiterhin als Root, auf dem eigentlichen Host ist es jedoch einem unprivilegierten Benutzer zugeordnet. Dieses Feature wechselt in Kubernetes v1.37 in die Beta und fügt eine zusätzliche Isolationsschicht hinzu, ohne die tägliche Nutzung des kubelet zu verändern.

9. HPA: Skalierung auf/von null für Object- und External-Metriken

Feature Group: SIG Autoscaling | KEP: KEP-2021

Der Horizontal Pod Autoscaler (HPA) kann Workloads schon länger über Object- oder External-Metriken auf null Replikas skalieren. Es gab aber keine einfache Möglichkeit zu erkennen, ob der HPA einen Workload auf null skaliert hat oder ob jemand ihn auf anderem Weg auf null gesetzt hat.

Kubernetes v1.37 fügt dem HPA-Objekt eine ScaledToZero-Statusbedingung hinzu, die diesen Unterschied klar erkennbar macht. Das ist besonders nützlich für event-getriebene Workloads – etwa solche mit Queue-Tiefe oder KEDA-artigen Triggern –, die im Leerlauf auf null herunterskalieren und bei neuer Arbeit wieder hochfahren.

10. CBOR-Serializer

Feature Group: SIG API Machinery | KEP: KEP-4222

Eingebaute Kubernetes-Ressourcen nutzen Protobuf, um API-Aufrufe schnell zu halten, aber CRDs können Protobuf nicht ohne Weiteres verwenden, da es Codegenerierung zur Kompilierzeit erfordert. CBOR ist ein Binärformat ohne diese Anforderung, und erste Benchmarks zeigen im Vergleich zu JSON bis zu 8-mal schnelleres Encoding und 2-mal schnelleres Decoding für Custom Resources. Clients handeln das Format automatisch aus und fallen bei älteren API-Servern auf JSON zurück, sodass der Rollout sicher erfolgt.

Kubernetes 1.37: Alpha-Features

Diese Features sind Alpha: nicht produktionsreif, aber einen Test im Staging-Cluster wert.

11. Volume Health Monitor

Feature Group: SIG Storage | KEP: KEP-1432

Wenn ein CSI-Volume derzeit ein Problem auf Storage-Ebene hat, erfahren Sie das meist nur durch einen fehlgeschlagenen Mount oder einen I/O-Hänger; es gibt kein strukturiertes Signal, auf das man reagieren könnte. Dieses Feature führt vier neue CSI-RPCs ein, mit denen Treiber den Zustand von Volumes so melden können, dass Controller darauf reagieren können. Auf Controller-Seite listet ControllerListVolumeHealth fehlerhafte Volumes auf und ControllerGetVolumeHealth prüft ein bestimmtes Volume; ein controllerseitiger Health Monitor fragt diese Endpunkte ab und schreibt das Ergebnis in PersistentVolumeClaim.status.healthStatus. Auf Node-Seite ruft das kubelet NodeGetVolumeHealth für einzelne Volumes auf (festgehalten in Pod.status.volumeHealth) und NodeGetStorageHealth für den Zustand der Treiber auf diesem Node. Damit erhalten Remediation-Controller maschinenlesbare Informationen, statt Hersteller-Dashboards manuell abgleichen zu müssen.

12. Ulimits pro Container

Feature Group: SIG Node | KEP: KEP-5758

Manche Anwendungen, etwa Datenbanken und hochparallele Anwendungen, benötigen höhere POSIX-Limits – etwa für die maximale Anzahl offener Dateien oder Prozesse –, als die Container-Runtime standardmäßig bereitstellt. Bisher waren die üblichen Optionen eigene Entrypoint-Skripte oder Änderungen an der Host-Konfiguration.

Kubernetes v1.37 fügt Container.SecurityContext ein ulimits-Feld hinzu. Das kubelet gibt diese Limits an die Container-Runtime weiter. Dieses Feature funktioniert derzeit nur mit dem Privileged-Profil der Pod Security Standards, und Kubernetes prüft vor dem Scheduling die Node-Unterstützung, damit der Pod nicht auf einem Node landet, der die geforderten Limits nicht anwenden kann.

13. DRA: Derived Attributes

Feature Group: SIG Scheduling | KEP: KEP-6080

DRA kann Geräte bereits über gemeinsame Attribute matchen – aber nur, wenn verschiedene Hardware-Hersteller denselben Attributnamen verwenden, was sie in der Regel nicht tun. Angenommen, Sie möchten eine GPU und eine schnelle NIC auf demselben NUMA-Node: Der Scheduler braucht übereinstimmende Attributnamen und -werte, aber jeder Hersteller beschreibt die Topologie auf seine eigene Weise.

Derived Attributes ermöglichen es, in der Device-Anfrage einen CEL-Ausdruck zu schreiben, der aus den Daten, die der Treiber ohnehin bereitstellt, ein virtuelles Attribut ableitet. So erhalten Sie einen gemeinsamen Schlüssel, etwa eine NUMA-Node-ID, auf die der Scheduler matchen kann. Damit lassen sich GPUs und NICs auf demselben NUMA-Node kombinieren, ohne darauf zu warten, dass sich alle Hersteller auf ein einheitliches Namensschema einigen.

Das Feature ist Alpha, und die API nimmt noch Gestalt an – testen Sie es also in einem Staging-Cluster und prüfen Sie vor dem Einsatz die genauen Felder im KEP.