Unterstützte Kubernetes-Versionen in Azure Kubernetes Service (AKS)

Die Kubernetes-Community veröffentlicht etwa alle vier Monate Nebenversionen .

Nebenversionsreleases enthalten neue Features und Verbesserungen. Patchreleases kommen häufiger vor (manchmal wöchentlich) und sind für wichtige Fehlerbehebungen in einer Nebenversion gedacht. Patchreleases enthalten Fixes für Sicherheitsrisiken oder schwer wiegende Fehler.

Kubernetes-Versionen

Kubernetes verwendet als Standardversionierungsschema für jede Version die semantische Versionierung:

[major].[minor].[patch]

Jede Zahl in der Version spiegelt die Kompatibilität mit früheren Versionen wider:

• Hauptversionen: Führen Sie inkompatible API-Änderungen ein, oder unterbrechen Sie die Abwärtskompatibilität.
• Nebenversionen: Neue Features hinzufügen. Stabile APIs bleiben in der Regel kompatibel, veraltete APIs und Features können jedoch gemäß der Kubernetes-Deprecation-Richtlinie entfernt werden.
• Patchversionen: Schließen Sie abwärtskompatible Fehlerkorrekturen ein.

Verwenden Sie immer die neueste Patchversion für Ihre aktuelle Nebenversion. Wenn ein späterer Patch für Ihre Nebenversion verfügbar ist, aktualisieren Sie so bald wie möglich, um sicherzustellen, dass Ihr Cluster vollständig gepatcht und unterstützt wird.

AKS Kubernetes-Releasekalender und bevorstehende Versionen

Überprüfen Sie den AKS Kubernetes-Veröffentlichungskalender auf bevorstehende Versionen. Um Echtzeitupdates zum Versionsstatus der Region und zu Versionshinweisen zu erhalten, besuchen Sie die Webseite zum AKS-Releasestatus. Weitere Informationen zur Release-Status-Webseite finden Sie unter AKS-Release-Tracker.

Den Verlauf der letzten Releases finden Sie unter Kubernetes-Geschichte.

LTS-Versionen

Sie müssen den langfristigen Support (LONG-Term Support, LTS) aktivieren, um erweiterten Support zu erhalten. Weitere Informationen finden Sie unter Aktivieren des langfristigen Supports.

AKS Kubernetes-Release-Zeitplan im Gantt-Diagramm

Das folgende Gantt-Diagramm zeigt die aktuellen Versionen an:

Breaking Changes der AKS-Komponenten nach Version

Beachten Sie die folgenden wichtigen Änderungen, bevor Sie auf eine der verfügbaren Nebenversionen aktualisieren:

Kubernetes 1.36

Kubernetes 1.35

Kubernetes 1.34

Kubernetes 1.33

Kubernetes 1.32

Kubernetes 1.31

Kubernetes 1.30

Alias-Nebenversion in AKS

Sie können einen AKS-Cluster erstellen, ohne eine Patchversion anzugeben. Beim Erstellen eines Clusters ohne Angabe eines Patches führt der Cluster den aktuellen GA-Patch der Nebenversion aus. Wenn Sie Ihre Patch-Version innerhalb derselben Unterversion aktualisieren möchten, verwenden Sie autoupgrade.

Führen Sie den Befehl az aks show --resource-group myResourceGroup --name myAKSCluster aus, um zu sehen, auf welchem Patch Sie sich befinden. In der Ausgabe zeigt die currentKubernetesVersion Eigenschaft die gesamte Kubernetes-Version an. Beispiel:

{
 "apiServerAccessProfile": null,
  "autoScalerProfile": null,
  "autoUpgradeProfile": null,
  "azurePortalFqdn": "myaksclust-myresourcegroup.portal.hcp.eastus.azmk8s.io",
  "currentKubernetesVersion": "<major>.<minor>.<patch>",
}

Richtlinie zur Unterstützung der Kubernetes-Version

In AKS wird eine allgemein verfügbare (Generally Available, GA) Version als eine Version definiert, die in allen Regionen verfügbar und in allen SLO- oder SLA-Messungen aktiviert ist. AKS unterstützt drei allgemein verfügbare Nebenversionen von Kubernetes:

• Die neueste GA-Version (N).
• Die beiden vorherigen Nebenversionen (N-1 und N-2).
  • Jede unterstützte Nebenversion kann eine beliebige Anzahl von Patches zu einem bestimmten Zeitpunkt unterstützen. AKS behält sich das Recht vor, Patches abzukündigen, wenn eine kritische CVE- oder Sicherheitslücke erkannt wird. Informationen zur Verfügbarkeit von Patches und jeglicher Ad-hoc-Deaktivierung finden Sie in den Versionshinweisen und besuchen Sie die AKS-Versionsstatus-Webseite.

AKS unterstützt möglicherweise auch Vorschauversionen, die explizit als solche gekennzeichnet sind und den Nutzungsbedingungen für Vorschauversionen unterliegen.

AKS bietet Plattformunterstützung nur für eine GA-Nebenversion von Kubernetes nach den regulären unterstützten Versionen. Das Plattformunterstützungsfenster von Kubernetes-Versionen auf AKS wird als N-3 bezeichnet. Weitere Informationen finden Sie in den Plattformunterstützungsrichtlinien.

Das unterstützte Fenster von Kubernetes-Nebenversionen auf AKS wird als N-2 bezeichnet, wobei N auf die neueste Version verweist, was bedeutet, dass auch zwei vorherige Nebenversionen unterstützt werden.

An dem Tag, an dem AKS die Version 1.29 einführt, wird Support für die folgenden Versionen bereitgestellt:

Bei Einführung einer neuen Nebenversion wird die älteste Nebenversion als veraltet gekennzeichnet und entfernt. Angenommen, die aktuelle Liste der unterstützten Nebenversionen ist 1.29, 1.28 und 1.27. Wenn AKS die Version 1.30 veröffentlicht, wird nach 30 Tagen der Support für alle Versionen vom Typ 1.27 eingestellt.

AKS unterstützt möglicherweise eine beliebige Anzahl an Patches basierend auf der Verfügbarkeit eines Upstream-Community-Releases für eine bestimmte Nebenversion. AKS behält sich das Recht vor, diese Patches aufgrund eines CVE oder eines potenziellen Fehlerproblems jederzeit zu verwerfen. Wir empfehlen Ihnen, den neuesten Patch für eine Nebenversion zu verwenden.

Plattformunterstützungsrichtlinie

Die Plattformunterstützungsrichtlinie ist ein reduzierter Supportplan für bestimmte nicht unterstützte Kubernetes-Versionen. Während der Plattformunterstützung erhalten Kunden nur Unterstützung von Microsoft für Probleme im Zusammenhang mit der AKS-/Azure-Plattform. Für Probleme im Zusammenhang mit Kubernetes-Funktionen und -Komponenten gibt es keine Unterstützung.

Plattformunterstützungsrichtlinie gilt für Cluster in einer N-3-Version (wobei N die neueste unterstützte AKS GA-Nebenversion ist), bevor der Cluster auf N-4 fällt. Beispielsweise wird Kubernetes v1.26 für Plattformunterstützung berücksichtigt, wenn v1.29 die neueste GA-Version ist. Angenommen, Sie führen eine N-2-Version aus. Sobald die Version N-3 wird, endet sie auch ihren offiziellen Support, und Sie treten in die Plattformsupportrichtlinie ein.

AKS basiert auf den Versionen und Patches von Kubernetes, einem Open-Source-Projekt, das nur ein Gleitfenster von drei Nebenversionen unterstützt. AKS kann nur vollständige Unterstützung garantieren, wenn diese Versionen im Upstream gepflegt werden. Da im Upstream keine Patches mehr erstellt werden, kann AKS diese Versionen entweder ungepatcht lassen oder forken. Aufgrund dieser Einschränkung gilt die Plattformunterstützung nicht für Elemente, die auf einem Kubernetes-Upstream basieren.

Die folgende Tabelle enthält Supportrichtlinien für community-Support im Vergleich zum Plattformsupport:

Unterstützte kubectl-Versionen

Sie können eine kubectl Version verwenden, die eine Nebenversion älter oder neuer als Ihre kube-apiserver-Version ist. Weitere Informationen finden Sie in der Kubernetes-Supportrichtlinie für Kubectl.

Wenn Ihr kube-apiserver sich beispielsweise bei 1.28 befindet, können Sie die Versionen von 1.27 bis 1.29 von kubectl verwenden.

Um die neueste Version zu installieren oder zu aktualisieren kubectl, verwenden Sie den Befehl, der auf Ihrem bevorzugten Tool basiert.

