Kubernetes 1.36: Was Self-Hosting-Admins bei API-Änderungen und Upgrades prüfen müssen

Kubernetes 1.36 „Haru“ ist seit dem 22. April 2026 der aktuelle stabile Upstream-Release – und er bringt mehrere Änderungen, die Self-Hosting-Admins konkret in den Kalender eintragen müssen. Nicht wegen Drama, sondern wegen handwerklicher Sorgfalt.

Was in 1.36 wirklich zählt – und was nur Lärm ist

Jeder Kubernetes-Release kommt mit einem Changelog, der auf den ersten Blick endlos wirkt. Die meisten Punkte betreffen Alpha-Features, die für Self-Hosting-Umgebungen mittelfristig irrelevant sind. Was in 1.36 zählt, sind drei Dinge: das endgültige Disable von gitRepo Volumes, die Deprecation von spec.externalIPs in Service-Objekten und das Retirement des Ingress-Nginx-Projekts als gepflegtes Upstream-Projekt. Hinzu kommt das Stable-Werden von User Namespaces für Pods. Das sind keine theoretischen API-Änderungen – das sind konkrete Bruchstellen für Cluster, die nicht vorbereitet sind.

Meine Einschätzung: Wer seit 1.29 oder 1.30 keine API-Hygiene betrieben hat, wird bei diesem Upgrade zum ersten Mal spürbar stolpern. Die Kubernetes-Community kommuniziert Deprecation-Zeitachsen inzwischen deutlich klarer als früher, aber das nutzt nichts, wenn niemand im Team aktiv auf Deprecation-Warnings im API-Server-Log schaut.

Der vollständige offizielle Release-Blog zu Kubernetes v1.36 listet alle 64 Enhancements mit Status auf. Wer ein Upgrade plant, sollte mindestens die „stable“ und „removed“-Einträge dort quer lesen.

gitRepo Volume: Lange angekündigt, jetzt endgültig weg

Das gitRepo-Volume-Plugin ist seit Kubernetes v1.11 als deprecated markiert – also seit Jahren. In v1.36 ist es nun permanent deaktiviert. Es gibt kein Feature-Gate, das man aktivieren könnte, um es zurückzubekommen. Jedes Manifest, jeder Helm-Chart oder Operator, der noch gitRepo nutzt, schlägt beim Deployment schlicht fehl.

Das klingt nach einer Kleinigkeit. Ist es aber nicht, wenn man Cluster betreibt, die über die Jahre gewachsen sind und deren Helm-Charts seit 2020 kaum angefasst wurden. Die Checkliste ist einfach: grep -r "gitRepo" ./charts/ und alle gefundenen Manifeste auf Init-Container mit EmptyDir oder auf CI/CD-seitige Git-Checkouts vor dem Deployment umstellen. Wer CSI-Treiber für Repository-Inhalte nutzen will, findet dort ebenfalls Alternativen.

Wer jetzt „das betrifft uns nicht“ denkt: Bitte erst suchen, dann urteilen. Gerade Cluster in mittleren Unternehmen mit selbst gepflegten Operators aus früheren Jahren haben erfahrungsgemäß überraschend viele solche Relikte.

spec.externalIPs: Deprecation mit Zeitplan bis ca. 1.43

Das Feld spec.externalIPs in Kubernetes-Service-Objekten wird in v1.36 als deprecated markiert. Es funktioniert noch – erzeugt aber Deprecation-Warnings im API-Server. Gleichzeitig wird das Feature-Gate AllowServiceExternalIPs in kube-proxy eingeführt, mit dem sich die Programmierung der entsprechenden Regeln bereits jetzt deaktivieren lässt.

Der Zeitplan laut Community und Sysdig-Analyse: In ca. v1.40 soll das Feature-Gate standardmäßig deaktiviert werden, in ca. v1.43 wird es vollständig entfernt. Das klingt nach viel Vorlaufzeit, ist es aber nicht, wenn man bedenkt, dass Kubernetes alle vier Monate einen neuen Minor-Release liefert. Von 1.36 bis 1.43 sind das sieben Releases, also knapp zwei Jahre. Wer heute eine neue Service-Konfiguration mit externalIPs einführt, baut technische Schulden auf.

