Kubernetes v1.36 verständlich erklärt
Katrin Peter 6 Minuten Lesezeit

Kubernetes v1.36 verständlich erklärt

Kubernetes klingt für viele zunächst wie ein reines Entwicklerthema – komplex, technisch und weit entfernt vom eigenen Arbeitsalltag. Doch genau das ist ein Trugschluss. Denn im Kern geht es bei Kubernetes um etwas sehr Grundlegendes: Wie moderne Software zuverlässig betrieben wird.

Kubernetes klingt für viele zunächst wie ein reines Entwicklerthema – komplex, technisch und weit entfernt vom eigenen Arbeitsalltag. Doch genau das ist ein Trugschluss. Denn im Kern geht es bei Kubernetes um etwas sehr Grundlegendes: Wie moderne Software zuverlässig betrieben wird.

Oder einfacher gesagt: Kubernetes sorgt dafür, dass digitale Anwendungen – von Online-Shops bis hin zu internen Unternehmenssystemen – stabil laufen, auch wenn im Hintergrund ständig Veränderungen passieren.

Damit wird Kubernetes zu einer Art Betriebssystem für die digitale Infrastruktur.

Und genau deshalb lohnt sich ein Blick auf neue Versionen wie Kubernetes v1.36 – auch ohne technischen Hintergrund.


Ein Release, das vor allem eines tut: Verantwortung verschieben

Wenn man sich die geplanten und bereits beschlossenen Änderungen in Kubernetes v1.36 genauer anschaut, fällt ein roter Faden auf, der sich durch nahezu alle Bereiche zieht – und der sich am besten so beschreiben lässt:

Kubernetes nimmt seinen Nutzern Bequemlichkeit ab, um ihnen dafür Kontrolle zurückzugeben.

Was zunächst widersprüchlich klingt, entfaltet seine Wirkung vor allem dann, wenn man versteht, dass viele der bisherigen „einfachen" Lösungen zwar schnell zum Ziel führten, dabei jedoch oft Sicherheitslücken, Intransparenz oder schwer kontrollierbare Abhängigkeiten in Kauf genommen wurden.

Mit Version 1.36 wird genau hier angesetzt – und zwar sehr konkret.


Wenn Bequemlichkeit zum Risiko wird: Warum Funktionen verschwinden

Eine der bereits fest beschlossenen Änderungen betrifft eine Funktion mit dem technischen Namen externalIPs. Hinter diesem sperrigen Begriff verbirgt sich im Grunde eine einfache Idee: Man konnte relativ unkompliziert festlegen, wie externe Zugriffe auf Anwendungen im System geleitet werden.

Das war bequem, weil es schnell ging und wenig Abstimmung erforderte. Gleichzeitig lag genau darin das Problem.

Denn was vielen nicht bewusst war: Diese Offenheit ermöglichte es unter bestimmten Umständen auch, Datenverkehr umzuleiten – etwa so, dass er unbemerkt über fremde Systeme läuft. Ein klassisches Einfallstor für sogenannte Man-in-the-Middle-Angriffe.

Mit Kubernetes v1.36 wird diese Funktion nun offiziell als veraltet markiert (Deprecation – sicher beschlossen). Sie funktioniert zunächst weiter, aber jede Nutzung erzeugt Warnungen – ein deutliches Signal, dass hier Handlungsbedarf besteht, bevor die Funktion in einer späteren Version vollständig verschwindet.

Der eigentliche Mehrwert dieser Änderung liegt daher nicht nur in der Technik, sondern in der Klarheit:

Statt stillschweigend Risiken zu tolerieren, zwingt Kubernetes seine Nutzer dazu, bewusstere und sicherere Wege zu wählen – etwa strukturierte Netzwerkmodelle, bei denen klar definiert ist, wer auf was zugreifen darf.


Ein stiller, aber wichtiger Schnitt: Das Ende von gitRepo

Noch konsequenter zeigt sich dieser Ansatz bei einer zweiten Änderung, die ebenfalls final beschlossen und mit v1.36 umgesetzt wird: der vollständigen Entfernung des sogenannten gitRepo-Mechanismus.

Was auf den ersten Blick wie ein praktisches Feature wirkte – nämlich Code direkt beim Start einer Anwendung aus einem Repository zu laden – entpuppt sich bei genauerem Hinsehen als riskante Abkürzung.

Denn dieser Mechanismus führte dazu, dass Code aus externen Quellen unter Umständen mit weitreichenden Systemrechten ausgeführt wurde. Anders formuliert: Man hat sich damit eine Hintertür geöffnet, ohne sie immer als solche zu erkennen.

Mit der Entfernung dieser Funktion wird ein klares Signal gesetzt:

Moderne IT-Systeme sollen nicht nur funktionieren, sondern auch nachvollziehbar und überprüfbar sein.

Der Vorteil liegt dabei weniger in der unmittelbaren Funktionalität, sondern in der strukturellen Verbesserung: Unternehmen sind gezwungen, sauberere Prozesse zu etablieren – etwa durch klar definierte Deployments oder GitOps-Ansätze, bei denen jede Änderung versioniert und nachvollziehbar ist.


Sicherheit neu gedacht: Wenn Schlüssel nicht mehr im selben System liegen

Eine der wichtigsten geplanten, aber noch nicht final bestätigten Neuerungen betrifft den Umgang mit Sicherheitsschlüsseln – ein Thema, das oft unterschätzt wird, obwohl es im Zentrum jeder digitalen Infrastruktur steht.

Bisher war es üblich, dass Kubernetes viele dieser Schlüssel selbst verwaltet. Das ist praktisch, führt aber zu einer kritischen Abhängigkeit: Das System, das Anwendungen betreibt, ist gleichzeitig auch für deren Absicherung zuständig.

