Kubernetes 1.36 GA: Was wirklich stabil ist – und was Marketing ist

Kubernetes 1.36 ist seit einigen Wochen General Availability, und in Homelab-Foren und Admin-Kanälen kursiert bereits der Satz „native eBPF-Integration“. Schön wäre es. Was tatsächlich GA wurde, ist nüchterner – aber für Self-Hosting-Betreiber trotzdem relevant: User Namespaces, härtere Admission-Kontrolle und ein paar Aufräumarbeiten, die beim nächsten Cluster-Upgrade zuschlagen können.

Kubernetes 1.36: Was GA wirklich bedeutet

Kubernetes 1.36 wurde laut den offiziellen Release-Angaben mit 70 Enhancements ausgeliefert. Davon haben es 18 Features bis zu Stable respektive General Availability geschafft, 25 liegen als Beta vor, weitere 25 als Alpha. Das ist erst einmal eine trockene Zahl, aber sie zeigt die Richtung: Kubernetes 1.36 ist kein Release mit einem einzigen Leuchtturm-Feature, sondern eine Sammlung kleinerer, sicherheitsrelevanter Schritte, die sich in Summe auf Produktionscluster auswirken.

Das größte GA-Feature heißt User Namespaces für Pods. Die Kubernetes-Steering-Group beschreibt das offiziell als Linux-spezifische Funktion, die Container besser vom Host-Kernel isoliert, ohne dass Betreiber dafür zusätzliche Sidecars oder Runtime-Patches brauchen. Wer schon einmal einen root-Prozess in einem Container hatte, der sich als root auf dem Host ausgab, weiß, warum das kein Randthema ist.

Zur Kernaussage „native eBPF-Integration“ muss ich als jemand, der lieber Changelogs liest als Marketing-Folien, klar widersprechen: Das ist in den offiziellen Kubernetes-1.36-Unterlagen so nicht zu finden. eBPF ist im Kubernetes-Ökosystem seit Jahren präsent, aber als Bestandteil von CNI-Plugins wie Cilium – nicht als frisch eingebautes Kernfeature des Orchestrators selbst. Diese Unterscheidung ist mehr als Wortklauberei, denn sie entscheidet darüber, was Sie beim Upgrade tatsächlich erwarten dürfen.

User Namespaces GA: Pod-Isolation wird ernst genommen

Für Self-Hosting-Betreiber ist User Namespaces das praktisch relevanteste Stück aus Kubernetes 1.36. Die Funktion mappt UIDs und GIDs innerhalb eines Pods auf einen anderen Bereich auf dem Host-System. Ein Prozess, der im Container als UID 0 läuft, ist auf dem Host eben nicht mehr root, sondern ein unprivilegierter Nutzer mit einer hohen, isolierten UID.

Das klingt nach Kernel-Detail, ist aber genau die Art Absicherung, die auf einem Homelab-Cluster oder einem kleinen On-Prem-Setup ohne dedizierte Security-Abteilung den Unterschied macht. Wenn ein kompromittierter Container ausbricht, trifft er auf eine Sandbox statt auf den echten Host. Für Betreiber, die Kubernetes nicht bei einem Hyperscaler, sondern auf eigener Hardware im Keller oder im Rechenzentrum betreiben, ist das ein handfester Sicherheitsgewinn ohne zusätzliche Tools.

Wichtig für die Praxis: User Namespaces sind, wie erwähnt, ein Linux-only Feature. Wer heterogene Cluster mit Windows-Nodes fährt, muss weiterhin differenzieren. Und wer alte Runtime-Konfigurationen mitschleppt, sollte vor der Aktivierung prüfen, ob Init-Container oder Volume-Mounts noch von festen UID-Annahmen ausgehen. Das ist kein Blocker, aber ein Punkt für die Migrationscheckliste.

Praxisbeispiel: Ein Drei-Node-Cluster im Vereinsheim

