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.

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, 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), 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.