Teilen über


Langfristiger Support für Azure Kubernetes Service (AKS)-Versionen

Die Kubernetes-Community gibt etwa alle vier Monate eine neue Unterversion heraus, wobei jede Version ein Jahr lang unterstützt wird. In Azure Kubernetes Service (AKS) wird dieses Supportfenster als „Community-Support“ bezeichnet.

AKS unterstützt Kubernetes-Versionen, die innerhalb dieses Community-Supportfensters liegen, um Fehlerbehebungen und Sicherheitsupdates aus Community-Releases zu veröffentlichen.

Während die Innovation, die mit dieser Release-Kadenz geliefert wird, Ihnen enorme Vorteile bietet, stellt sie Sie vor die Herausforderung, mit den Kubernetes-Releases auf dem Laufenden zu bleiben, was durch die Anzahl der AKS-Cluster, die Sie verwalten müssen, erschwert werden kann.

AKS-Supporttypen

Nach etwa einem Jahr läuft der Community-Support für die Kubernetes-Version aus, und Ihre AKS-Cluster sind nun gefährdet, da Fehlerbehebungen und Sicherheitsupdates nicht mehr verfügbar sind.

AKS bietet ein Jahr Community-Support und ein Jahr langfristigen Support (Long Term Support, LTS), um Sicherheitskorrekturen aus der Community Upstream in unser öffentliches Repository zu übertragen. Unsere Upstream-LTS-Arbeitsgruppe unterstützt die Community mit ihren Bemühungen, unseren Kunden ein längeres Support-Fenster zu bieten.

LTS soll Ihnen eine längere Zeitspanne für die Planung und den Test von Upgrades über einen Zeitraum von zwei Jahren ab der allgemeinen Verfügbarkeit der jeweiligen Kubernetes-Version geben.

Communityunterstützung Langfristiger Support
Einsatzgebiete 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
Supportversionen Drei allgemein verfügbare Nebenversionen Eine Kubernetes-Version (derzeit 1.27) für zwei Jahre

Langfristigen Support aktivieren

Das Aktivieren und Deaktivieren des langfristigen Supports ist eine Kombination aus dem Verschieben Ihres Clusters auf die Premium-Ebene und der expliziten Auswahl des LTS-Supportplans.

Hinweis

Obwohl es möglich ist, LTS zu aktivieren, wenn sich der Cluster im Community-Support befindet, werden Sie belastet, sobald Sie die Premium-Ebene aktivieren.

Erstellen eines Clusters mit aktiviertem LTS

az aks create --resource-group myResourceGroup --name myAKSCluster --tier premium --k8s-support-plan AKSLongTermSupport --kubernetes-version 1.27

Hinweis

Das Aktivieren und Deaktivieren von LTS ist eine Kombination aus dem Verschieben Ihres Clusters auf die Premium-Ebene sowie dem Aktivieren des langfristigen Supports. Beide müssen entweder ein- oder ausgeschaltet sein.

Aktivieren von LTS für einen vorhandenen Cluster

az aks update --resource-group myResourceGroup --name myAKSCluster --tier premium --k8s-support-plan AKSLongTermSupport

Deaktivieren von LTS für einen vorhandenen Cluster

az aks update --resource-group myResourceGroup --name myAKSCluster --tier [free|standard] --k8s-support-plan KubernetesOfficial

Langfristiger Support, Add-Ons und Features

Das AKS-Team verfolgt derzeit Add-On-Versionen, in denen Kubernetes-Community-Support vorhanden ist. Sobald eine Version den Community-Support verlässt, sind wir auf Open-Source-Projekte für verwaltete Add-Ons angewiesen, um den Support fortzusetzen. Aufgrund verschiedener externer Faktoren unterstützen einige Add-Ons und Features möglicherweise keine Kubernetes-Versionen außerhalb dieser Upstream-Community-Supportfenster.

In der folgenden Tabelle finden Sie eine Liste der Add-Ons und Features, die nicht unterstützt werden, und den Grund dafür.

Add-On / Feature Grund, warum es nicht unterstützt wird
Istio Der Istio-Supportzyklus ist kurz (sechs Monate), und es werden keine Wartungsversionen für Kubernetes 1.27 vorhanden sein
Keda Die Kompatibilität zukünftiger Versionen mit Kubernetes 1.27 kann nicht garantiert werden
Calico Erfordert eine Calico Enterprise-Vereinbarung über den Community-Support hinaus
Cillium Erfordert eine Cillium Enterprise-Vereinbarung über den Community-Support hinaus
Schlüsselverwaltungsdienst (Key Management Service, KMS) KMSv2 ersetzt KMS während dieses LTS-Zyklus
Dapr AKS-Erweiterungen werden nicht unterstützt
Application Gateway-Eingangscontroller Die Migration zu App Gateway für Container erfolgt während des LTS-Zeitraums
Bereitstellen von Open Service Mesh OSM wird eingestellt
AAD Pod Identity Veraltet anstelle von Workload Identity