Wie sich das in der Praxis anfühlt, zeigt ein einfaches Szenario: Ein Verein betreibt drei gebrauchte Mini-PCs als Kubernetes-Cluster, verwaltet über k3s, mit einer Handvoll Diensten wie Nextcloud, einem internen Wiki und einem kleinen Tracking-Dienst. Vor dem Umstieg auf Kubernetes 1.36 lief dort noch ein Pod, dessen Prozess mit UID 0 gestartet wurde, weil das zugrunde liegende Container-Image das so vorsah und niemand die Zeit hatte, das umzubauen. Mit User Namespaces GA lässt sich genau dieser Fall entschärfen, ohne das Image anfassen zu müssen: Der Container denkt weiterhin, er sei root, der Host sieht davon aber nur einen unprivilegierten Nutzer. Für ehrenamtlich betriebene Infrastruktur, bei der niemand hauptberuflich Security-Reviews macht, ist das genau die Art Verbesserung, die im Hintergrund wirkt, ohne dass jemand aktiv etwas konfigurieren muss – vorausgesetzt, die Distribution hat das Feature bereits aktiviert. Wer unsicher ist, ob der eigene Cluster davon profitiert, sollte nach dem Upgrade prüfen, ob die Pod-Spezifikationen das Feld für User Namespaces überhaupt setzen; ohne explizite Konfiguration bleibt der alte Zustand erhalten.

Admission Policies, Kubelet-Autorisierung, SELinux: Der Security-Schwerpunkt

Neben User Namespaces sind in Kubernetes 1.36 mehrere Security-Features GA geworden, die zusammen ein klares Bild ergeben: Mutating Admission Policies, Fine-Grained Kubelet API Authorization, SELinux Volume Labeling und Declarative Validation. Fachberichte wie InfoQ ordnen den Release deshalb konsistent als Security-Hardening-Release ein, nicht als API-Feuerwerk.

Mutating Admission Policies erlauben es, Pod-Spezifikationen bereits beim Erstellen deklarativ zu verändern, statt dafür einen eigenen Webhook-Service zu betreiben. Für kleinere Self-Hosting-Teams ist das ein echter Betriebsvorteil: weniger zusätzliche Deployments, weniger Angriffsfläche, weniger Dinge, die um 3 Uhr nachts ausfallen können.

Fine-Grained Kubelet API Authorization schränkt ein, wer mit welchen Rechten auf die Kubelet-API eines Nodes zugreifen darf. Bisher war das eher grobkörnig geregelt. Wer produktive Cluster mit mehreren Admin-Teams betreibt, bekommt damit ein Werkzeug, das Rechtevergabe granularer macht, ohne gleich ein komplettes Service-Mesh einzuführen.

SELinux Volume Labeling schließlich ist für alle relevant, die Storage-Backends mit SELinux-Enforcement fahren – ein Setup, das in klassischen Enterprise-Linux-Umgebungen häufiger vorkommt, als es die Cloud-Native-Marketingfolien vermuten lassen. Zusammen mit Volume Group Snapshots und Verbesserungen an der Dynamic Resource Allocation zeigt Kubernetes 1.36, dass Storage und Betrieb diesmal wichtiger genommen wurden als neue Programmierschnittstellen.

eBPF und Self-Hosted Networking: Ökosystem statt Kernfeature

Jetzt zum Kern der Verwirrung. eBPF ist keine Erfindung von Kubernetes 1.36, sondern ein Linux-Kernel-Mechanismus, den die Kubernetes-Community bereits seit 2017 in offiziellen Blogposts diskutiert – damals ging es um Netzwerk-Monitoring und frühe CNI-Experimente. Was sich seither entwickelt hat, ist das Ökosystem drumherum: eBPF-basierte CNI-Plugins wie Cilium haben sich zum De-facto-Standard für performantes Kubernetes-Networking entwickelt, weil sie Netzwerk-Policies direkt im Kernel durchsetzen, statt über klassische iptables-Regelketten zu gehen.

Genau hier setzt der Begriff „Self-Hosted-Networking“ an, den ich in der Praxis eher als Architekturbeschreibung denn als offiziellen Kubernetes-Terminus verstehe. Wer einen Cluster selbst hostet – im Homelab, auf Bare-Metal-Servern oder in einem gemieteten Rack – installiert die Netzwerkschicht selbst, statt sie von einem Cloud-Provider als Blackbox zu bekommen. Genau da liefert eBPF handfeste Vorteile: geringerer Overhead als klassische iptables-Chains, bessere Observability von Netzwerk-Policies, und das ganz ohne Sidecar-Proxys, die zusätzliche RAM- und CPU-Kosten verursachen.

Google Cloud hat diesen Zusammenhang in einem eigenen Blogpost zu eBPF und Cilium in GKE beschrieben – dort geht es zwar um einen Managed-Dienst, das zugrunde liegende Prinzip funktioniert aber genauso auf einem selbst betriebenen Cluster. Wer heute einen neuen Self-Hosted-Cluster aufsetzt, wählt eBPF-fähige CNI-Plugins nicht, weil Kubernetes 1.36 das erzwingt, sondern weil sie schlicht die reifste Option für Kubernetes-Ingress, Netzwerk-Policies und Kubernetes-Namespace-Isolation im Jahr 2026 sind.