Die Empfehlung von Sysdig ist direkt: Das Feature-Gate AllowServiceExternalIPs frühzeitig deaktivieren, um Bruchstellen sofort sichtbar zu machen, statt sie bis 1.43 mitzuschleppen. Das ist pragmatisch. Migrationspfade sind LoadBalancer-Services, NodePort oder – für komplexere Setups – die Gateway API. Für Sysdig’s Analyse der Security-Features und Deprecations in 1.36 lohnt sich der Blick auch auf die CSI-Secret-Handling-Änderungen, die im gleichen Artikel beschrieben werden.

Ingress-Nginx retired: Kein Drama, aber ein Datum setzen

Das Ingress-Nginx-Projekt wird upstream als „retired“ markiert – es erhält keine neuen Security-Patches mehr. Bestehende Installationen funktionieren weiter. Das ist der entscheidende Unterschied: Es ist kein Hard-Remove wie bei gitRepo, sondern ein Support-Ende. Wer Ingress-Nginx heute produktiv betreibt, tut das auf eigenes Risiko, sobald die nächste CVE auftaucht und kein Fix kommt.

Für internet-exponierte Cluster ist das eine klare Handlungsaufforderung. Die Gateway API ist der empfohlene Nachfolger – rollenorientierter, mit besserem Traffic-Split und erweitertem Routing. Alternativen wie Contour, Istio oder Envoy-basierte Controller sind ebenfalls aktiv gepflegt. Die Migration ist kein Wochenend-Projekt, aber sie lässt sich in Phasen planen: erst Inventur, dann Paralleltest in einer Namespace-Isolation, dann Cutover.

Wer Rancher als Management-Schicht nutzt, sollte zusätzlich prüfen, ob und wie Rancher mit Gateway-API-Ressourcen umgeht – dort gibt es eigene Controller-Layers, die nicht immer automatisch mit Upstream-Änderungen synchronisiert werden. Vendor-Release-Notes lesen ist hier keine optionale Aufgabe.

User Namespaces: Jetzt stable – Policies prüfen

User Namespaces für Pods erreichen in v1.36 den Status „stable“. Das bedeutet: Prozesse im Container können als root laufen, werden auf dem Host aber als unprivilegierter User gemappt. Das ist eine substanzielle Härtung gegen Container-Escapes, die in der Praxis oft unterschätzt wird.

Für Self-Hosting-Umgebungen gibt es zwei konkrete Prüfpunkte. Erstens: Sind die eigenen Pod Security Admission Policies so konfiguriert, dass sie User-Namespace-Nutzung korrekt erlauben oder explizit verbieten? Wer bisher implizit davon ausgegangen ist, dass kein Container User Namespaces nutzt, muss das jetzt explizit machen. Zweitens: Security-Tools wie Falco oder eBPF-basierte Sensoren müssen mit User Namespaces umgehen können – nicht alle Versionen tun das transparent. Testen vor dem Upgrade, nicht danach.

Die Stabilisierung bedeutet auch, dass Feature-Gate-basierte Opt-ins in der Konfiguration aufgeräumt werden sollten. Wer User Namespaces bisher über Alpha- oder Beta-Feature-Gates aktiviert hatte, muss prüfen, ob diese Gates in 1.36 entfallen sind oder sich verändert haben.

Dynamic Resource Allocation und Manifest-basierte Admission-Kontrolle

Zwei weitere Punkte verdienen Aufmerksamkeit, auch wenn sie für viele Self-Hosting-Setups noch nicht sofort relevant sind. Erstens: Dynamic Resource Allocation (DRA) erhält in 1.36 weitere Enhancements, darunter die Möglichkeit, einzelne Devices für Wartung offline zu nehmen, ohne den gesamten Knoten zu drainieren. Wer GPU-Workloads oder AI-Inferenz-Pods auf dem eigenen Cluster betreibt, sollte prüfen, ob die verwendeten DRA-Treiber mit v1.36 kompatibel sind – und ob neue Features wie gezieltes Device-Tainting genutzt werden können.

