Kubernetes 1.36 (Haru): Was sich in der Produktion wirklich ändert

Kubernetes 1.36 (Haru) ist am 22. April 2026 als GA erschienen. Das Leitmotiv des Releases lautet „Komplexität in die Kernplattform schieben": weniger externer Glue (Admission-Webhooks, Metrics-Adapter, eigene Log-Shipper), mehr eingebaute Endpunkte und CEL direkt im API-Server. Für ein Plattform-Team heißt das, dass Teile des gewohnten Service-Zoos endgültig in Rente gehen können — aber nicht überall, wo Blogposts „GA" rufen. Es lohnt sich, die offizielle Feature-Gates-Tabelle dagegenzuhalten: rund die Hälfte der 1.36-Übersichten weicht inzwischen von der Realität ab.

Mutating Webhooks fangen an zu sterben

MutatingAdmissionPolicy ist GA — die Mutation lebt jetzt als CEL-Ausdruck im kube-apiserver. Kein externer HTTP-Webhook, keine TLS-Rotation, keine separaten Pods, keine up{job="...-webhook"}-Dashboards, keine Timeouts. Eine ganze Klasse von Incidents fällt mit einem Release weg: abgelaufenes Zertifikat, unerreichbarer Gatekeeper, Latenz-Spike auf Admission, der jedes CREATE/UPDATE im Cluster blockiert.

Das heißt nicht, dass Kyverno und Gatekeeper morgen verschwinden. Komplexe Policies mit Cross-Object-Lookups, Ressourcengenerierung und Image-Verifikation gehören weiter zu externen Engines. Aber Standard-Mutationen wie „pack HTTP_PROXY in jeden Pod dieses Namespace" leben jetzt nativ im API-Server und lassen sich auf Staging testen, ohne einen Webhook anzurufen.

Ingress NGINX wurde ausser Betrieb genommen

SIG Network und das Security Response Committee haben am 24. März 2026 ingress-nginx als retired erklärt: keine Releases, keine Bugfixes, keine Security-Patches. Bestehende Installationen bedienen weiter Traffic — das ist kein Kill-Switch. Aber annotation-lastige Konfigurationen sind jetzt technische Schuld mit tickender Uhr. Zielsysteme: Envoy Gateway, Cilium Gateway, ALB/Lattice in der Cloud, mit Gateway API als Abstraktionsschicht. Der Migrations-Audit beginnt mit der Inventur: wie viele Annotation-Features sind tatsächlich im Einsatz, und wie viele davon haben ein 1:1-Äquivalent in Gateway API? Häufig sind 80 % der Annotations rewrite-target und proxy-buffer-size — die migrieren schnell.

HPA Scale-to-Zero ist Alpha, nicht GA

Hier sitzt der lauteste Lärm. Das Feature-Gate HPAScaleToZero ist seit K8s 1.16 in Alpha und bleibt es auch in 1.36 — Default false. Mehrere Übersichten behaupten das Gegenteil; das ist Fehlinformation. Verifizieren über die Feature-Gates-Dokumentation, nicht über Medium.

Was in 1.36 wirklich funktioniert, wenn man --feature-gates=HPAScaleToZero=true am kube-apiserver setzt: HPA kann nativ minReplicas: 0 für Object- und External-Metriken (etwa sqs_queue_length) erreichen, aber nicht für CPU/Memory. Ein Metrics-Adapter wird weiterhin gebraucht. In der Praxis bedeutet das: KEDA bleibt relevant, weil sein Scaler-Katalog alle Quellen abdeckt, die in der Kubernetes-nativen Metrik-Kette fehlen. Das Combo „Karpenter + HPA Scale-to-Zero + KEDA-Quelle" ist das serverlose Kubernetes, auf das man seit 2019 wartet.

User Namespaces GA — der grösste Security-Win seit Jahren

Der Container-Root wird auf einen unprivilegierten User auf dem Host gemappt. Ein Container-Breakout im Stil der runc-CVE landet in einer Sandbox mit null Privilegien statt auf Host-Root. Für Multi-Tenant-Cluster ist das die materiellste Änderung des Bedrohungsmodells seit mehreren Jahren. Eingeschaltet wird das mit userNamespaces: true in der Pod-Spec plus Kernel ≥ 6.5 auf den Nodes. EKS/GKE-Standard-AMIs liefern das bereits; auf Bare Metal und Talos vor der Annahme nachprüfen.

GPU-Scheduling: Beta kommt von selbst, Alpha nicht

Der zweite Punkt, an dem Release-Übersichten von der Feature-Gate-Tabelle abweichen, ist das Scheduling von GPU-Workloads. Partitionable Devices sind in 1.36 auf Beta gegangen, und das Gate DRAPartitionableDevices ist in kube-apiserver und kube-scheduler per Default aktiv; in 1.33–1.35 war das Feature Alpha und abgeschaltet. Der Unterschied ist praktisch: Der Mechanismus kommt mit dem Upgrade mit, eine eigene Entscheidung des Betreibers braucht es dafür nicht.