Meine persönliche Einschätzung: Es ist ärgerlich, wenn Release-Ankündigungen Ökosystem-Trends als Kernfeature verkaufen. Das nährt Erwartungen, die das eigentliche Changelog nicht erfüllt, und sorgt bei Admins für Verwunderung, wenn nach dem Upgrade plötzlich niemand ein neues eBPF-Toggle findet. Ehrlicher wäre die Formulierung „Kubernetes 1.36 GA schafft die sicherheitsseitigen Grundlagen, auf denen moderne eBPF-CNI-Stacks noch solider laufen“ – weniger knackig, aber korrekt.

Ist die Kritik an der Marketing-Vereinfachung überzogen?

Man kann einwenden, dass diese Detailkritik am Ende Wortklauberei ist: Wenn Nutzer durch die Schlagzeile „native eBPF-Integration“ überhaupt erst auf eBPF-CNI-Plugins aufmerksam werden und in der Folge einen sichereren, performanteren Cluster betreiben, wäre das Ergebnis doch positiv, unabhängig davon, ob die Formulierung technisch korrekt war. Dieses Argument hat einen wahren Kern – am Ende zählt für viele Betreiber, was im Cluster ankommt, nicht wie die Ankündigung formuliert war. Trotzdem bleibt die Unterscheidung wichtig, weil falsche Erwartungen konkrete Folgekosten haben: Wer nach dem Upgrade ein eBPF-Toggle in der Kubernetes-Konfiguration sucht, verschwendet Zeit, die er stattdessen in die Migration von gitRepo-Volumes oder die Umstellung auf CSI-Treiber hätte stecken können. Genauigkeit bei Release Notes ist deshalb kein Selbstzweck, sondern spart im Zweifel echte Arbeitsstunden im Betrieb.

Breaking Changes: gitRepo und Portworx verschwinden

Zum Pflichtprogramm jedes Kubernetes-Upgrades gehört der Blick auf Breaking Changes, und die werden in Ankündigungen gerne unter den Tisch fallen gelassen. Für Kubernetes 1.36 wird berichtet, dass der gitRepo-Volume-Typ dauerhaft deaktiviert bleibt – ein alter Mechanismus, um Git-Repositories direkt als Volume in Pods einzubinden, der schon länger als unsicher galt und in aktuellen Versionen faktisch nicht mehr nutzbar ist. Wer noch alte Manifeste mit gitRepo-Volumes im Repository liegen hat, sollte diese vor dem Upgrade auf Init-Container mit expliziten Git-Clone-Schritten umstellen.

Ebenfalls entfernt wurde nach diesen Berichten das In-Tree-Plugin für Portworx-Storage. Das betrifft alle, die ihre persistenten Volumes noch über die alte In-Tree-Integration statt über den zugehörigen CSI-Treiber anbinden. Für ein Self-Hosting-Setup mit Storage-Cluster ist das kein Wochenend-Projekt, sondern eine Migration, die man rechtzeitig einplant, am besten in einem Staging-Cluster testet und dann erst produktiv ausrollt.

Ich empfehle grundsätzlich, solche Angaben nicht aus Zweitquellen zu übernehmen, sondern vor jedem Produktions-Upgrade das offizielle Kubernetes-Release-Blog und das zugehörige Changelog im Kubernetes-GitHub-Repository gegenzuchecken. Release Notes sind Marketing mit Fakten drin, das Changelog ist die Wahrheit mit schlechter Lesbarkeit.

Praxis: Upgrade-Pfad für Homelab und kleine Cluster

Für alle, die Kubernetes nicht in einer Enterprise-Umgebung, sondern im Homelab oder auf einem kleinen Set von Bare-Metal-Servern betreiben, lohnt sich ein strukturierter Weg statt eines Direktsprungs auf Kubernetes 1.36. Zunächst: Kubernetes-Versionen sauber dokumentieren, bevor Sie upgraden. Welche API-Objekte, welche Kubernetes-Deployment-Manifeste, welche Kubernetes-Ingress-Regeln laufen aktuell produktiv?

Zweitens: Ein Staging-Cluster mit identischer Topologie aufsetzen, dort auf Kubernetes 1.36 gehen und alle Workloads durchtesten – inklusive Dinge, die selten anfallen, wie RabbitMQ-Kubernetes-Deployments mit persistenten Volumes oder Services mit expliziter ImagePullPolicy. Gerade ImagePullPolicy-Einstellungen und Service-Resource-Definitionen sind erfahrungsgemäß die Stellen, an denen alte Annahmen aus früheren Kubernetes-Versionen unbemerkt weiterleben.