Zweitens ermöglicht 1.36 manifest-basierte Konfiguration von Admission-Controllern. Policies liegen dann als statische Dateien auf der Control-Plane-Disk und sind damit nicht durch kubectl delete oder etcd-Probleme temporär deaktivierbar. Das klingt nach einem Detail, ist aber für sicherheitskritische Self-Hosting-Setups relevant: Wer etwa ein Verbot privilegierter Container durchsetzen will, das nicht durch einen versehentlichen API-Call kippt, sollte das evaluieren. GitOps-Workflows lassen sich so konfigurieren, dass diese Dateien versionskontrolliert ausgerollt werden – was Transparenz und Auditierbarkeit deutlich verbessert.

Was oft übersehen wird: API-Versionswechsel in CRDs und Webhooks

Neben den prominenten Feature-Removals birgt ein Kubernetes-Upgrade auf 1.36 eine weitere, weniger sichtbare Stolperfalle: Custom Resource Definitions und Admission-Webhooks, die intern veraltete API-Versionen referenzieren. Das betrifft vor allem Cluster, die seit 1.25 oder früher nicht vollständig auf admissionregistration.k8s.io/v1 migriert haben oder deren Operator-Bundles noch v1beta1-Webhooks registrieren.

In der Praxis äußert sich das selten als harter Fehler beim Upgrade selbst – der API-Server startet trotzdem. Der Effekt zeigt sich erst im Betrieb: Webhooks, die die alte API-Version erwarten, werden möglicherweise nicht mehr korrekt aufgerufen, Validierungen greifen lautlos nicht mehr, oder Operator-Reconcile-Loops laufen in Fehlerzustände. Das ist die unangenehme Variante eines Upgrade-Problems, weil es nicht sofort sichtbar ist.

Ein nützlicher Ansatz vor dem Upgrade: kubectl get validatingwebhookconfigurations,mutatingwebhookconfigurations -o yaml ausgeben und auf veraltete API-Versionen prüfen. Für CRDs lohnt sich ein Blick auf die spec.versions-Einträge und ob veraltete Versionen noch als served: true markiert sind, obwohl der entsprechende Controller sie längst nicht mehr aktiv nutzt. Aufräumen vor dem Upgrade ist hier einfacher als Debugging danach.

Ein weiterer Aspekt, den Self-Hosting-Admins unterschätzen: Helm-Releases, die mit helm upgrade --reuse-values eingespielt werden, können veraltete API-Versionen aus dem ursprünglichen helm install mitschleppen, wenn die Chart-Templates nicht explizit auf neue API-Versionen aktualisiert wurden. Das gilt insbesondere für Charts, die intern PodDisruptionBudgets oder HorizontalPodAutoscaler in älteren API-Versionen definierten.

Upgrade-Checkliste für Self-Hosting-Admins

Konkret, ohne Buzzword-Bingo: Was muss vor dem Upgrade auf Kubernetes 1.36 geprüft werden?

• gitRepo scannen:grep -r "gitRepo" ./ in allen Chart-Repos, Operator-Definitionen und Custom-Manifesten. Jeder Fund ist ein Blocker.
• externalIPs identifizieren:kubectl get services --all-namespaces -o json | jq '.items[] | select(.spec.externalIPs != null) | .metadata.name' – alle Treffer brauchen einen Migrationsplan.
• Ingress-Nginx-Inventur: Welche Cluster nutzen Ingress-Nginx, welche sind internet-exponiert? Dort Migrationsdatum setzen.
• Deprecation-Warnings aus API-Server-Logs: Seit mindestens 1.34 sollten Warnings gesammelt werden; wenn nicht, jetzt nachholen und Backlog abarbeiten.
• User-Namespace-Policies auditieren: PSA-Konfiguration und Security-Tool-Kompatibilität testen, bevor User Namespaces produktiv genutzt werden.
• Webhooks und CRDs auf veraltete API-Versionen prüfen:validatingwebhookconfigurations und mutatingwebhookconfigurations auf v1beta1-Referenzen scannen, CRD-Versionslisten aufräumen.
• Helm-Charts auf API-Versionen prüfen: Charts, die seit 1.24 oder früher nicht aktualisiert wurden, auf veraltete Ressourcentypen in Templates kontrollieren.
• etcd-Backup vor dem Upgrade: Selbstverständlich, aber in der Hektik trotzdem oft vergessen. Backup verifizieren, nicht nur durchführen.
• Testcluster mit repräsentativem Workload: Upgrade erst dort durchführen, Fehler protokollieren, dann auf Produktion. Kein direkter Prod-Upgrade ohne vorherige Validierung.
• Vendor-Release-Notes lesen: Wer kubeadm, Rancher, k0s oder andere Distributions nutzt, prüft deren spezifischen 1.36-Stand – Upstream-Release bedeutet nicht automatisch sofortige Verfügbarkeit.