Mit der neuen Funktion zur externen Signierung von ServiceAccount-Tokens (voraussichtlich GA in v1.36, aber noch nicht final bestätigt) wird genau diese Kopplung aufgelöst.

Das bedeutet in der Praxis:

Schlüssel können künftig in externen, spezialisierten Systemen liegen – etwa in besonders gesicherten Hardware-Modulen oder zentralen Schlüsselverwaltungen.

Der Vorteil erschließt sich vor allem dann, wenn man einen Schritt zurücktritt:

  • Sicherheit wird aus dem operativen System ausgelagert
  • Verantwortlichkeiten werden klarer getrennt
  • bestehende Compliance-Strukturen lassen sich besser integrieren

Gerade im Kontext europäischer Datenstrategien und regulatorischer Anforderungen entsteht hier ein echter Hebel für digitale Souveränität, weil Unternehmen die Kontrolle über kritische Sicherheitskomponenten behalten – unabhängig davon, wo ihre Anwendungen laufen.


Wenn Infrastruktur effizienter wird: Mehr aus vorhandenen Ressourcen holen

Ein weiterer Bereich, der zunächst technisch wirkt, aber wirtschaftlich hoch relevant ist, betrifft die Nutzung von Hardware – insbesondere teurer Spezialressourcen wie GPUs.

Hier plant Kubernetes eine Erweiterung, die es ermöglicht, solche Geräte aufzuteilen und mehreren Anwendungen gleichzeitig zur Verfügung zu stellen (geplant, nicht final bestätigt).

Um das greifbar zu machen, hilft ein einfaches Bild:

Bisher war es oft so, als würde man für jede Aufgabe ein ganzes Fahrzeug reservieren – selbst wenn man nur einen Bruchteil der Kapazität benötigt. Mit der neuen Funktion können mehrere „Fahrgäste" dasselbe „Fahrzeug" nutzen, ohne sich gegenseitig zu behindern.

Der Vorteil liegt auf der Hand:

  • Höhere Auslastung vorhandener Infrastruktur
  • Weniger Bedarf an zusätzlicher Hardware
  • Geringere Kosten bei gleichzeitig besserer Performance

Gerade für Unternehmen, die eigene Rechenzentren betreiben oder Cloud-Kosten optimieren wollen, ist das ein wichtiger Schritt – auch wenn die finale Umsetzung noch abzuwarten ist.


Mehr Ordnung im System: Wer darf eigentlich was nutzen?

Eng damit verbunden ist eine weitere geplante Funktion, die dafür sorgt, dass bestimmte Ressourcen nur dann genutzt werden dürfen, wenn dies explizit erlaubt ist (ebenfalls geplant, noch nicht final bestätigt).

Auch hier geht es weniger um Technik im engeren Sinne, sondern um Governance:

In komplexen Systemen ist es entscheidend zu wissen, wer auf welche Ressourcen zugreift – und warum.

Durch diese Mechanismen wird verhindert, dass Anwendungen versehentlich oder unkontrolliert auf sensible oder teure Ressourcen zugreifen. Stattdessen entsteht ein klar geregeltes System, das sich besser überwachen und steuern lässt.


Ein Blick über das Release hinaus: Warum Ingress NGINX verschwindet

Zeitlich eng mit Kubernetes v1.36 verbunden, aber nicht Teil des Releases selbst, ist die Einstellung von Ingress NGINX.

Dieses Werkzeug wurde lange genutzt, um Zugriffe von außen auf Anwendungen zu steuern. Dass es nun nicht mehr weiterentwickelt wird, zeigt, wie stark sich die Anforderungen verändert haben.

Der entscheidende Punkt dabei ist weniger das „Was", sondern das „Warum":

Ältere Lösungen stoßen an Grenzen, wenn es um Sicherheit, Wartbarkeit und Standardisierung geht. Deshalb verschiebt sich das Ökosystem in Richtung moderner Ansätze wie der Gateway API, die strukturierter, klarer und langfristig besser kontrollierbar sind.


Was sich insgesamt verändert – und warum das relevant ist

Wenn man all diese Entwicklungen zusammennimmt, ergibt sich ein klares Bild, das über einzelne Features hinausgeht.

Kubernetes entwickelt sich in Richtung einer Plattform, die:

  • weniger implizite Annahmen trifft
  • mehr explizite Entscheidungen erfordert
  • dafür aber deutlich transparenter und kontrollierbarer wird

Das hat unmittelbare Auswirkungen auf Unternehmen:

Systeme werden nicht mehr „einfach irgendwie" betrieben, sondern bewusst gestaltet.

Und genau darin liegt – bei aller zusätzlichen Komplexität – der eigentliche Vorteil.


Fazit: Kontrolle ersetzt Bequemlichkeit

Kubernetes v1.36 bringt keine spektakulären Einzelinnovationen, sondern eine konsequente Weiterentwicklung, die sich erst im Gesamtbild vollständig erschließt.

Unsichere Funktionen werden entfernt, neue Möglichkeiten schaffen mehr Kontrolle, und bestehende Mechanismen werden so angepasst, dass sie besser in moderne Sicherheits- und Governance-Modelle passen.

Oder anders formuliert, und bewusst etwas zugespitzt:

Kubernetes wird nicht schwieriger – es wird ehrlicher.

Für Unternehmen, die ihre digitale Infrastruktur langfristig souverän betreiben wollen, ist genau das eine gute Nachricht.

Ähnliche Artikel

IT-Gesetze 2026:

Das Jahr, in dem europäische Regulierung operativ wird 2026 ist kein Jahr neuer digitalpolitischer …

02.02.2026