Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Wichtig
Von der AKS-Plattform initiierte Upgrades. Ab dem 1. Juni 2027 aktualisiert AKS automatisch alle Cluster, die auf einer nicht unterstützten Kubernetes-Version verbleiben, nach Ablauf der 60-tägigen Plattform-Support-Nachfrist. Ein plattforminitiiertes Upgrade folgt nicht Ihrem Wartungsfenster, hält nicht bei der Verwendung veralteter APIs an und kann ein Pod Disruption Budget außer Kraft setzen, das einen Node-Drain blockiert, sodass Workloads unterbrochen werden können. Ersetzen Sie vor dem Upgrade-Monat APIs, die aus der Kubernetes-Zielversion entfernt wurden, und aktualisieren Sie inkompatible selbstverwaltete Add-Ons. Bewahren Sie Ihre Cluster auf einer unterstützten Kubernetes-Version auf, um ein plattformgesteuertes Upgrade zu vermeiden. Weitere Informationen finden Sie unter Vorbereiten auf plattforminitiierte Upgrades in AKS.
Die Kubernetes-Community veröffentlicht ungefähr alle vier Monate eine neue Minor-Version, und jede Version hat ein Supportfenster von einem Jahr. In Azure Kubernetes Service (AKS) wird dieses Supportfenster als Communitysupport bezeichnet.
Für Kubernetes-Versionen im Community-Support stellt AKS Fehlerbehebungen und Sicherheitsupdates aus Communityversionen bereit. Es kann schwierig sein, mit dem Kubernetes-Release-Rhythmus auf dem Laufenden zu bleiben, wenn Ihre Anwendungen komplexe Abhängigkeiten haben.
Long-Term Support (LTS) erweitert das Supportfenster, sodass Sie mehr Zeit haben, Upgrades auf neuere Kubernetes-Versionen zu planen und zu testen.
AKS-Supporttypen
Nach etwa einem Jahr fällt eine bestimmte Kubernetes-Nebenversion aus dem Community-Support, und Fehlerbehebungen und Sicherheitsupdates sind für Ihre AKS-Cluster nicht mehr verfügbar.
AKS bietet ein Jahr Community-Unterstützung, gefolgt von einem zusätzlichen Jahr Long-Term Support. Zusammen bieten die Community-Support- und LTS-Zeiträume ca. 24 Monate Gesamtunterstützung von der Allgemeinen Verfügbarkeit der Kubernetes-Version (GA). Während des LTS-Jahres portiert AKS Sicherheitsfixes aus der upstream-Community. Die Upstream-LTS-Arbeitsgruppe trägt zur Community bei und erweitert das Supportfenster.
| Communityunterstützung | Langfristiger Support | |
|---|---|---|
| Wann verwendet werden soll | Wenn Sie mit Upstream-Kubernetes-Releases Schritt halten können | Wenn Sie steuern müssen, wann von einer Version zu einer anderen migriert werden soll |
| Unterstützte Versionen | Drei neueste GA-Nebenversionen | Alle unterstützten Kubernetes-Versionen sind für LTS berechtigt. Siehe den AKS LTS-Veröffentlichungskalender. |
Langfristiger Supportpatchprozess
LTS unterstützt nur die beiden neuesten Patchversionen. Community-Support kann eine beliebige Anzahl von derzeit angebotenen Patches enthalten. AKS behält sich jedoch das Recht vor, jede Patchversion als Reaktion auf kritische Sicherheitslücken (CVEs) als veraltet zu kennzeichnen. Weitere Informationen zur Communitysupportrichtlinie finden Sie in der Kubernetes-Versionsunterstützungsrichtlinie.
Informationen zur Identifizierung der neuesten unterstützten Patchversionen finden Sie in der AKS-Versionsverfolgung.
Langfristigen Support aktivieren
Das Aktivieren von LTS erfordert das Verschieben Ihres Clusters auf die Premium-Ebene und die explizite Auswahl des LTS-Supportplans. Sie können sich jederzeit anmelden, auch wenn Ihr Cluster noch im Community-Support ist.
LTS ist auf der Premium-Stufe verfügbar. Aktuelle Preise finden Sie unter AKS-Preise.
Hinweis
Aktivieren Sie den Kanal für das automatische Patchupgrade , um Ihren Cluster auf den neuesten unterstützten Patches zu halten. LTS unterstützt nur die beiden neuesten Patchversionen für jede Minor-Version. Cluster, die keine dieser Patchversionen ausführen, werden möglicherweise nicht mehr unterstützt.
Aktivieren von LTS für einen neuen Cluster
Erstellen Sie einen neuen Cluster mit aktiviertem LTS mithilfe des Befehls az aks create. AKS verwendet die standardmäßig unterstützte Kubernetes-Version und den neuesten Patch, der in der Region verfügbar ist.
az aks create \
--resource-group <resource-group-name> \
--name <cluster-name> \
--tier premium \
--k8s-support-plan AKSLongTermSupport \
--auto-upgrade-channel patch \
--generate-ssh-keys
Der Befehl verwendet die folgenden LTS-spezifischen Parameterwerte:
-
--tier premiumlegt die Clusterverwaltungsebene auf Premium fest, die für LTS erforderlich ist. -
--k8s-support-plan AKSLongTermSupportregistriert den Cluster in LTS und stellt ein weiteres Jahr mit Sicherheitsupdates bereit. -
--auto-upgrade-channel patchaktualisiert den Cluster automatisch auf unterstützte Patchversionen, wobei die gleiche Nebenversion beibehalten wird.
Aktivieren von LTS für einen vorhandenen Cluster
Aktivieren Sie LTS für einen vorhandenen Cluster mithilfe des Befehls az aks update.
az aks update --resource-group <resource-group-name> --name <cluster-name> --tier premium --k8s-support-plan AKSLongTermSupport --auto-upgrade-channel patch
Der Befehl verwendet die folgenden LTS-spezifischen Parameterwerte:
-
--tier premiumverschiebt den Cluster auf die Premium-Clusterverwaltungsebene, die für LTS erforderlich ist. -
--k8s-support-plan AKSLongTermSupportnimmt den Cluster in LTS auf und stellt ein weiteres Jahr mit Sicherheitsupdates bereit. -
--auto-upgrade-channel patchaktualisiert den Cluster automatisch auf unterstützte Patchversionen, wobei die gleiche Nebenversion beibehalten wird.
Tipp
Um zu sehen, auf welche Kubernetes-Versionen Sie aktualisieren können, verwenden Sie den AKS-Release-Tracker oder führen Sie az aks get-upgrades --resource-group <resource-group-name> --name <cluster-name> aus.
Migrieren zur aktuellen LTS-Version
Um ein direktes Upgrade auf die neueste LTS-Version durchzuführen, geben Sie eine höhere LTS-Version an, die von AKS als Upgradeziel angeboten wird. Ein LTS-Cluster kann Nebenversionen überspringen, wenn das Upgrade die Version-Skew-Anforderungen und Validierungsprüfungen erfüllt. Weitere Informationen finden Sie unter Kubernetes-Versionsupgraderegeln.
Während eines vollständigen In-Place-Upgrades aktualisiert AKS zuerst die Steuerebene und aktualisiert dann jeden Knotenpool sequenziell. Testen Sie Ihre Workloads anhand veralteter APIs und anderer inkompatibler Änderungen zwischen den aktuellen und den Zielversionen vor dem Upgrade.
Listen Sie die Versionen auf, die AKS als Upgradeziele für Ihren Cluster mit dem
az aks get-upgradesBefehl anbietet.az aks get-upgrades --resource-group <resource-group-name> --name <cluster-name> --output tableAktualisieren Sie mithilfe des
az aks upgradeBefehls auf eine angebotene LTS-Version.az aks upgrade --resource-group <resource-group-name> --name <cluster-name> --kubernetes-version <lts-kubernetes-version>Hinweis
Alle unterstützten AKS Kubernetes-Versionen sind LTS-kompatibel. Den neuesten LTS-Kalender finden Sie im Veröffentlichungskalender von AKS Kubernetes. Informationen zum Anzeigen der verfügbaren LTS-Versionen und deren Patches nach Region finden Sie im AKS-Versionstracker.
Deaktivieren der langfristigen Unterstützung für einen vorhandenen Cluster
Um LTS für einen vorhandenen Cluster zu deaktivieren, verschieben Sie Ihren Cluster auf die Stufe „Free“ oder „Standard“ und wählen Sie den Supportplan KubernetesOfficial explizit aus
Sie können LTS deaktivieren, während die Kubernetes-Version des Clusters noch in der Community unterstützt wird. Wenn für diese Version der Community-Support endet, aktualisieren Sie den Cluster auf eine von der Community unterstützte Version, bevor Sie LTS deaktivieren. Überprüfen Sie den Veröffentlichungskalender von AKS Kubernetes , um den Supportstatus Ihrer Version zu ermitteln.
Wenn Sich Ihre aktuelle Version außerhalb des Communitysupports befindet, führen Sie die verfügbaren Upgradeziele mithilfe des
az aks get-upgradesBefehls auf.az aks get-upgrades --resource-group <resource-group-name> --name <cluster-name> --output tableFühren Sie bei Bedarf ein Upgrade des Clusters auf eine angebotene Version aus, für die Community-Support verfügbar ist, indem Sie den
az aks upgradeBefehl verwenden.az aks upgrade --resource-group <resource-group-name> --name <cluster-name> --kubernetes-version <community-supported-kubernetes-version>Deaktivieren Sie LTS mithilfe des
az aks updateBefehls. Im folgenden Beispiel wird der Cluster in den Free-Tarif verschoben und derKubernetesOfficialSupportplan ausgewählt.az aks update --resource-group <resource-group-name> --name <cluster-name> --tier free --k8s-support-plan KubernetesOfficialDer
--tier freeWert verschiebt den Cluster auf die Kostenlose Clusterverwaltungsebene und--k8s-support-plan KubernetesOfficialwechselt den Cluster von LTS in den Standard-AKS Kubernetes-Supportplan.
Überlegungen zum Add-On- und Featurelebenszyklus
LTS erweitert die Unterstützung für die Kubernetes-Version, aber Add-Ons und Features können separate Supportlebenszyklen aufweisen. Bevor Sie einen Cluster zu LTS verschieben, überprüfen Sie den Lebenszyklus und die Kubernetes-Versionskompatibilität der einzelnen Add-Ons und Features, die der Cluster verwendet.
In der folgenden Tabelle sind die aktuellen Überlegungen zum Lebenszyklus zusammengefasst:
| Add-on oder Feature | Überlegungen zum Lebenszyklus |
|---|---|
| Calico | Vergewissern Sie sich, dass Ihre Calico-Version die Kubernetes-Zielversion unterstützt, und überprüfen Sie die Tigera-Supportbedingungen für die Verwendung außerhalb des Kubernetes Community-Supports. |
| Schlüsselverwaltungsdienst (Key Management Service, KMS) | Die vorhandene KMS-Version wird jetzt als Legacy festgelegt. Informieren Sie sich für Kubernetes 1.33 und höher über die neue KMS-Datenverschlüsselung und die entsprechenden Hinweise zur Migration. Sowohl die neue Benutzeroberfläche als auch der Migrationsworkflow befinden sich in der Vorschau. |
| Dapr | Die verwaltete Dapr-Erweiterung verwendet ein rollierendes Supportfenster, das die aktuelle und die vorherige Dapr-Version umfasst. Behalten Sie die Erweiterung innerhalb des unterstützten Versionsbereichs bei. |
| Application Gateway Ingress Controller (AGIC) | AGIC bleibt verfügbar. Beginnen Sie mit dem Übergang zu Application Gateway for Containers. |
| Open Service Mesh (OSM) | Die AKS-Unterstützung für das verwaltete OSM-Add-On endet am 30. September 2027. Migrieren Sie vor diesem Datum zum Istio-Add-On . |
| Microsoft Entra podverwaltete Identität | Der Support für das verwaltete Add-On endete im September 2025. Migrieren Sie zu Microsoft Entra Workload ID. |
| Azure Vertraulich Compute SGX (ACC SGX) | Vergewissern Sie sich, dass ACC SGX die Kubernetes-Zielversion unterstützt, bevor Sie den Cluster über die Communityunterstützung hinaus verschieben. |
Plane das nächste LTS-Upgrade
AKS qualifiziert aufeinander folgende Kubernetes-Versionen für LTS und veröffentlicht für jede Version ein separates LTS-End-of-Life-Datum. Verwenden Sie den AKS LTS-Veröffentlichungskalender und die AKS-Versionsverfolgung , um eine angebotene Zielversion auszuwählen und Ihre Migration zu planen, bevor die aktuelle Version das LTS-End-of-Life-Datum erreicht.
Wenn Sie kein Upgrade durchführen, aktualisiert AKS den Cluster nach der 60-tägigen Nachfrist, die dem LtS-End-of-Life-Datum folgt, über ein plattformgesteuertes Upgrade. Der Cluster bleibt auf der LTS-Spur und wechselt zur nächsten unterstützten LTS-Version. Von der Plattform initiierte Upgrades halten sich nicht an Ihr Wartungsfenster. Daher ist ein Upgrade nach Ihrem eigenen Zeitplan die einzige Möglichkeit, die zeitliche Kontrolle zu behalten.
Häufig gestellte Fragen
Kann ich einen neuen AKS-Cluster mit einer LTS-Version erstellen, nachdem der Communitysupport beendet wurde?
Ja, Sie können einen neuen AKS-Cluster mit einer LTS-Version erstellen, nachdem der Communitysupportzeitraum dieser Version beendet wurde, wenn Sie LTS aktivieren. Die LTS-Unterstützung wird nur bis zum Ende des Lebenszyklus dieser Version fortgesetzt. Anschließend müssen Sie ein Upgrade auf die nächste unterstützte LTS-Version durchführen. Weitere Informationen finden Sie im Veröffentlichungskalender von AKS Kubernetes.
Kann ich LTS auf einer AKS-unterstützten Version aktivieren und deaktivieren, nachdem der Communitysupport beendet wurde?
Ja, Sie können den LTS-Supportplan für jede AKS-unterstützte Version aktivieren, auch nachdem der Supportzeitraum der Community beendet wurde. Sobald der Supportzeitraum der Community beendet wurde, können Sie LTS für diese Version jedoch nicht deaktivieren.
Wird ein von der Community unterstütztes AKS-Cluster nach Ablauf der Lebensdauer automatisch für LTS berechtigt?
Nein. Sie müssen LTS explizit aktivieren und den Cluster auf die Premium-Ebene verschieben.
Registriert ein vom Plattform initiiertes Upgrade meinen Cluster in LTS?
Nein. AKS registriert niemals einen Cluster in LTS in Ihrem Auftrag und ändert niemals Ihre Abrechnungsstufe. Ein plattformgesteuertes Upgrade behält den Cluster in seiner aktuellen Supportebene bei: Ein Community-Support-Cluster wechselt zur niedrigsten unterstützten Nebenversion der Community, und ein LTS-Cluster wechselt zur entsprechenden LTS-Version.
Was geschieht, wenn die LTS-Version meines Clusters das Ende der Lebensdauer erreicht und ich kein Upgrade durchführe?
AKS aktualisiert den Cluster auf die nächste unterstützte LTS-Version nach der 60-tägigen Nachfrist, die dem LTS-End-of-Life-Datum folgt. Der Cluster wird nicht auf eine von der Community unterstützte Version herabgestuft. Den Monat für Ihre Version finden Sie im AKS LTS-Versionskalender. Weitere Informationen finden Sie unter Plattform-initiierte Upgrades.
Ist jede AKS-Version für den langfristigen Support berechtigt?
Yes. Alle unterstützten Kubernetes-Versionen sind für LTS berechtigt.
Wie sieht das Preismodell für LTS aus?
LTS wird auf der Premium-Stufe angeboten. Aktuelle Preise finden Sie unter Premium-Tarife.
Stört die Aktivierung von LTS Workloads?
Nein. Es ist eine reine Konfigurationsänderung; es werden keine Knoten neu aufgesetzt oder Workloads unterbrochen, sodass keine Ausfallzeiten erwartet werden.