Zu den API-Änderungen gibt es einen nützlichen Überblick im Kubernetes-1.36-Überblick von Cloudsmith, der insbesondere die Admission-Control-Änderungen und DRA-Updates praxisnah einordnet.

Wie sich API-Disziplin langfristig auszahlt

Ein Aspekt, der in Upgrade-Diskussionen zu kurz kommt: Die eigentliche Arbeit bei einem Kubernetes-Upgrade wie 1.36 ist selten der Upgrade-Prozess selbst. Sie ist das Ergebnis jahrelanger Entscheidungen darüber, wie viel Aufmerksamkeit API-Hygiene bekommt. Cluster, die konsequent Deprecation-Warnings auswerten, Feature-Gates nach Plan migrieren und Helm-Charts aktuell halten, erleben Kubernetes-Upgrades als Routinevorgang. Cluster, die das nicht tun, erleben sie als Krisenübung.

Das ist keine Kritik an Teams, die unter Ressourcendruck arbeiten – das ist Realität in vielen Self-Hosting-Umgebungen. Aber es lohnt sich, das Verhältnis umzukehren: Wer heute eine Stunde pro Release in API-Hygiene investiert, spart bei jedem Upgrade mehrere Stunden ungeplanter Fehlersuche. Auch in Bezug auf Werkzeuge lohnt es sich, Prozesse zu automatisieren – etwa durch regelmäßige Jobs, die Deprecation-Warnings aus API-Server-Logs in ein Monitoring-System exportieren, statt sie manuell zu suchen. Wer sich für automatisierte Überprüfung von Kubernetes-Konfigurationen in CI-Pipelines interessiert, findet in Tools wie KI-gestützten Analyse-Ansätzen für Infrastruktur-Code mittlerweile ergänzende Optionen, die manuelle Reviews sinnvoll entlasten können.

Langfristig ist der entscheidende Faktor nicht die Qualität eines einzelnen Upgrades, sondern ob ein Team eine strukturierte Upgrade-Praxis aufgebaut hat, die unabhängig von einzelnen Personen funktioniert. Dokumentierte Checklisten, ein Testcluster, der regelmäßig den Produktionsstand spiegelt, und klare Ownership für API-Hygiene sind keine Nice-to-haves – sie sind der Unterschied zwischen einem entspannten Wartungsfenster und einem Sonntagabend-Incident.

Was bleibt – und was Self-Hosting-Admins jetzt tun sollten

Kubernetes 1.36 ist kein revolutionärer Release. Es ist ein Release, der die Konsequenzen langjähriger Deprecations zieht und Security-Defaults in Richtung „sicher by default“ verschiebt. Das ist gut. Aber es bedeutet, dass wer seine API-Hygiene vernachlässigt hat, jetzt Rückstände abbaut – unter Zeitdruck, falls der Cluster produktiv läuft.

Mein pragmatisches Fazit: Der Upgrade-Druck ist realistisch. gitRepo ist weg, externalIPs tickt, Ingress-Nginx hat keinen Security-Support mehr. Wer das auf Wiedervorlage legt, schiebt das Problem nur in einen Release weiter, in dem der Aufwand größer wird, nicht kleiner. Die Kubernetes-Community liefert inzwischen klare Zeitachsen – das ist mehr, als viele andere Open-Source-Projekte bieten. Die Frage ist, ob Teams diese Zeitachsen auch in ihre Planungszyklen übersetzen oder ob sie warten, bis der Ausfall die Priorität setzt.

Was nutzen Sie gerade als Migrationspfad weg von Ingress-Nginx – Gateway API, Contour, oder etwas anderes? Und hat Ihr Cluster nach dem Scan noch gitRepo-Relikte aus besseren Zeiten?