az aks install-cli

Install-AzAksKubectl -Version latest

Langfristiger Support (Long Term Support, LTS)

AKS bietet ein Jahr Community-Support und ein Jahr Long Term Support (LTS), einschließlich backported Security Fixes von der Upstream-Community. Unsere Upstream-LTS-Arbeitsgruppe unterstützt die Community mit ihren Bemühungen, unseren Kunden ein längeres Support-Fenster zu bieten.

Weitere Informationen zu LTS finden Sie unter Long Term Support for Azure Kubernetes Service (AKS).For more information on LTS, see Long term support for Azure Kubernetes Service (AKS).

Veröffentlichen und Markieren als veraltet

Informationen zu kommenden Versionen und Abkündigungen finden Sie im AKS-Kubernetes-Releasekalender.

Bei neuen Nebenversionen von Kubernetes:

• AKS kündigt in den AKS-Versionshinweisen mindestens 30 Tage vor der Entfernung neue Versionsveröffentlichungstermine und die Außerkraftsetzung alter Versionen an.

• AKS verwendet Azure Advisor, um Sie zu benachrichtigen, wenn eine neue Version aufgrund veralteter APIs Probleme in Ihrem Cluster verursachen könnte. Azure Advisor benachrichtigt Sie auch, wenn Sie nicht mehr unterstützt werden.

• AKS veröffentlicht eine Benachrichtigung zur Dienstintegrität, die für alle Benutzer mit Zugriff auf AKS und das Portal verfügbar ist. Außerdem sendet AKS eine E-Mail an die Abonnementadministratoren mit den geplanten Daten für die Entfernung von Versionen.

  Note

  Um Ihre Abonnementadministratoren anzuzeigen oder zu ändern, finden Sie unter Verwalten von Azure-Abonnements Informationen.

• Sie haben nach der Entfernung einer Version 30 Tage lang Zeit, ein Upgrade auf eine unterstützte Nebenversion durchzuführen, um weiterhin Support zu erhalten.

Bei neuen Patchversionen von Kubernetes:

• Da Patchversionen dringend sind, können sie in den Dienst eingefügt werden, sobald sie verfügbar sind. Sobald sie verfügbar sind, haben Patches einen Mindestlebenszyklus von zwei Monaten.
• In der Regel macht AKS die Veröffentlichung neuer Patchversionen nicht allgemein bekannt. AKS überwacht und überprüft allerdings verfügbare CVE-Patches, um diese möglichst schnell in AKS zu unterstützen. Wenn ein kritischer Patch gefunden wird oder eine Benutzeraktion erforderlich ist, benachrichtigt AKS Sie, damit Sie ein Upgrade auf den neu verfügbaren Patch ausführen.
• Sie haben ab der Entfernung eines Patchreleases von AKS 30 Tage lang Zeit, ein Upgrade auf einen unterstützten Patch auszuführen und weiterhin Support zu erhalten. Sie können jedoch keine Cluster oder Knotenpools mehr erstellen, nachdem die Version veraltet/entfernt wurde.

Ausnahmen von den Richtlinien für unterstützte Versionen

AKS behält sich das Recht vor, ohne Vorankündigung neue Versionen hinzuzufügen/bestehende zu entfernen, wenn in diesen kritische, die Produktion einschränkende Fehler oder Sicherheitsprobleme gefunden werden.

Bestimmte Patchreleases können übersprungen oder Rollouts je nach Schweregrad des Fehlers oder Sicherheitsproblems vorgezogen werden.

Versionen für Azure-Portal and CLI

Wenn Sie einen AKS-Cluster mithilfe von Azure Portal, Azure CLI oder Azure PowerShell bereitstellen, wird der Cluster standardmäßig auf die Nebenversion N-1 und den neuesten Patch festgelegt.

Um herauszufinden, welche Versionen derzeit für Ihr Abonnement und Ihre Region verfügbar sind, verwenden Sie den Befehl basierend auf Ihrem bevorzugten Tool:

# The following example lists the available Kubernetes versions for the EastUS region:

az aks get-versions --location eastus --output table

# The following example lists the available Kubernetes versions for the EastUS region:

Get-AzAksVersion -Location eastus

Häufig gestellte Fragen (FAQ)

Wie benachrichtigt mich Microsoft, wenn neue Kubernetes-Versionen vorliegen?

