Überblick: 22 Alpha-Features, sechs Schwerpunkte
Kubernetes 1.37 erscheint am 26. August 2026. Die Schwerpunkte: Workload-Lifecycle (Checkpoints, Gang Scheduling), der weitere Ausbau von Dynamic Resource Allocation (DRA), Security- und Storage-Verbesserungen – und der eingeleitete Wechsel von iptables zu nftables.
Alle 22 Alpha-Features mit KEP und Feature-Gate
| Feature | KEP | Feature-Gate | Abschnitt |
|---|---|---|---|
| Pod-Level Checkpoint/Restore | 5823 | PodLevelCheckpointRestore | 1 |
| Default Pod Sysctls in Kubelet | 5996 | DefaultPodSysctls | 1 |
| Resize von Memory-backed Volumes | 6030 | InPlacePodVerticalScalingMemoryBackedVolumes | 1 |
| TLS für gRPC-Probes | 4939 | GRPCContainerProbeTLS | 2 |
| h2c-Probes (HTTP/2 cleartext) | 5999 | H2CContainerProbe | 2 |
| bindMountOptions an volumeMounts | 5855 | VolumeBindMountOptions | 2 |
| DRA Optional Node Preparation | 5945 | DRAOptionalNodePreparation | 3 |
| DRA Device Compatibility Groups | 5963 | DRADeviceCompatibilityGroups | 3 |
| DRA Standard-Attribut numaNode | 6072 | – (Listenform: DRAListTypeAttributes) | 3 |
| DRA Derived Attributes | 6080 | DRADerivedAttributes | 3 |
| Preemption für In-Place-Resize | 5836 | SchedulerPreemptionForPodResize | 4 |
| Workload-Aware-Scheduling Controller-APIs | 6089 | WorkloadWithJob | 4 |
| CompositePodGroup API | 6012 | CompositePodGroup | 4 |
| User-Felder für Atomic-Write-Volumes | 5936 | AtomicWriteVolumeUserFields | 5 |
| Topologie für Volume-Snapshots | 5943 | VolumeSnapshotTopology | 5 |
| emptyDir Permission Mode | 5502 | EmptyDirVolumeMode | 5 |
| Volume Health Monitor | 1432 | CSIVolumeHealth | 5 |
| nftables als kube-proxy-Default | 5343 | – | 6 |
| nftables Localhost-NodePort-Proxy | 6032 | KubeProxyNFTablesLocalhostNodePorts | 6 |
| API-Server-Auth gegen Admission-Webhooks | 6060 | APIServerWebhookAuthenticationToken | 6 |
| Recreate-Strategie für StatefulSets | 3541 | StatefulSetRecreateStrategy | 6 |
| Interne API-Typen eliminieren | 6164 | – | 6 |
Pod-Lifecycle: Checkpoints, Sysctl-Defaults, tmpfs-Resize
Drei Node-Features rütteln an einem alten Grundsatz: dass Pods flüchtig sind und jede Änderung einen Neustart kostet.
Pod-Level Checkpoint/Restore · KEP 5823
Bisher ließen sich nur einzelne Container einfrieren (KEP-2008) – wenig hilfreich, weil Container im Pod Netz und Memory teilen. Jetzt lässt sich ein kompletter Pod samt RAM-Zustand, Prozessbaum, offenen File-Deskriptoren und Metadaten in eine Datei sichern und später exakt an diesem Punkt fortsetzen. Technisch orchestriert das kubelet die Runtime (containerd/CRI-O), die dafür das Linux-Werkzeug CRIU aufruft; beim Restore entstehen Prozesse mit den ursprünglichen PIDs. Die CRI-API bekommt dafür die Methoden CheckpointPod und RestorePod.
- Warmstarts klonen – schwergewichtige Java-/ML-Apps einmal hochfahren, Snapshot ziehen, auf andere Nodes replizieren
- Checkpoint statt Neuberechnung – Langläufer nach Fehlern am letzten Stand fortsetzen
- Wartung ohne Verlust – Pods pausieren, verschieben, weiterlaufen lassen
- Forensik – eingefrorenen Zustand in Staging analysieren, ohne das Original zu stören
Default Pod Sysctls · KEP 5996
Kernel-Parameter mussten bisher pro Pod über securityContext.sysctls gesetzt werden – mühsam, wenn ein ganzer Node-Pool dieselben net.*-Werte braucht. Neu: defaultPodSysctls als Key-Value-Map in der KubeletConfiguration. Das kubelet wendet sie beim Anlegen der Pod-Sandbox auf alle Pods des Nodes an; explizite Werte im Pod-Manifest gewinnen weiterhin.
tmpfs-Resize ohne Neustart · KEP 6030
Ein emptyDir mit medium: Memory landet als tmpfs im RAM – dessen sizeLimit war bisher in Stein gemeißelt. Jetzt wird das Feld über die /resize-Subresource mutierbar, der Fortschritt ist in einer neuen VolumeStatus-Struktur nachvollziehbar. Passt zum In-Place-Pod-Resizing: Auch der RAM-„Datenträger" wächst ohne Pod-Neustart mit.
Probes & Mounts: TLS, h2c und noexec
Drei kleine Felder mit großem Alltagsnutzen: Healthchecks sprechen endlich verschlüsseltes gRPC und HTTP/2, und beschreibbare Volumes lassen sich härten.
TLS für gRPC-Probes · KEP 4939
Native gRPC-Probes gibt es seit 1.23 – aber nur im Klartext. gRPC-Server mit TLS lehnten die Probe-Requests ab, weshalb weiterhin Drittwerkzeuge wie grpc_health_probe per exec ins Image mussten. Das neue mode-Feld (Plaintext als Default oder TLS) macht das überflüssig; die Zertifikatsgültigkeit wird dabei nicht geprüft.
livenessProbe:
grpc:
port: 8443
mode: TLSh2c-Probes · KEP 5999
Liveness-, Readiness- und Startup-Probes können HTTP-Endpunkte jetzt per unverschlüsseltem HTTP/2 (h2c) prüfen. Dafür bekommt httpGet ein protocol-Feld: HTTP1 (Default) oder HTTP2 bei weiterhin scheme: HTTP.
readinessProbe:
httpGet:
port: 8080
path: /readyz
protocol: HTTP2bindMountOptions: noexec, nosuid, nodev · KEP 5855
Read-only-Rootfilesystem plus beschreibbares /tmp-Volume ist gängige Härtungspraxis – hat aber ein Loch: Ins beschreibbare Volume lässt sich ein Skript legen, ausführbar machen und starten. Das neue Feld bindMountOptions am volumeMount schließt das mit klassischen Mount-Flags: noexec (nichts ausführen), nosuid (keine Privilegien-Eskalation über suid-Bits), nodev (keine Device-Dateien).
volumeMounts:
- name: tmp
mountPath: /tmp
bindMountOptions: [noexec, nosuid]Unterstützen kubelet oder Runtime die Optionen nicht, wird der Pod auf diesem Node gar nicht erst geplant.
DRA: vier Ausbaustufen für GPUs & Co.
Dynamic Resource Allocation bekommt den größten Block des Releases: weniger Pflicht-Overhead auf den Nodes, hardwarebewusstes Scheduling und ein gemeinsames Vokabular für NUMA-Topologie.
Optional Node Preparation · KEP 5945
Bisher wollte das kubelet vor jedem Container-Start per gRPC den lokalen DRA-Treiber erreichen, um das Device vorzubereiten – auch bei virtuellen oder Cloud-Ressourcen, die auf dem Node gar nichts brauchen. Admins mussten deshalb Dummy-Treiber als DaemonSet ausrollen. Das neue Bool-Feld SkipNodeOperations (in ResourceSliceSpec und DeviceRequestAllocationResult) lässt Treiber signalisieren: Node-seitig ist nichts zu tun. Das spart die No-op-DaemonSets, CPU und RAM – und verhindert Pods, die wegen eines toten lokalen Treibers in Terminating festhängen.
Device Compatibility Groups · KEP 5963
Der Scheduler kannte bei geteilten Geräten bislang nur die Kapazität – nicht, ob sich Nutzungsmodi vertragen. Ergebnis: Ein Pod mit inkompatiblem Modus (etwa MIG neben vGPU auf derselben GPU) landete auf dem Node und drehte dann Schleifen in CrashLoopBackOff oder UnexpectedAdmissionError, ohne je umgeplant zu werden. Neu liefert der Treiber im ResourceSlice das Feld compatibilityGroups (Textlabels); beim Scheduling wird der Schnitt mit den Gruppen bereits laufender Pods gebildet. Kein Überschneiden, kein Placement – der Scheduler sucht direkt einen passenden Node.
Standard-Attribut numaNode · KEP 6072
Fünf Treiber, fünf verschiedene Attributnamen für dieselbe NUMA-Information – so ließ sich keine generische Regel bauen, die GPU, NIC und CPU auf denselben NUMA-Node zwingt. Jetzt wird resource.kubernetes.io/numaNode standardisiert: als einzelner Integer oder (hinter DRAListTypeAttributes) als Integer-Liste auf Basis der ACPI-SLIT-Latenzen. Der Scheduler bildet die Schnittmenge – CPU auf Node 4, NIC meldet [6, 4, 5, 7], also läuft der Workload auf 4.
Derived Attributes · KEP 6080
matchAttributes verlangt exakt gleiche Attributnamen und -werte – bei Vendor-Wildwuchs chancenlos, ohne Treibercode anzufassen. Mit derivedAttributes lassen sich im ResourceClaim per CEL-Ausdruck aus verschiedenen Treiber-Metadaten virtuelle, gemeinsame Schlüssel ableiten (z. B. eine NUMA-ID aus gpu.nvidia.com und dra.net), die dann ganz normal per matchAttribute verknüpft werden.
Scheduling: Preemption, Gangs und Gruppen-Hierarchien
Der Scheduler lernt zwei Dinge: Platz schaffen für wachsende Pods – und ganze Workload-Gruppen als Einheit denken, statt Pod für Pod.
Preemption für In-Place-Resize · KEP 5836
In-Place-Resize ändert CPU/RAM eines Pods ohne Neustart – aber wenn der Node voll ist, hängt der Antrag in Deferred und wartet, bis zufällig etwas frei wird. Dabei kann der Pod OOM-killed werden, obwohl niedriger priorisierte Nachbarn auf demselben Node verdrängbar wären. Genau das darf der Scheduler jetzt: Pods mit niedrigerer Priorität auf diesem Node preempten, um Platz für den Resize zu schaffen. Geprüft wird nur der Node des Ziel-Pods; Affinity-, Anti-Affinity- und Topology-Spread-Regeln der Erstplatzierung bleiben außen vor, PriorityClass und preemptionPolicy gelten wie beim normalen Scheduling. Verdrängte Pods gehen als Unschedulable zurück in die Queue – was den Cluster Autoscaler triggern kann. Neu am Node-Objekt: podPreemptionPolicy, um Resize-getriebene Preemption pro Node abzuschalten.
WAS Controller-APIs · KEP 6089
Workload-Aware Scheduling (Gang Scheduling, Topologie, Workload-Preemption) existiert bislang als Scheduler-nahe Zwischen-APIs (Workload, PodGroup) – höhere Controller wie Job, JobSet oder RayJob konnten die Wünsche ihrer Nutzer nicht sauber im YAML entgegennehmen. KEP-6089 liefert wiederverwendbare API-Bausteine in scheduling.k8s.io, eine gemeinsame Go-Library (workloadbuilder) und erweitert die Job-API um einen scheduling-Block: Gang-Verhalten, Topologie-Constraints (z. B. Zone) und Disruption-Modus direkt im Job-Manifest.
CompositePodGroup API · KEP 6012
AI-/ML-Workloads bestehen oft aus Gruppen von Gruppen – etwa N Prefill- und M Decode-Gruppen – und brauchen mehrstufiges Gang Scheduling: Die Elterngruppe darf erst starten, wenn genug Kindgruppen stehen. Die flachen Workload-/PodGroup-APIs konnten das nicht. CompositePodGroup bildet einen Baum aus Root-Gruppen und PodGroup-Blättern; Gang-, Topologie- und Preemption-Regeln gelten dann pro Ebene. Der DisruptionMode legt fest, ob Kindgruppen einzeln verdrängt werden dürfen oder nur alle zusammen – beim ML-Training macht ein verlorener Worker den Rest oft wertlos.
Storage: Ownership, Topologie, Rechte, Gesundheit
Vier Baustellen, ein Muster: Dinge, die bisher nur mit Workarounds (root-initContainer, Blindflug bei Snapshots) gingen, bekommen native Felder.
User-Felder für Atomic-Write-Volumes · KEP 5936
Dateien aus ConfigMap-, Secret-, DownwardAPI- und Projected-Volumes gehören bisher root (UID 0) – Anwendungen wie MongoDB verweigern solche Dateien aber, wenn sie selbst unprivilegiert laufen. Der alte Trick (root-initContainer mit chown) scheitert an strengen Pod-Security-Policies. Neu: defaultUser setzt die UID für alle Dateien des Volumes, user übersteuert sie pro Datei. Nur UID – GIDs laufen weiter über fsGroup/supplementalGroups; Windows und PVs sind außen vor.
Topologie für Volume-Snapshots · KEP 5943
Volumes kennen Zonen – Snapshots bisher nicht. Ergebnis: Restore-Versuche in Zonen, in denen der Snapshot gar nicht verfügbar ist. Jetzt schreibt der CSI-Snapshotter die vom Treiber gemeldete Topologie als nodeAffinity in den VolumeSnapshotContent; Wunsch-Standorte lassen sich per VolumeSnapshotClass.allowedTopologies vorgeben. Beim Restore filtert im WaitForFirstConsumer-Modus ein Scheduler-Plugin unpassende Nodes, im Immediate-Modus provisioniert der external-provisioner nur im Schnitt aus Snapshot-Standort und StorageClass.allowedTopologies – oder bricht mit explizitem Topologie-Fehler ab.
emptyDir Permission Mode · KEP 5502
emptyDir-Volumes entstehen bislang stur mit 0777 – teilen sich mehrere Container das Volume, kann jeder jedem die Dateien löschen. Das neue optionale mode-Feld erlaubt Unix-Rechte von 0000 bis 01777:
volumes:
- name: app-data
emptyDir:
mode: 0750fsGroup im securityContext kann Gruppe und Rechte nachträglich verändern. Das effektive Ergebnis kann also vom deklarierten mode abweichen, ohne dass irgendwo ein Fehler auftaucht.Volume Health Monitor · KEP 1432
Ein Klassiker seit 2019: Die Cloud-Disk ist längst gelöscht, das Filesystem korrupt oder der Multipath weg – aber die PVC steht weiter auf Bound, und man merkt es erst an hängenden I/O-Operationen. Die CSI-Spezifikation bekommt vier neue RPC-Calls, über die Treiber Volume- und Backend-Gesundheit melden: auf Controller-Ebene über den Sidecar csi-external-health-monitor-controller (Liste kranker Volumes, Status eines Volumes), auf Node-Ebene über das kubelet (Volume- und Backend-Sicht des Nodes). Standardisierte Zustände: Inaccessible, DataLoss, Degraded, StorageUnreachable, StorageDegraded – wie Kubernetes darauf reagiert, definiert das KEP bewusst nicht.
Netz, Auth, Apps & API-Machinery
Der leise Umbau im Unterbau: kube-proxy wechselt das Rückgrat, der API-Server weist sich bei Webhooks aus, StatefulSets bekommen den Holzhammer – und intern verschwindet ein historischer Zwischenschritt.
nftables wird kube-proxy-Default · KEP 5343 + 6032
Der Wechsel läuft gestuft: Ab 1.37 warnt kube-proxy per Log und Event, wenn kein --proxy-mode (bzw. mode-Feld) explizit gesetzt ist, und fällt noch auf iptables zurück. Einige Releases später kippt der Default auf nftables; iptables bleibt wählbar.
route_localnet-Kernel-Flag – nftables hat kein Äquivalent. Workloads, die sich auf localhost:<NodePort> verlassen, verlieren beim Backend-Wechsel kommentarlos die Verbindung. Abhilfe ist der neue optionale Userspace-TCP-Proxy (KEP-6032): aktiv nur, wenn Loopback explizit in --nodeport-addresses steht (z. B. primary,localhost – all genügt nicht), und nur für TCP; UDP und SCTP über localhost bleiben tot.API-Server-Auth gegen Admission-Webhooks · KEP 6060
Bisher authentifiziert sich der kube-apiserver gegenüber Admission-Webhooks standardmäßig gar nicht – wer das Service-Netz erreicht, kann AdmissionReviews im Namen des API-Servers fälschen und Policies umgehen (siehe CVE-2025-1974); mTLS/kubeconfig-Setups sind so umständlich, dass sie kaum jemand nutzt. Neu: kurzlebige JWTs (max. 10 Minuten, gecacht) über die TokenRequest API mit AttestationClaims. Der Claim allowedAPIGroup begrenzt, für welche API-Gruppen ein Token AdmissionReviews senden darf – der Core-API-Server bekommt *, aggregierte API-Server nur ihre eigenen Gruppen. Webhooks validieren lokal (Signatur, Audience, API-Gruppe), ohne Rückfrage beim API-Server; wer den Header noch nicht versteht, ignoriert ihn einfach. Gilt nur für Admission-Webhooks, nicht für Authn/Authz/Audit/Conversion.
Recreate-Strategie für StatefulSets · KEP 3541
RollingUpdate ist bei StatefulSets bewusst vorsichtig – bleibt aber ein Pod im Update hängen (ImagePullBackOff, Pending), steht der ganze Rollout, und selbst nach dem Fix räumt der Controller den hängenden Pod nicht selbst weg. Die neue Recreate-Strategie löscht alle alten Pods auf einmal (PVCs und damit die Daten bleiben), wartet auf vollständigen Shutdown und startet dann die neue Version gemäß podManagementPolicy – mit bewusster Downtime, also nicht für jedes Szenario.
spec.updateStrategy.type auf Recreate zu stellen startet keinen Rollout – es passiert schlicht nichts, bis .spec.template geändert oder kubectl rollout restart ausgeführt wird. Wer nach dem Umstellen auf das Neuausrollen wartet, wartet vergebens.Interne API-Typen eliminieren · KEP 6164
Historisch konvertiert der API-Server jede eingehende Ressource in eine interne __internal-Version (Validierung einmal schreiben statt je Version) und zurück. Bei überwiegend stabilen v1-APIs ist dieser Umweg heute vor allem teuer – besonders bei großen List-Abfragen. Phase 1 macht die internen Strukturen speicheridentisch zu v1, sodass die Konvertierung ohne Feld-für-Feld-Kopie auskommt: Bei einer Liste mit 1.000 Pods sinken die Memory-Allokationen von 21.000 auf 5, die Verarbeitung wird knapp sechsmal schneller bei einem Drittel des RAM-Verbrauchs. Phase 2 (ab v1.38+) macht die internen Typen zu Go-Aliassen der v1-Strukturen.
__internal) und wurde dort umgepackt, selbst wenn Absender und Empfänger längst dieselbe Sprache (v1) sprechen. Jetzt fährt der Lkw direkt.Jenseits von Alpha: die Beta- und Stable-Sprünge
Neben den 22 Neulingen reifen alte Bekannte – zwei davon nach über fünf Jahren Anlauf seit Kubernetes 1.22.
Die Highlights des Releases außerhalb der Alphas
| Feature | KEP | Neuer Stand | Kurz gesagt |
|---|---|---|---|
| Rootless-Modus (Kubelet-in-UserNS) | 2033 | Beta | alle K8s-Komponenten (kubelet, kube-*, CRI, OCI, CNI) als Non-root auf dem Host |
| Memory QoS mit cgroups v2 | 2570 | Beta, default an | Memory-Steuerung über cgroup-v2-Mechanismen |
| KYAML | 5295 | Stable | YAML-Dialekt mit strikter Formatierung gegen Klassiker wie den „Norway-Bug" |
| Pod Certificates + Cluster Trust Bundles | 4317 / 3257 | Stable | X.509-Zertifikate für Pods (mTLS gegen den API-Server) plus Verteilung der Trust-Anchors über certificates.k8s.io |
| Node-declared Features | 5328 | Stable | Nodes deklarieren selbst, welche K8s-Features sie unterstützen |