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

Kubernetes 1.37: Stable-Features (GA)

1. Die Metrics API erreicht GA

Feature Group: SIG Instrumentation | KEP: KEP-5207

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

Funktional ändert sich dabei nichts. Sowohl v1 als auch v1beta1 funktionieren weiterhin, Sie müssen also aktuell nichts anpassen. Wenn Sie aber Tools bauen, die diese API nutzen, können Sie jetzt bedenkenlos auf v1 setzen – die Version 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.

Mit Ressourcen auf Pod-Ebene lassen sich CPU-, Speicher- und Hugepages-Requests/-Limits auf Pod-Ebene statt auf (oder zusätzlich zur) Container-Ebene 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 teilen sich dann denselben Ressourcenpool, statt jeweils eine eigene feste Zuweisung zu erhalten. 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 geschriebene DeviceTaintRule können ein bestimmtes Gerät tainten (etwa eine GPU, die überhitzt oder gerade für Wartungsarbeiten geräumt 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 trotzdem nutzen muss, kann er eine passende Toleration in seinem ResourceClaim hinterlegen.

So lässt sich eine einzelne GPU oder NIC isolieren, ohne den gesamten Node sperren zu müssen.

4. HPA: Konfigurierbare Toleranz

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änderungen zu vermeiden. Doch dieselben 10 % ergeben nicht für jeden Workload Sinn. Eine 10-Prozent-Änderung bei einem Workload mit 500 Pods ist etwas ganz anderes als bei einem mit 5 Pods.

Da das 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 kann jeder Workload passender skalieren, ohne dass der clusterweite Standardwert geändert werden muss.

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 über ein PodCertificate Projected Volume übergibt das kubelet Schlüssel und Zertifikat direkt an den Pod, inklusive automatischer Rotation.

Das macht mTLS-Setups (auch mit Drittanbieter-Tools wie HashiCorp Vault) nativ deutlich einfacher – ohne die zusätzlichen Sidecars oder Webhooks, auf die viele Service Meshes heute noch angewiesen sind.

6. KYAML-Ausgabe für kubectl

Feature Group: SIG CLI | KEP: KEP-5295

KYAML ist eine striktere, Kubernetes-spezifische Teilmenge von YAML: geschweifte Klammern für Maps, eckige Klammern für Listen, doppelte Anführungszeichen für Strings. Kommentare und nachgestellte Kommas bleiben erlaubt, aber die klassischen YAML-Fallstricke entfallen – etwa das stille Parsen als boolesches false (das "Norwegen-Problem").

KYAML ist jetzt eine stabile Ausgabeoption für kubectl. Sie können Manifeste also in diesem Format erzeugen, ohne dass versehentliche Typumwandlungen Ihre Konfiguration beschädigen.

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

Feature Group: SIG Storage | KEP: KEP-1710

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

SELinuxMount erreicht GA 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 einem einzigen Mount-Vorgang. 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 bei Ihnen aktuell 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 scheint es weiterhin als Root zu laufen, 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 dass sich am täglichen Umgang mit dem kubelet etwas ändert.

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 schon länger mithilfe von Object- oder External-Metriken auf null Replicas skalieren. Bislang war jedoch schwer 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 Status-Condition ScaledToZero hinzu und macht diesen Unterschied sichtbar. Das ist besonders nützlich für ereignisgesteuerte Workloads – etwa solche mit Queue-Depth- oder KEDA-artigen Triggern –, die im Leerlauf auf null herunterskalieren und bei neuer Arbeit wieder hochfahren.

10. CBOR-Serialisierer

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

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

Kubernetes 1.37: Alpha-Features

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

11. Volume Health Monitor

Feature Group: SIG Storage | KEP: KEP-1432

Hat ein CSI-Volume aktuell ein Problem auf Storage-Ebene, erfahren Sie das meist erst durch einen fehlgeschlagenen Mount oder einen I/O-Hänger; ein strukturiertes Signal, auf das sich reagieren ließe, gibt es nicht. 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 regelmäßig 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. Remediation-Controller erhalten damit maschinenlesbare Informationen, auf die sie reagieren können, statt Hersteller-Dashboards manuell abgleichen zu müssen.

12. ulimits pro Container

Feature Group: SIG Node | KEP: KEP-5758

Manche Anwendungen – etwa Datenbanken oder Anwendungen mit hoher Parallelität – benötigen höhere POSIX-Limits, z. B. für die maximale Anzahl offener Dateien oder Prozesse, als die Container-Runtime standardmäßig bereitstellt. Bislang blieben dafür meist nur 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. Das Feature funktioniert derzeit nur mit dem Privileged-Profil der Pod Security Standards, und Kubernetes prüft vor dem Scheduling des Pods, ob der Node das unterstützt – der Pod läuft also nicht auf einem Node, der die geforderten Limits nicht anwenden kann.

13. DRA: Derived Attributes

Feature Group: SIG Scheduling | KEP: KEP-6080

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

Mit Derived Attributes können Sie in Ihrem Device Request einen CEL-Ausdruck schreiben, der aus den vom Treiber ohnehin bereitgestellten Daten ein virtuelles Attribut erzeugt. So erhalten Sie einen gemeinsamen Schlüssel – etwa eine NUMA-Node-ID –, auf den der Scheduler matchen kann. GPUs und NICs lassen sich damit auf demselben NUMA-Node kombinieren, ohne darauf zu warten, dass sich alle Hersteller auf ein Namensschema einigen.

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