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.