Drittens: Wer mit Rancher-Kubernetes-Distributionen wie k3s oder RKE arbeitet, sollte prüfen, wann der jeweilige Anbieter 1.36 offiziell unterstützt – Distributionen ziehen erfahrungsgemäß mit ein paar Wochen Abstand nach. Auf einem Azure-Kubernetes-Service-Cluster oder anderen Managed-Angeboten übernimmt der Provider das Timing ohnehin, im Self-Hosted-Betrieb liegt die Verantwortung komplett bei Ihnen.

Viertens: Nach dem Upgrade lohnt der Blick ins Kubernetes-Dashboard oder in Ihr bevorzugtes Monitoring, um zu prüfen, ob die neuen Admission Policies bestehende Deployments blockieren. Declarative Validation ist strenger als frühere Prüfmechanismen – das ist gewollt, kann aber alte, etwas schlampig geschriebene Manifeste sichtbar machen, die vorher einfach durchgerutscht sind.

Kubernetes vs. Docker, Rancher und der Alltag im Self-Hosting

Die Diskussion Kubernetes vs. Docker taucht in Foren immer wieder auf, meist von Leuten, die eigentlich Docker Compose meinen. Docker ist eine Container-Runtime beziehungsweise ein Werkzeugsatz, Kubernetes ist der Orchestrator darüber. Für ein einzelnes Homelab-Projekt mit drei Containern braucht niemand Kubernetes 1.36 – da reicht Docker Compose völlig. Sobald Sie aber mehrere Nodes, Failover, Rolling Updates und deklarative Kubernetes-Deployment-Strategien brauchen, wird der Umstieg sinnvoll.

Rancher-Kubernetes-Distributionen wie k3s haben sich im Self-Hosting-Bereich deshalb durchgesetzt, weil sie die Komplexität von Kubernetes 1.36 in eine handhabbare Binärdatei packen, ohne die API-Kompatibilität zu verlieren. Wer schon einmal versucht hat, einen Kubernetes-Cluster von Hand mit kubeadm auf drei Raspberry Pis aufzuziehen, weiß, warum diese Distributionen existieren.

Ist der ganze Aufwand für ein Homelab wirklich gerechtfertigt, oder reicht am Ende doch ein simples Docker-Setup mit Reverse Proxy? Diese Frage stelle ich mir bei jedem neuen Projekt neu, und die Antwort hängt schlicht davon ab, ob Sie Ausfallsicherheit lernen oder produktiv brauchen wollen. Für reines Lernen ist ein Drei-Node-k3s-Cluster mit Kubernetes 1.36 ein hervorragendes Testfeld für Kubernetes-Namespace-Trennung, Kubernetes-Ingress-Controller und Service-Resource-Definitionen – ohne Cloud-Rechnung am Monatsende.

Wer sich tiefer einarbeiten will, findet die verlässlichsten Informationen nach wie vor in der offiziellen Kubernetes-Documentation und nicht in Zusammenfassungen dritter Anbieter. Auch Analysen wie die von InfoQ zu Kubernetes 1.36 sind eine gute Ergänzung, ersetzen aber nicht den Blick ins Original.

Was bleibt?

Kubernetes 1.36 ist ein solides, unspektakuläres Release – und das ist ausdrücklich ein Kompliment, kein Vorwurf. User Namespaces GA, granularere Kubelet-Autorisierung und strengere Admission-Kontrolle sind genau die Art von Fortschritt, die Self-Hosting-Betreiber ohne eigene Security-Abteilung brauchen. Die eBPF-Story dagegen bleibt, was sie schon vorher war: ein Ökosystem-Trend, getragen von CNI-Projekten wie Cilium, nicht ein frisches Kernfeature von Kubernetes 1.36 selbst.

Wer sich nicht durch jedes Release-Blog und jedes GitHub-Issue wühlen möchte, greift inzwischen auch auf KI-gestützte Zusammenfassungen zurück, etwa Werkzeuge wie Claude 4, um Breaking Changes und GA-Features vorab grob einordnen zu lassen. Das ersetzt nicht die eigene Prüfung im Staging-Cluster, spart aber beim ersten Überblick oft Zeit – solange man das Ergebnis nicht ungeprüft in die Produktionsplanung übernimmt.

Für den nächsten Kubernetes-Upgrade-Zyklus lohnt sich eine kurze Checkliste, die über Kubernetes 1.36 hinaus Bestand hat:

• Offizielles Release-Blog und Changelog gegen Z