Das AKS-Team kündigt neue Kubernetes-Versionsveröffentlichungsdaten in unserer Dokumentation, auf GitHub und per E-Mail an Abonnementadministratoren mit Clustern am Ende des Supports an. AKS verwendet auch Azure Advisor, um Sie innerhalb des Azure-Portals zu benachrichtigen, wenn Ihre Version nicht mehr unterstützt wird, und Sie über veraltete APIs zu informieren, die sich auf Ihre Anwendung oder Ihren Entwicklungsprozess auswirken kann.

Wie oft muss ich damit rechnen, ein Upgrade auf Kubernetes-Versionen durchzuführen, um weiterhin Unterstützung zu erhalten?

Ab Kubernetes 1.19 erweiterte die Open Source-Community den Support um ein Jahr. AKS führt einen Commit aus, um Patches und Unterstützung zu ermöglichen, die den Upstreamzusagen entsprechen. Für AKS-Cluster auf Version 1.19 und höher können Sie mindestens einmal pro Jahr ein Upgrade durchführen, um auf einer unterstützten Version zu bleiben.

Was geschieht, wenn Sie ein Upgrade eines Kubernetes-Clusters mit einer Nebenversion durchführt, die nicht unterstützt wird?

Wenn Ihre Version gemäß der Liste der unterstützten Kubernetes-Versionen nicht unterstützt wird, müssen Sie ein Upgrade durchführen. Sie können ein Upgrade von nicht unterstützten Versionen auf unterstützte Versionen durchführen. Beispiel:

• Wenn die niedrigste unterstützte AKS-Nebenversion 1.33 ist und Sie Version 1.32 oder älter verwenden, sind Sie nicht mehr im Support.
• Wenn Sie ein Upgrade von 1.32 auf 1.33 oder höher erfolgreich durchführen, befinden Sie sich wieder in den Supportrichtlinien.

Downgrades oder Rollbacks zu einer nicht unterstützten Version werden nicht unterstützt. Darüber hinaus ist die Clusterversion von der niedrigsten unterstützten Version entfernt, desto höher ist die Wahrscheinlichkeit von Upgradeproblemen. In diesem Fall wäre das Erstellen eines neuen Clusters und die Migration der Workloads der bessere Ansatz.

Was bedeutet es, "außerhalb des Supports" zu sein?

"Außerhalb der Unterstützung" bedeutet:

• Die Version, die Sie ausführen, befindet sich nicht auf der Liste der unterstützten Versionen.
• Wenn Sie Support anfordern, werden Sie aufgefordert, für den Cluster ein Upgrade auf eine unterstützte Version vorzunehmen, sofern Sie sich nicht mehr innerhalb des 30-Tage-Zeitraums befinden, der beginnt, nachdem eine Version als veraltet gekennzeichnet wurde.

Des Weiteren stellt AKS für Cluster mit Versionen, die nicht in der Liste der unterstützten Versionen aufgeführt sind, weder Laufzeitgarantien noch sonstige Garantien bereit.

Kann man für immer auf einer Kubernetes-Version bleiben?

Wenn ein Cluster nicht mehr als drei Nebenversionen unterstützt und Sicherheitsrisiken birgt, kontaktiert Azure Sie proaktiv. Sie empfehlen Ihnen, Ihr Cluster zu aktualisieren. Wenn Sie keine weiteren Maßnahmen ergreifen, behält Azure sich das Recht vor, automatisch ein Upgrade Ihres Clusters in Ihrem Namen auszuführen.

Was passiert, wenn Sie einen Kubernetes-Cluster mit einer nicht unterstützten Nebenversion skalieren?

Bei Nebenversionen, die von AKS nicht unterstützt werden, sollte das Ab- oder Aufskalieren weiterhin einwandfrei funktionieren. Da es keine Garantien für die Dienstqualität gibt, sollten Sie ein Upgrade durchführen, damit für Ihren Cluster wieder Support gewährt wird.

Welche Version wird von der Steuerungsebene unterstützt, wenn der Knotenpool keine der unterstützten AKS-Versionen verwendet?

Die Kontrollebene und alle Knotenpools müssen innerhalb des unterstützten Bereichs zulässiger Versionsabweichungen bleiben. Ab Kubernetes 1.28 kann die Control Plane den Knotenpools um bis zu drei Minor-Versionen voraus sein. Ausführliche Informationen finden Sie in den Kubernetes-Versionsupgraderegeln.