Die Mechanik dahinter. Ein Treiber deklariert in einem ResourceSlice einen Satz sharedCounters — einen Pool der physischen Ressource, sagen wir 8Gi Speicher der Karte —, und logische Devices tragen über consumesCounters ein, wie viel sie aus diesem Pool nehmen. Zwei Devices zu je 6Gi aus gemeinsamen 8Gi werden nie gleichzeitig vergeben: Die Überschneidung rechnet der Scheduler selbst aus, der konsumierende ResourceClaim muss davon nichts wissen. Genau diese Buchhaltung hat man früher mit handgeschnittenen MIG-Profilen oder einem eigenen Device-Plugin nachgebaut, und sie holt eine teure Karte aus dem Modus „ganz an einen Pod vergeben“ heraus — dieselbe Arithmetik wie bei CPU- und Memory-Requests.

Gang Scheduling dagegen, das in Übersichten zu 1.36 als Neuheit des Releases verkauft wird, ist früher gelandet. Die API Workload und PodGroup (scheduling.k8s.io/v1alpha2) steht seit 1.35 in Alpha, die Gates GenericWorkload und GangScheduling sind per Default aus. In 1.36 sind zwei eigene Alpha-Gates drumherum dazugekommen: WorkloadWithJob — der Job-Controller legt Workload und PodGroup selbst an, die Objekte muss niemand mehr von Hand bauen; und WorkloadAwarePreemption — die Preemption behandelt die ganze Gruppe als eine Einheit und sucht Opfer im gesamten Cluster statt auf einer Node. Das Release hat nicht das All-or-Nothing-Scheduling gebracht, sondern seine Brauchbarkeit — mit drei aktivierten Gates und explizit eingeschalteter Alpha-API-Gruppe.

Ein Detail, das dafür spricht, die Feature-Gate-Tabelle im Lesezeichen zu haben und nicht die Konzeptseiten: Am 24. August 2026 liegt der Unterabschnitt zu Partitionable Devices in der Dokumentation immer noch unter der Überschrift „DRA alpha features“, während der Text in diesem Unterabschnitt Beta sagt. Die Gliederung hinkt dem Status hinterher, die Gate-Tabelle nicht.

Stille Reife im Tagesbetrieb

Ein paar Dinge, die keine Schlagzeilen machen, aber den Day-2-Betrieb verändern:

• In-Place Vertical Pod Scaling funktioniert jetzt sogar mit der Static-CPU-Manager-Policy: VPA verändert requests/limits ohne Restart und ohne Verlust des CPU-Pinning. Für High-Perf-Workloads wird VPA damit wirklich nicht-disruptiv.
• Ephemeral Service Account Tokens für Image-Pulls (KEP-2535, GA): kubelet handelt mit der Registry einen kurzlebigen OIDC-Token aus, gescoped auf den Pod-Lifecycle, statt eines dauerhaften imagePullSecret. Ein Zero-Trust-Artefakt weniger im Secret Store.
• PSI-Metriken GA: Pressure Stall Information aus dem Linux-Kernel landet direkt in den kubelet-Metriken. Statt „memory at 95 %" (was File-Cache sein kann) sieht man endlich, wie lange Tasks tatsächlich auf eine Ressource warten. Weniger false-positive NodeNotReady, präziseres VPA-Tuning.
• Node Log Query GA: kubectl get --raw "/api/v1/nodes/<node>/proxy/logs/?query=kubelet" — Systemlogs ohne SSH auf der Node. Erfordert das NodeLogQuery-Gate und enableSystemLogQuery in der kubelet-Konfiguration.
• Fine-Grained Kubelet Authz GA: statt der groben system:kubelet-api-admin gibt es jetzt granulare Verbs pro Subresource (nodes/proxy/logs — get, nodes/proxy/exec — deny). Audit-Accounts bekommen Read-Only, ohne den vollen Admin-Grant auf kubelet zu erben.

Was beim Upgrade still kaputtgeht

• gitRepo-Volume ist endgültig deaktiviert: Manifeste mit gitRepo: produzieren defekte Pods. Fix: Build in die CI verlegen und das Artefakt mounten.
• IPVS-Mode kube-proxy ist entfernt (war seit 1.35 deprecated). Migration: iptables mit nftables-Backend, oder Cilium/eBPF.
• 1.36 ist das letzte Release mit containerd-1.6-Support. Den containerd-2.x-Bump parallel zum Upgrade vorbereiten.
• service.spec.externalIPs emittiert jetzt Warnungen: der Weg zur Entfernung ist klar. Umzug auf einen Ingress-Controller oder Gateway API.

Triage für einen Monat

Adopt early: MutatingAdmissionPolicy GA, User Namespaces GA, Suspended Job mutability, Fine-Grained Kubelet Authz. Adopt selectively: DRA für GPU-lastige Workloads — Partitionable Devices kommen als Beta bereits aktiviert, OCI-Artefakt-Volumes, In-Place VPA (wenn man bereits VPA fährt). Watch, don't rush: HPA Scale-to-Zero (immer noch Alpha, braucht ein Feature-Gate), Gang Scheduling (API seit 1.35, drei Gates aus), Mixed Version Proxy (Beta), Smarter HPA Pod Selection (Alpha). Vor dem kubeadm upgrade ist das Pflicht-Paar kubent + Pluto gegen Manifeste und Helm-Charts; deprecated-API-Leaks existieren in den meisten Clustern und tauchen erst während des Upgrades selbst auf.