Constantin, Azure & Kubernetes Consultant bei Pexon Consulting | 7 Min. Lesezeit | 16.08.2026
TL;DR
Azure Kubernetes Service unterstützt nur die drei neuesten Kubernetes-Minor-Versionen (N-2). Nach rund zwölf Monaten fällt jede Version aus dem Community-Support: keine Sicherheitspatches mehr. Im August 2026 sind 1.36, 1.35 und 1.34 unterstützt, 1.33 ist seit Juli raus. Wer nicht upgradet, riskiert ungepatchte CVEs oder ein erzwungenes Auto-Upgrade durch Azure.
Warum das Supportende bei AKS anders funktioniert als bei einer VM
AKS ist ein Managed Service, und Microsoft managt genau eine Sache aggressiv: den Versions-Stand. Anders als bei einer VM, die man jahrelang unangetastet laufen lassen kann, hat jede Kubernetes-Version in AKS ein hartes Ablaufdatum. Der Grund liegt upstream: Das Kubernetes-Projekt selbst pflegt nur die drei jüngsten Minor-Versionen. Erscheint eine neue, verliert die älteste ihre Patches. AKS kann nicht patchen, was upstream niemand mehr patcht.
Konkret veröffentlicht die Kubernetes-Community etwa alle vier Monate eine neue Minor-Version, also rund drei pro Jahr. AKS übernimmt jede davon und gibt ihr ab General Availability (GA) rund zwölf Monate Community-Support. In diesem Fenster gibt es Bugfixes und Sicherheitsupdates. Danach ist Schluss, es sei denn, Sie zahlen für Long Term Support (dazu unten).
Das ist keine Kleinigkeit für den Betrieb. Es bedeutet: Ein AKS-Cluster ist kein Set-and-forget-System. Sie müssen mindestens einmal im Jahr upgraden, um im Support zu bleiben. Wer das ignoriert, sammelt CVEs an, verliert den SLA und wird irgendwann von Azure zwangsweise angefasst.
Der AKS Release-Kalender: Wer wann stirbt
Die N-2-Regel bedeutet: unterstützt sind immer die aktuelle GA-Version (N) plus die zwei davor (N-1, N-2). Sobald eine neue Minor-Version GA wird, fällt die älteste 30 Tage später raus. Hier der Stand aus dem offiziellen AKS-Release-Kalender bei Microsoft Learn (Abruf August 2026):
Praktisch heißt das: Läuft Ihr Produktiv-Cluster im August 2026 noch auf 1.33, sind Sie bereits im Platform-Support-Fenster. Auf 1.32 oder älter bekommen Sie gar keine Kubernetes-Patches mehr. Und mit dem 1.37-GA im Oktober 2026 rutscht 1.34 auf N-3 und verliert seinerseits den vollen Support.
Nebenbei ein Termin, den viele übersehen: AKS hat den Support für Azure Linux 2.0 zum 30. November 2025 eingestellt, und ab dem 31. März 2026 werden die entsprechenden Node-Images entfernt. Wer noch Azure-Linux-2.0-Node-Pools fährt, kann diese dann nicht mehr skalieren. Das Versions-Supportende betrifft also nicht nur Kubernetes selbst, sondern auch das Betriebssystem der Nodes.
Was tatsächlich passiert, wenn der Support endet
Hier trennen sich Panik und Realität. Ein Cluster fällt nicht um, wenn der Support endet. Er läuft weiter. Aber er läuft ungeschützt. Sinnvoll ist die Unterscheidung zwischen zwei Stufen: Community-Support (N-2) und dem reduzierten Platform-Support (N-3).
Platform-Support ist also eine Galgenfrist, kein Sicherheitsnetz. Sie bekommen keine einzige Kubernetes-Sicherheitskorrektur mehr. In einem Umfeld, in dem regelmäßig kritische CVEs in kube-apiserver, containerd oder den CNI-Plugins auftauchen, ist das ein offenes Risiko.
Wird ein Cluster mehr als drei Minor-Versionen alt und bringt Sicherheitsrisiken mit, kontaktiert Azure Sie proaktiv. Reagieren Sie nicht, behält Microsoft sich vor, den Cluster eigenmächtig hochzuziehen. Ein erzwungenes Auto-Upgrade zur ungünstigsten Zeit, ohne dass Sie Ihre Workloads gegen die neuen APIs getestet haben, ist das schlechteste aller Szenarien. Genau das wollen Sie vermeiden.
Welche Version fahre ich gerade? Zwei Kommandos
Bevor Sie planen, brauchen Sie den Ist-Stand. Die aktuelle Version und den Patch-Level eines Clusters holen Sie mit der Azure CLI:
# Aktuelle Kubernetes-Version des Clusters anzeigen
az aks show
--resource-group myResourceGroup
--name myAKSCluster
--query currentKubernetesVersion -o tsvWelche Versionen in Ihrer Region überhaupt verfügbar sind, zeigt:
# Verfügbare Versionen und Upgrade-Ziele in der Region
az aks get-versions --location westeurope --output tableWenn Sie das für ein ganzes Portfolio prüfen wollen, hilft az aks list mit einem Query über alle Cluster einer Subscription. Ein Ergebnis unterhalb der untersten unterstützten Version (im August 2026 also alles unter 1.34) ist ein Handlungsauftrag, kein Hinweis.
Upgrade-Regeln: Warum Sie Versionen nicht beliebig überspringen können
Ein häufiger Irrtum: „Ich springe von 1.33 direkt auf 1.36.“ Bei regulären, nicht-LTS-Versionen geht das nicht. Sie müssen Minor-Versionen einzeln durchlaufen, also 1.33 auf 1.34, dann 1.34 auf 1.35 und so weiter. Der Grund ist die Version-Skew-Policy von Kubernetes: Control Plane und Node Pools dürfen maximal drei Minor-Versionen auseinanderliegen (seit 1.28). kubectl darf eine Minor-Version älter oder neuer sein als der kube-apiserver.
Das Muster für ein Upgrade sieht so aus:
# 1. Verfügbare Upgrade-Ziele prüfen
az aks get-upgrades
--resource-group myResourceGroup
--name myAKSCluster --output table
# 2. Auf die nächste Minor-Version upgraden (Control Plane + Node Pools)
az aks upgrade
--resource-group myResourceGroup
--name myAKSCluster
--kubernetes-version 1.34.1Wichtig ist der Schritt davor, der in keinem Kommando steckt: die Prüfung auf entfernte APIs. Jede Minor-Version wirft deprecated APIs raus. Wenn Ihre Manifeste, Helm-Charts oder Operator-CRDs noch auf einer alten API-Version hängen, brechen sie nach dem Upgrade. Azure Advisor warnt Sie zwar vor betroffenen APIs, aber verlassen Sie sich nicht darauf. Testen Sie gegen einen echten Staging-Cluster.
Unsere klare Empfehlung: Wenn Ihr Cluster mehr als drei Minor-Versionen hinter dem Support-Fenster liegt, ist ein In-Place-Upgrade oft riskanter als ein neuer Cluster mit Workload-Migration. Je grösser der Sprung, desto höher die Wahrscheinlichkeit, dass unterwegs etwas bricht. Das sagt Microsoft in den eigenen Docs so, und wir sehen es in Projekten genauso.
Long Term Support: Atempause, kein Dauerabo
Wenn Sie mit der Upgrade-Kadenz nicht mithalten können, etwa weil eine zertifizierte Anwendung eine bestimmte Version voraussetzt, gibt es Long Term Support (LTS). Damit verlängert AKS das Fenster von rund zwölf Monaten Community-Support um ein weiteres Jahr backgeporteter Sicherheitsfixes. Zusammen also etwa 24 Monate ab GA.
Der Preis ist der Haken. LTS gibt es nur im Premium-Tier, und der kostet laut Azure-Preisliste rund 0,60 USD pro Cluster und Stunde, also grob 430 USD pro Monat allein für die Control Plane, pro Cluster. Bei einem grösseren Portfolio summiert sich das schnell. Aktiviert wird LTS mit einem einzigen Update-Kommando, ohne Downtime:
# LTS auf bestehendem Cluster aktivieren
az aks update
--resource-group myResourceGroup
--name myAKSCluster
--tier premium
--k8s-support-plan AKSLongTermSupport
--auto-upgrade-channel patchUnsere Position dazu ist deutlich: LTS ist eine Atempause, kein Ersatz für Upgrades. Wer LTS als Dauerlösung nutzt, zahlt Premium-Preise dafür, technischen Stillstand zu verwalten. Sinnvoll ist es, wenn eine harte Abhängigkeit ein Upgrade für einige Monate blockiert. Als Standard-Betriebsmodell für alle Cluster ist es Geldverschwendung. Der günstigere und gesündere Weg ist ein automatisierter, regelmässiger Upgrade-Prozess, damit Sie das teure LTS-Fenster gar nicht erst brauchen.
Was IT-Leiter jetzt konkret prüfen sollten
Wenn Sie AKS im Haus haben, sind das die drei Fragen, die diese Woche auf den Tisch gehören:
- Welche Version läuft wo? Nicht raten, mit
az aks listüber alle Subscriptions prüfen. Jeder Cluster unter der untersten unterstützten Version ist ein akutes Risiko. - Wer ist verantwortlich für den Upgrade-Zyklus? Wenn die Antwort „keiner explizit“ lautet, haben Sie das eigentliche Problem gefunden. Upgrades scheitern an fehlendem Prozess, nicht an fehlendem Tooling.
- Ist der Prozess automatisiert oder Handarbeit? Manuelle Quartals-Upgrades werden vergessen. Ein sauber konfigurierter Auto-Upgrade-Channel plus Deprecated-API-Gate im CI ist die belastbarere Lösung.
Für die interne Aufstellung lohnt ein Blick auf Platform Engineering: Der Upgrade-Lebenszyklus gehört zu den Golden Paths, die eine Plattform-Mannschaft standardisiert bereitstellt, statt sie jedem Team einzeln aufzubürden. Und wenn Sicherheit der Treiber hinter dem Upgrade-Druck ist, hilft unsere 32-Punkte-Checkliste zum Härten von Kubernetes-Clustern, die Version-Aktualität als ersten Punkt führt.
Häufig gestellte Fragen
Wann läuft der Support für meine AKS-Version aus?
Jede Kubernetes-Version bekommt ab AKS-GA rund zwölf Monate Community-Support. Das konkrete Datum steht im AKS-Release-Kalender. Beispiel Stand August 2026: 1.34 endet im November 2026, 1.35 im März 2027, 1.36 im Juni 2027. Prüfen Sie Ihre laufende Version gegen den offiziellen Kalender, denn die Daten verschieben sich mit jedem neuen Release.
Was passiert, wenn ich auf einer nicht mehr unterstützten Version bleibe?
Der Cluster läuft weiter, bekommt aber keine Kubernetes-Sicherheitspatches mehr. Der AKS-SLA entfällt, und Sie können auf dieser Version keine neuen Cluster oder Node Pools mehr anlegen. Liegt der Cluster mehr als drei Minor-Versionen zurück und bringt Sicherheitsrisiken mit, kann Azure ein erzwungenes Auto-Upgrade durchführen.
Was kostet AKS Long Term Support?
LTS ist nur im Premium-Tier verfügbar. Der kostet laut Azure-Preisliste rund 0,60 USD pro Cluster und Stunde für die Control Plane, also etwa 430 USD pro Monat und Cluster. Dafür verlängert sich das Support-Fenster von rund zwölf auf etwa 24 Monate ab GA. Community-Support in Free oder Standard ist deutlich günstiger, aber eben zeitlich enger.
Kann ich mehrere Kubernetes-Versionen auf einmal überspringen?
Bei regulären Versionen nein, Sie müssen jede Minor-Version einzeln durchlaufen (etwa 1.33 auf 1.34 auf 1.35). Nur zwischen LTS-Versionen dürfen Sie Minor-Versionen überspringen, solange Version-Skew und Validierung passen. Control Plane und Node Pools dürfen maximal drei Minor-Versionen auseinanderliegen.
Was ist der Unterschied zwischen Community Support und Platform Support?
Community-Support (die drei aktuellen GA-Versionen, N-2) umfasst volle Kubernetes-Patches, Bugfixes und den AKS-SLA. Platform-Support (die eine Version darunter, N-3) ist ein Rumpf: Sie bekommen nur noch Support für Azure-Infrastruktur-Themen, keine Kubernetes-Sicherheitspatches und keinen Platform-SLA. Es ist eine Übergangsfrist, um das Upgrade nachzuholen.
Nächster Schritt
Sie wissen jetzt, welche Version stirbt und wann. Was fehlt, ist meist der verlässliche Prozess dahinter. Wenn Sie Ihr AKS-Portfolio einmal sauber gegen den Support-Kalender stellen und einen automatisierten Upgrade-Fahrplan aufsetzen wollen, sprechen Sie mit uns.
Verwandte Themen
→Kubernetes-Migration: Von VMs zu Containern
→ArgoCD auf AKS: GitOps für Azure Kubernetes