Was ist der zulässige Unterschied in den Versionen zwischen der Kontrollebene und den Knotenpools?

Die Versionsabweichungsrichtlinie ermöglicht jetzt einen Unterschied von bis zu drei Versionen zwischen Kontrollebene und Agentpools. AKS folgt dieser Änderung der Richtlinie zur Versionsabweichung ab Version 1.28.

Kann ich während eines Clusterupgrades mehrere AKS-Versionen überspringen?

Ja, In einigen Fällen können Sie Nebenversionen überspringen. Wenn Sie die Control Plane jedoch unabhängig von den Knotenpools aktualisieren, müssen Sie die Kubernetes-Richtlinien zur Versionsabweichung einhalten. Die Kubernetes-Versions-Skew-Richtlinie unterstützt derzeit nur N-3, sodass sich die Kontrollebene und die Agentpools innerhalb von N-3 voneinander befinden müssen.

• LTS: Eine Version mit aktiviertem AKS Long-Term Supportplan. Siehe LTS-Versionen.
• Nicht mehr unterstützte LTS-Version: Eine LTS-aktivierte Version, deren LTS-End-of-Life-Datum in der Tabelle LTS versions überschritten ist.
• Unterstützt nicht LTS: Eine Version, die nicht LTS ist, aber weiterhin im AKS Kubernetes-Veröffentlichungskalender unterstützt wird.
• Nicht unterstützte Nicht-LTS: Eine Version, die nicht LTS ist und nicht mehr im AKS Kubernetes-Veröffentlichungskalender unterstützt wird.

Beispiele:

• Wenn Ihr Cluster auf 1.29 LTS festgelegt ist und Sie zu 1.32 LTS wechseln möchten, können Sie mehrere Nebenversionen überspringen, solange 1.32 LTS weiterhin von AKS angeboten wird und das Upgrade Versionsverknügungen und Überprüfungsprüfungen erfüllt.
• Wenn Ihr Cluster auf 1.28 non-LTS ausgeführt wird, können Sie über den nicht unterstützten Wiederherstellungspfad auf AKS LTS 1.30 LTS upgraden, sofern die Zielversion von AKS aufgeführt ist, die Validierungsprüfungen besteht und Sie ein vollständiges Clusterupgrade durchführen statt control-plane-only.
• Wenn Ihr Cluster nicht von LTS 1.33 unterstützt wird und Sie zu unterstützten Nicht-LTS 1.35 wechseln möchten, können Sie nicht direkt von 1.33 auf 1.35 überspringen. Sie müssen jeweils eine Nebenversion aktualisieren, z. B. 1.33 auf 1.34 und dann 1.34 auf 1.35.

In der vorhergehenden Tabelle gibt Unsupported recovery path an, dass der Upgradepfad auf eine Weise ausgeführt wird, deren sichere Ausführung nicht garantiert werden kann und die daher als nicht unterstützt gilt. AKS ermöglicht es, das Upgrade fortzusetzen, wird aber nicht unterstützt und kann Risiken tragen.

Um den richtigen Pfad auszuwählen, überprüfen Sie die verfügbaren Ziele durch Ausführen az aks get-upgrades --resource-group <resource-group-name> --name <cluster-name>. Überprüfen Sie die vorstehende Tabelle, und berücksichtigen Sie dann das Risiko eines Upgrades im Vergleich zum Erneuten Erstellen des Clusters und der Migration von Workloads.

Kann ich während des Plattformunterstützungsfensters einen neuen 1.xx.x-Cluster erstellen?

Nein, die Erstellung neuer Cluster ist während des Plattformsupportzeitraums nicht möglich.

Ich bin auf einer aktuell veralteten Version, die nicht plattformübergreifend unterstützt wird. Kann ich weiterhin neue Knotenpools hinzufügen oder ein Upgrade durchführen?

Ja, Sie können Agentpools hinzufügen, solange sie mit der Version der Steuerebene kompatibel sind.

Verwandte Inhalte

Informationen zu AKS-Clusterupgrades finden Sie unter:

• Durchführen eines Upgrades für einen Azure Kubernetes Service-Cluster (AKS)
• Upgrade mehrerer AKS-Cluster über Azure Kubernetes Fleet Manager