Hinweis

Sie können Ihren Cluster nicht auf langfristigen Support umstellen, wenn eines dieser Add-Ons oder Features aktiviert sind.
Obwohl diese von AKS verwalteten Add-Ons von Microsoft nicht unterstützt werden, können Sie die Open Source-Versionen dieser Add-Ons auf Ihrem Cluster installieren, wenn Sie diese über den Community-Support hinaus verwenden möchten.

Wie wir über die nächste LTS-Version entscheiden

Versionen von Kubernetes LTS sind für zwei Jahre ab der allgemeinen Verfügbarkeit verfügbar. Wir kennzeichnen eine spätere Version von Kubernetes als LTS, basierend auf den folgenden Kriterien:

  • Ausreichend Zeit für Kunden, um von der vorherigen LTS-Version zur aktuellen Version zu migrieren
  • Die vorherige Version verfügt über ein zweijähriges Supportfenster

Lesen Sie die AKS-Versionshinweise, um zu erfahren, wann Sie Ihre Migration planen können.

Migrieren von LTS zu Community-Support

Die Verwendung von LTS ist eine Möglichkeit, Ihr Zeitfenster für die Planung eines Kubernetes-Versionsupgrades zu erweitern. Möglicherweise möchten Sie zu einer Version von Kubernetes migrieren, die sich im Standardsupportfenster befindet.

Um von einem LTS-aktivierten Cluster zu einer Version von Kubernetes zu wechseln, die sich im Standardsupportfenster befindet, müssen Sie LTS auf dem Cluster deaktivieren:

az aks update --resource-group myResourceGroup --name myAKSCluster --tier [free|standard] --k8s-support-plan KubernetesOfficial

Führen Sie dann ein Upgrade des Clusters auf eine spätere unterstützte Version durch:

az aks upgrade --resource-group myResourceGroup --name myAKSCluster --kubernetes-version 1.28.3

Hinweis

Hier wird Kubernetes 1.28.3 als Beispiel verwendet. Bitte überprüfen Sie den AKS-Release-Tracker auf verfügbare Kubernetes-Versionen.

Zwischen einer LTS-Version und der nächsten liegen etwa zwei Jahre. Da die Upstream-Unterstützung für die Migration von mehr als zwei Unterversionen fehlt, ist die Wahrscheinlichkeit groß, dass Ihre Anwendung von veralteten Kubernetes-APIs abhängt. Wir empfehlen Ihnen, Ihre Anwendung gründlich auf der LTS-Kubernetes-Zielversion zu testen und eine Blue/Green-Bereitstellung von einer Version zur anderen durchzuführen.

Migrieren von LTS zur nächsten LTS-Version

Die Upstream-Kubernetes-Community unterstützt einen Upgrade-Pfad für zwei Unterversionen. Der Prozess migriert die Objekte in Ihrem Kubernetes-Cluster als Teil des Upgradeprozesses und stellt einen getesteten und akkreditierten Migrationspfad bereit.

Für Kunden, die eine direkte Migration durchführen möchten, migriert der AKS-Service Ihre Steuerebene von der vorherigen LTS-Version auf die neueste und migriert anschließend Ihre Datenebene.

Um ein direktes Upgrade auf die neueste LTS-Version durchzuführen, müssen Sie eine LTS-aktivierte Kubernetes-Version als Upgradeziel angeben.

az aks upgrade --resource-group myResourceGroup --name myAKSCluster --kubernetes-version 1.32.2

Hinweis

Wenn Sie eine Programmier-/Skriptlogik zum Auflisten und Auswählen einer Nebenversion von Kubernetes verwenden, bevor Sie Cluster mit der ListKubernetesVersions-API erstellen, beachten Sie, dass die API ab Kubernetes v1.27 SupportPlan als [KubernetesOfficial, AKSLongTermSupport] zurückgibt. Bitte stellen Sie sicher, dass Sie alle Logik aktualisieren, um AKSLongTermSupport-Versionen auszuschließen, um Unterbrechungen zu vermeiden, und wählen Sie KubernetesOfficial-Supportplanversionen aus. Andernfalls, wenn LTS tatsächlich Ihr Weg vorwärts ist, abonnieren Sie zuerst die Premium-Stufe und die AKSLongTermSupport-Supportplanversionen aus der ListKubernetesVersions-API, bevor Sie Cluster erstellen.

Hinweis

Die nächste langfristige Supportversion nach 1.27 ist noch zu bestimmen. Kunden erhalten jedoch mindestens 6 Monate Überlappung zwischen 1.27 LTS- und der nächsten LTS-Version, um Upgrades zu planen.
Kubernetes 1.32.2 wird in diesem Artikel als eine Beispielversion verwendet. Überprüfen Sie den AKS-Releasetracker auf verfügbare Kubernetes-Versionen.