Unterstützte Kubernetes-Versionen in Azure Operator Nexus Kubernetes Service
Dieses Dokument bietet einen Überblick über das Versionsverwaltungsschema, das für den Operator Nexus Kubernetes-Dienst verwendet wird, einschließlich der unterstützten Kubernetes-Versionen. Es erklärt die Unterschiede zwischen Haupt-, Neben- und Patch-Versionen und bietet eine Anleitung zum Upgrade von Kubernetes-Versionen und wie das Upgrade abläuft. Das Dokument behandelt auch den Lebenszyklus der Versionsunterstützung und das Ende der Lebensdauer (EOL) für jede Unterversion von Kubernetes.
Die Kubernetes-Community veröffentlicht etwa alle drei Monate Nebenversionen. Ab Version 1.19 hat die Kubernetes-Community das Unterstützungsfenster für die einzelnen Versionen von neun Monaten auf ein Jahr erhöht.
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]
Examples:
1.24.7
1.25.4
Für jede Zahl in der Version gilt, dass allgemeine Kompatibilität mit der vorherigen Version besteht:
- Hauptversionsnummern ändern sich, wenn in der API möglicherweise Breaking Changes eingeführt werden.
- Nebenversionsnummern ändern sich, wenn Updates an der Funktionalität vorgenommen werden, die zu den anderen Nebenreleases abwärtskompatibel sind.
- Patchversionsnummern ändern sich, wenn abwärtskompatible Fehlerbehebungen vorgenommen werden.
Wir empfehlen Ihnen dringend, sich über die neuesten verfügbaren Patches auf dem Laufenden zu halten. Wenn sich Ihr Produktionscluster beispielsweise auf 1.25.4 befindet, ist 1.25.6 die neueste verfügbare Patchversion für die 1.25-Serie. Sie sollten so bald wie möglich ein Upgrade auf 1.25.6 durchführen, um sicherzustellen, dass Ihr Cluster vollständig gepatcht ist und unterstützt wird. Weitere Details zum Upgrade Ihres Clusters finden Sie in der Dokumentation Upgrade von Kubernetes-Versionen.
Releasekalender für Nexus Kubernetes
Sehen Sie sich die bevorstehenden Version-Releases im Nexus Kubernetes-Release-Kalender an.
Hinweis
Lesen Sie mehr zu unserer Supportrichtlinie für die Kubernetes-Versionsverwaltung.
Den Verlauf der letzten Releases finden Sie unter Kubernetes-Geschichte.
| Kubernetes-Version | Nexus (GA) | Ende der Lebensdauer | Erweiterte Verfügbarkeit |
|---|---|---|---|
| 1,25 | Juni 2023 | Dez. 2023 | Bis Ende Oktober 2024 |
| 1.26 | Sept. 2023 | März 2024 | Bis Ende März 2025 |
| 1.27* | Sept. 2023 | Juli 2024, LTS bis Juli 2025 | Nicht verfügbar |
| 1.28 | Nov. 2023 | Oktober 2024 | Bis Ende Oktober 2025 |
| 1.29 | August 2024 | Februar 2025 | Bis Ende Februar 2026 |
| 1.30* | Oktober 2024 | Juli 2025, LTS bis Juli 2026 | Nicht verfügbar |
* Gibt an, dass die Version für den langfristigen Support bestimmt ist.
Versionskomponenten des Nexus Kubernetes-Diensts
Eine Version des Operator Nexus Kubernetes-Diensts besteht aus zwei einzelnen Komponenten, die in einer einzigen Darstellung kombiniert werden:
- Der Kubernetes-Version. Zum Beispiel: Die Version, die Sie in Operator Nexus bereitstellen, ist Version 1.25.4 von Kubernetes. Diese Pakete, einschließlich aller Patch-Versionen, die von Operator Nexus unterstützt werden, werden von Azure AKS bereitgestellt. Weitere Informationen zu Azure AKS-Versionen finden Sie unter Unterstützte Kubernetes-Versionen in Azure Kubernetes Service (AKS).
- Das Versionspaket, das die Funktionen (Add-Ons) und das Betriebssystem-Image, das von den Knoten im Operator Nexus Kubernetes-Cluster verwendet wird, in einer einzigen Zahl zusammenfasst. Beispiel: „2“.
Die Kombination dieser Werte wird in der API als einzelne Kubernetes-Version dargestellt. Beispiel:
1.25.4-2oder die alternativ unterstützte „v“-Schreibweise:v1.25.4-2.
Versionspakete
Durch die Erweiterung der Version von Kubernetes um einen sekundären Wert für die Patch-Version, das Versionspaket, kann der Dienst Operator Nexus Kubernetes Fälle berücksichtigen, in denen die Bereitstellung geändert wird, um zusätzliche betriebssystembezogene Aktualisierungen aufzunehmen. Solche Updates können unter anderem sein: aktualisierte Betriebssystem-Images, Patch-Versionen für Funktionen (Add-Ons) und so weiter. Versionspakete sind immer abwärtskompatibel mit früheren Versionspaketen innerhalb der gleichen Patch-Version, zum Beispiel ist 1.25.4-2 abwärtskompatibel mit 1.25.4-1.
Änderungen an der Konfiguration eines bereitgestellten Operator Nexus Kubernetes-Clusters sollten nur im Rahmen eines Nebenversionsupgrades von Kubernetes vorgenommen werden, nicht während eines Patchversionsupgrades. Beispiele für Konfigurationsänderungen, die während des Nebenversionsupgrades vorgenommen werden können, sind:
- Ändern der Konfiguration des kube-proxy von iptables auf ipvs
- Ändern der CNI von einem Produkt zu einem anderen
Wenn wir diese Prinzipien befolgen, wird es einfacher, den Prozess des Wechsels zwischen verschiedenen Versionen von Kubernetes-Clustern, die vom Operator Nexus Kubernetes Service angeboten werden, vorherzusagen und zu verwalten.
Wir können problemlos von jedem kleinen Update einer Kubernetes-Version auf jedes kleine Update der nächsten Version upgraden, sodass Sie flexibel bleiben. Zum Beispiel wäre ein Upgrade von 1.24.1-x auf 1.25.4-x erlaubt, unabhängig vom Vorhandensein einer Zwischenversion 1.24.2-x.
Komponentenversion und Breaking Changes
Beachten Sie wichtige Änderungen, die vorgenommen werden müssen, bevor Sie ein Upgrade auf eine der folgenden verfügbaren Nebenversionen durchführen.
| Kubernetes-Version | Versionspaket | Komponenten | Betriebssystemkomponenten | Aktuelle Änderungen | Hinweise |
|---|---|---|---|---|---|
| 1.30.3 | 1 | Calico v3.27.4 metrics-server v0.7.2 Multus v4.0.2 azure-arc-servers v1.1.0 CoreDNS v1.9.4 etcd v3.5.15 sriov-dp v3.7.0 Csi-nfs v4.9.0 csi-volume v0.1.0 metallb v0.14.5-3 |
Azure Linux 3.0.20240824 | Keine Breaking Changes | |
| 1.29.7 | 3 | Calico v3.28.2 metrics-server v0.7.2 Multus v4.0.2 azure-arc-servers v1.1.0 CoreDNS v1.9.4 etcd v3.5.15 sriov-dp v3.7.0 Csi-nfs v4.9.0 csi-volume v0.1.0 metallb v0.14.5-3 |
Azure Linux 2.0.20240731 | Keine Breaking Changes | Erweiterte verfügbare Patches: 1.29.4-1 |
| 1.29.7 | 2 | Calico v3.27.4 metrics-server v0.7.1 Multus v4.0.2 azure-arc-servers v1.1.0 CoreDNS v1.9.4 etcd v3.5.15 sriov-dp v3.5.1 Csi-nfs v4.8.0 csi-volume v0.1.0 metallb v0.14.5-3 |
Azure Linux 2.0.20240731 | Keine Breaking Changes | |
| 1.29.6 | 4 | Calico v3.28.2 metrics-server v0.7.2 Multus v4.0.2 azure-arc-servers v1.1.0 CoreDNS v1.9.4 etcd v3.5.15 sriov-dp v3.7.0 Csi-nfs v4.9.0 csi-volume v0.1.0 metallb v0.14.5-3 |
Azure Linux 2.0.20240731 | Keine Breaking Changes | |
| 1.29.6 | 3 | Calico v3.27.4 metrics-server v0.7.1 Multus v4.0.2 azure-arc-servers v1.1.0 CoreDNS v1.9.4 etcd v3.5.15 sriov-dp v3.5.1 Csi-nfs v4.8.0 csi-volume v0.1.0 metallb v0.14.5-3 |
Azure Linux 2.0.20240731 | Keine Breaking Changes | |
| 1.28.12 | 3 | Calico v3.28.2 metrics-server v0.7.2 Multus v4.0.2 azure-arc-servers v1.1.0 CoreDNS v1.9.4 etcd v3.5.15 sriov-dp v3.7.0 Csi-nfs v4.9.0 csi-volume v0.1.0 metallb v0.14.5-3 |
Azure Linux 2.0.20240731 | Keine Breaking Changes | Erweiterte verfügbare Patches: 1.28.9-2, 1.28.0-6 |
| 1.28.12 | 2 | Calico v3.27.4 metrics-server v0.7.1 Multus v4.0.2 azure-arc-servers v1.1.0 CoreDNS v1.9.4 etcd v3.5.15 sriov-dp v3.5.1 Csi-nfs v4.8.0 csi-volume v0.1.0 metallb v0.14.5-3 |
Azure Linux 2.0.20240731 | Keine Breaking Changes | |
| 1.28.11 | 4 | Calico v3.28.2 metrics-server v0.7.2 Multus v4.0.2 azure-arc-servers v1.1.0 CoreDNS v1.9.4 etcd v3.5.15 sriov-dp v3.7.0 Csi-nfs v4.9.0 csi-volume v0.1.0 metallb v0.14.5-3 |
Azure Linux 2.0.20240731 | Keine Breaking Changes | |
| 1.28.11 | 3 | Calico v3.27.4 metrics-server v0.7.1 Multus v4.0.2 azure-arc-servers v1.1.0 CoreDNS v1.9.4 etcd v3.5.15 sriov-dp v3.5.1 Csi-nfs v4.8.0 csi-volume v0.1.0 metallb v0.14.5-3 |
Azure Linux 2.0.20240731 | Keine Breaking Changes | |
| 1.27.13 | 3 | Calico v3.28.2 metrics-server v0.7.2 Multus v4.0.2 azure-arc-servers v1.1.0 CoreDNS v1.9.4 etcd v3.5.15 sriov-dp v3.7.0 Csi-nfs v4.9.0 csi-volume v0.1.0 metallb v0.14.5-3 |
Azure Linux 2.0.20240425 | Keine Breaking Changes | Erweiterte verfügbare Patches: 1.27.3-7, 1.27.1-8 |
| 1.27.13 | 2 | Calico v3.27.4 metrics-server v0.7.1 Multus v4.0.2 azure-arc-servers v1.1.0 CoreDNS v1.9.4 etcd v3.5.15 sriov-dp v3.5.1 Csi-nfs v4.8.0 csi-volume v0.1.0 metallb v0.14.5-3 |
Azure Linux 2.0.20240425 | Keine Breaking Changes | |
| 1.27.9 | 5 | Calico v3.28.2 metrics-server v0.7.2 Multus v4.0.2 azure-arc-servers v1.1.0 CoreDNS v1.9.4 etcd v3.5.15 sriov-dp v3.7.0 Csi-nfs v4.9.0 csi-volume v0.1.0 metallb v0.14.5-3 |
Azure Linux 2.0.20240425 | Keine Breaking Changes | |
| 1.27.9 | 4 | Calico v3.27.4 metrics-server v0.7.2 Multus v4.0.2 azure-arc-servers v1.1.0 CoreDNS v1.9.4 etcd v3.5.15 sriov-dp v3.5.1 Csi-nfs v4.8.0 csi-volume v0.1.0 metallb v0.14.5-3 |
Azure Linux 2.0.20240425 | Keine Breaking Changes | |
| 1.26.12 | 4 | Calico v3.27.4 metrics-server v0.7.1 Multus v4.0.2 azure-arc-servers v1.1.0 CoreDNS v1.9.4 etcd v3.5.15 sriov-dp v3.5.1 Csi-nfs v4.8.0 csi-volume v0.1.0 metallb v0.14.5-3 |
Azure Linux 2.0.20240425 | Keine Breaking Changes | |
| 1.26.12 | 3 | Calico v3.27.4 metrics-server v0.7.1 Multus v4.0.2 azure-arc-servers v1.1.0 CoreDNS v1.9.4 etcd v3.5.15 sriov-dp v3.5.1 Csi-nfs v4.8.0 csi-volume v0.1.0 metallb v0.14.5-3 |
Azure Linux 2.0.20240425 | Keine Breaking Changes | |
| 1.26.6 | 6 | Calico v3.27.4 metrics-server v0.7.1 Multus v4.0.2 azure-arc-servers v1.1.0 CoreDNS v1.9.4 etcd v3.5.15 sriov-dp v3.5.1 Csi-nfs v4.7.0 csi-volume v0.1.0 metallb v0.14.5-3 |
Azure Linux 2.0.20240425 | Keine Breaking Changes | Erweiterte verfügbare Patches: 1.26.3-8 |
| 1.26.6 | 5 | Calico v3.27.3 metrics-server v0.7.1 Multus v4.0.0 azure-arc-servers v1.1.0 CoreDNS v1.9.4 etcd v3.5.13 sriov-dp v3.5.1 Csi-nfs v4.7.0 csi-volume v0.1.0 metallb v0.14.5-3 |
Azure Linux 2.0.20240425 | Keine Breaking Changes | |
| 1.25.11 | 6 | Calico v3.27.4 metrics-server v0.7.1 Multus v4.0.2 azure-arc-servers v1.1.0 CoreDNS v1.9.4 etcd v3.5.15 sriov-dp v3.5.1 Csi-nfs v4.7.0 csi-volume v0.1.0 metallb v0.14.5-3 |
Azure Linux 2.0.20240425 | Keine Breaking Changes | |
| 1.25.11 | 5 | Calico v3.27.3 metrics-server v0.7.1 Multus v4.0.2 azure-arc-servers v1.1.0 CoreDNS v1.9.4 etcd v3.5.15 sriov-dp v3.5.1 Csi-nfs v4.7.0 csi-volume v0.1.0 metallb v0.14.5-3 |
Azure Linux 2.0.20240425 | Keine Breaking Changes | |
| 1.25.6 | 8 | Calico v3.27.4 metrics-server v0.7.1 Multus v4.0.0 azure-arc-servers v1.1.0 CoreDNS v1.9.4 etcd v3.5.13 sriov-dp v3.5.1 Csi-nfs v4.7.0 csi-volume v0.1.0 metallb v0.14.5-3 |
Azure Linux 2.0.20240425 | Keine Breaking Changes | Erweiterte verfügbare Patches: 1.25.5-5 |
| 1.25.6 | 7 | Calico v3.27.3 metrics-server v0.7.1 Multus v4.0.0 azure-arc-servers v1.1.0 CoreDNS v1.9.4 etcd v3.5.13 sriov-dp v3.5.1 Csi-nfs v4.7.0 csi-volume v0.1.0 metallb v0.14.5-3 |
Azure Linux 2.0.20240425 | Keine Breaking Changes |
Features des Versionspakets
| Funktion | Versionspaket | Hinweise |
|---|---|---|
| Die Volume-Orchestrierungskonnektivität ist TLS verschlüsselt. | Ab 1.28.9-1, 1.28.0-5, 1.27.9-1, 1.27.3-5, 1.26.12-1, 1.26.6-5, 1.25.11-5 und 1.25.6-7 | |
| Clusterknoten sind Azure Arc-fähig | Ab 1.25.6-4, 1.25.11-2, 1.26.3-4, 1.26.6-2, 1.27.1-4, 1.27.3-2 and 1.28.0-2 | |
| Bei gemeinsam genutzten Volumes von Nexus wird das Kapazitätsattribut als Volumengrößenbeschränkung erzwungen. | Ab v1.27.13-3, v1.27.9-5, v1.28.11-4, v1.28.12-3, v1.29.6-4, v1.29.7-3, v1.30.3-1 |
Upgrade von Kubernetes-Versionen
Weitere Informationen zum Upgrade Ihres Clusters finden Sie unter Upgrade eines Azure Operator Nexus Kubernetes Dienstclusters.
Richtlinie zur Unterstützung der Kubernetes-Version
Operator Nexus unterstützt drei Nebenversionen von Kubernetes:
- Die neueste allgemein verfügbare Nebenversion, die in Operator Nexus veröffentlicht wurde (diese wird als N bezeichnet).
- Die beiden vorherigen Nebenversionen.
- Jede unterstützte Nebenversion unterstützt außerdem maximal zwei aktuelle stabile Patches, während die vorherigen Patches während der Lebensdauer der Nebenversion unter die erweiterte Verfügbarkeitsrichtlinie fallen.
Der Operator Nexus Kubernetes-Dienst bietet eine standardisierte Unterstützungsdauer für jede Nebenversion von Kubernetes, die veröffentlicht wird. Die Versionen folgen zwei unterschiedlichen Zeitplänen, die Folgendes widerspiegeln:
- Unterstützungsdauer – Wie lange wird eine Version aktiv gewartet. Am Ende des unterstützten Zeitraums ist die Version am Ende ihrer Lebensdauer.
- Erweiterte Verfügbarkeit – Wie lange kann eine Version nach dem Ende ihrer Lebensdauer noch für die Bereitstellung ausgewählt werden.
Das unterstützte Fenster von Kubernetes-Versionen auf Operator Nexus wird als „N-2“ bezeichnet: (N (Neueste Version) – 2 (Nebenversionen)), und „.Buchstabe“ steht für Patch-Versionen.
Wenn Operator Nexus beispielsweise heute die Version 1.17.a einführt, werden die folgenden Versionen unterstützt:
| Neue Nebenversion | Liste mit unterstützten Versionen |
|---|---|
| 1.17.a | 1.17.a, 1.17.b, 1.16.c, 1.16.d, 1.15.e, 1.15.f |
Wenn eine neue Nebenversion eingeführt wird, werden die ältesten unterstützten Nebenversionen und Patch-Versionen nicht mehr unterstützt. Angenommen, die aktuelle Liste mit den unterstützten Versionen sieht wie folgt aus:
1.17.a
1.17.b
1.16.c
1.16.d
1.15.e
1.15.f
Wenn Operator Nexus die Version 1.18.* veröffentlicht, endet für alle 1.15.*-Versionen der Support.
Supportzeitachse
Der Operator Nexus Kubernetes-Dienst bietet ab der ersten AKS GA-Veröffentlichung einer Nebenversion in der Regel 12 Monate lang Support. Dieser Zeitplan folgt dem Zeitrahmen von Azure AKS, der eine deklarierte langfristig unterstützte Version 1.27 beinhaltet.
Unterstützte Versionen:
- Kann als neue Operator Nexus Kubernetes-Cluster bereitgestellt werden.
- Dies kann das Ziel von Upgrades aus früheren Versionen sein. Beschränkt auf normale Upgradepfade.
- Könnte zusätzliche Patches oder Versionspakete in der Nebenversion enthalten.
Hinweis
In Ausnahmefällen kann der Support für den Nexus Kubernetes-Dienst vorzeitig oder sofort beendet werden, wenn eine Sicherheitslücke oder ein Sicherheitsproblem festgestellt wird. Microsoft wird seine Kunden proaktiv benachrichtigen, falls dies der Fall sein sollte, und daran arbeiten, mögliche Probleme zu entschärfen.
Ende des Lebenszyklus (End of Life, EOL)
Ende der Lebensdauer (EOL) bedeutet, dass keine weiteren Patch- oder Versionspakete mehr produziert werden. Es ist möglich, dass der Cluster, den Sie eingerichtet haben, nicht mehr aktualisiert werden kann, weil die neuesten unterstützten Versionen nicht mehr verfügbar sind. In diesem Fall besteht die einzige Möglichkeit für ein Upgrade darin, den Nexus Kubernetes-Cluster mit der neueren unterstützten Version komplett neu zu erstellen. Nicht unterstützte Upgrades über Extended availability können verwendet werden, um zu einer unterstützten Version zurückzukehren.
Erweiterte Verfügbarkeitsrichtlinie
Während des erweiterten Verfügbarkeitszeitraums für nicht unterstützte Kubernetes-Versionen (d.h. EOL-Kubernetes-Versionen) gibt es keine Sicherheitspatches oder Bugfixes. Detaillierte Informationen zu den Supportkategorien finden Sie in der folgenden Tabelle.
| Unterstützungskategorie | N-2 zu N | Erweiterte Verfügbarkeit |
|---|---|---|
| Upgrades von N-3 auf eine unterstützte Version | Unterstützt | Unterstützt |
| Skalierung des Knotenpools | Unterstützt | Unterstützt |
| Cluster- oder Knotenpoolerstellung | Unterstützt | Unterstützt |
| Kubernetes-Komponenten (einschließlich Add-Ons) | Unterstützt | Nicht unterstützt |
| Komponentenupdates | Unterstützt | Nicht unterstützt |
| Komponentenhotfixes | Unterstützt | Nicht unterstützt |
| Anwenden von Kubernetes-Bugfixes | Unterstützt | Nicht unterstützt |
| Anwenden von Kubernetes-Sicherheitspatches | Unterstützt | Nicht unterstützt |
| Sicherheitspatches für Knotenimages | Unterstützt | Nicht unterstützt |
Hinweis
Operator Nexus basiert auf den Releases und Patches von Kubernetes, einem Open Source-Projekt, das nur ein gleitendes Fenster mit drei Nebenversionen unterstützt. Operator Nexus kann nur vollständige Unterstützung garantieren, wenn diese Versionen im Upstream gepflegt werden. Da im Upstream keine Patches mehr erstellt werden, kann Operator Nexus diese Versionen entweder ungepatcht lassen oder forken. Aufgrund dieser Einschränkung gilt die erweiterte Verfügbarkeit nicht für Elemente, die auf einem Kubernetes-Upstream basieren.
Abgebrochene Nexus Kubernetes-Cluster
Nach Ablauf des erweiterten Verfügbarkeitszeitraums wird die K8s-Version vollständig aus Nexus entfernt. Zu diesem Zeitpunkt werden alle vorhandenen Nexus Kubernetes-Cluster, die auf dieser K8s-Version basieren, abgebrochen. Der einzige unterstützte Vorgang für abgebrochene Cluster wird gelöscht. Wichtig ist, dass ein Upgrade auf eine spätere K8s-Version nicht funktioniert, sobald ein Cluster abgebrochen wurde.
Unterstützte kubectl-Versionen
Sie können eine relativ zu Ihrer kubectl-Version niedrigere oder höhere Nebenversion von kubectl verwenden, die mit der Kubernetes-Unterstützungsrichtlinie für kubectl konsistent ist.
Wenn Ihr kube-apiserver beispielsweise die Version 1.17 hat, können Sie die Versionen 1.16 bis 1.18von kubectl mit diesem kube-apiserver verwenden.
Um kubectl zu installieren oder auf die neueste Version zu aktualisieren, führen Sie Folgendes aus:
az aks install-cli
Langfristiger Support (Long Term Support, LTS)
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 Cluster, die Sie verwalten müssen, erschwert werden kann.
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.
| Communitysupport | Langfristige Unterstützung | |
|---|---|---|
| Einsatzgebiete | Wenn Sie mit Upstream-Kubernetes-Releases Schritt halten können | Szenarien, in denen Ihre Anwendungen nicht mit den in neueren Kubernetes-Versionen eingeführten Änderungen kompatibel sind und Sie aufgrund technischer Einschränkungen oder anderer Faktoren nicht zu einem kontinuierlichen Release-Zyklus übergehen können |
| Supportversionen | Drei allgemein verfügbare Nebenversionen | Eine Kubernetes-Version (derzeit 1.27) für zwei Jahre |
Wichtig
Kubernetes Version 1.27 ist die erste unterstützte LTS-Version von Kubernetes für den Operator Nexus Kubernetes-Dienst. Die nächste LTS-Version nach 1.27 ist 1.30, die den LTS-Support im Oktober 2024 starten wird.
Migrieren von LTS zur nächsten LTS-Version
Nexus Kubernetes-Cluster unterstützen keine direkten Upgrades zwischen LTS-Versionen. Um von einer LTS-Version zur nächsten zu wechseln, haben Sie zwei Optionen: Erstellen Sie entweder einen neuen Cluster mit der gewünschten LTS-Version, und verschieben Sie Ihre Workloads in diesen neuen Cluster, oder führen Sie eine Reihe von Zwischenupgrades über die unterstützten Versionen durch, bevor Sie die nächste LTS-Version erreichen.
Häufig gestellte Fragen
Wie benachrichtigt mich Microsoft, wenn neue Kubernetes-Versionen vorliegen?
Dieses Dokument wird in regelmäßigen Abständen mit den geplanten Daten der neuen Kubernetes-Versionen aktualisiert.
Wie oft muss ich damit rechnen, ein Upgrade auf Kubernetes-Versionen durchzuführen, um weiterhin Unterstützung zu erhalten?
Ab Kubernetes 1.19 hat die Open-Source-Community die Unterstützung auf ein Jahr erweitert. Operator Nexus führt einen Commit aus, um Patches und Unterstützung zu ermöglichen, die den Upstreamzusagen entsprechen. Für Operator Nexus-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 Sie die N-3-Version oder älter verwenden, befinden Sie sich außerhalb des Supportfensters. Wenn Sie das Upgrade von Version N-3 auf N-2 durchführen, befinden Sie sich wieder in unserem Supportfenster. Beispiel:
- Wenn die älteste unterstützte AKS-Version 1.25.x ist und Sie 1.24.x oder eine ältere Version verwenden, wird diese Version nicht mehr unterstützt.
- Nach einem erfolgreichen Upgrade von 1.24.x auf 1.25.x oder höher, befinden Sie sich wieder in unserem Supportfenster.
- „Skip-Level Upgrades“ werden nicht unterstützt. Um ein Upgrade von 1.23.x auf 1.25.x durchzuführen, müssen Sie zuerst ein Upgrade auf 1.24.x und dann auf 1.25.x durchführen.
Downgrades werden nicht unterstützt.
Was passiert, wenn ich für mein Cluster kein Upgrade durchführe?
Wenn Sie Ihr Cluster nicht aktualisieren, erhalten Sie weiterhin Support für die Kubernetes-Version, die Sie bis zum Ende des Supportzeitraums ausführen. Danach erhalten Sie keine Unterstützung mehr für Ihr Cluster. Sie müssen Ihr Cluster auf eine unterstützte Version aktualisieren, um weiterhin Support zu erhalten.
Was geschieht, wenn ich mein Cluster nicht vor dem Ende des erweiterten Verfügbarkeitszeitraums aktualisiere?
Wenn Sie Ihr Cluster nicht vor dem Ende des erweiterten Verfügbarkeitszeitraums aktualisieren, können Sie Ihr Cluster nicht mehr auf eine unterstützte Version oder einen Scaleout-Agentpool aktualisieren. Sie müssen Ihr Cluster mit einer unterstützten Version neu erstellen, um weiterhin Support zu erhalten.
Was bedeutet „nicht unterstützt“?
„Nicht unterstützt“ bedeutet:
- Die Version, die Sie ausführen, befindet sich nicht auf der Liste der unterstützten Versionen.
- Sie werden aufgefordert, den Cluster auf eine unterstützte Version zu aktualisieren, wenn Sie Support anfordern.
Des Weiteren gewährt Operator Nexus für Cluster mit Versionen, die nicht in der Liste der unterstützten Versionen aufgeführt sind, weder Laufzeitgarantien noch sonstige Garantien.
Was geschieht, wenn ein Benutzer einen Kubernetes-Clusters mit einer Nebenversion skaliert, die nicht unterstützt wird?
Bei Nebenversionen, die von Operator Nexus 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.
Kann ich während eines Clusterupgrades mehrere Kubernetes-Versionen überspringen?
Beim Upgrade eines unterstützten Operator Nexus Kubernetes-Clusters können Nebenversionen von Kubernetes nicht übersprungen werden. Die Richtlinie zur Versionsabweichung der Kubernetes-Steuerungsebenen unterstützt das Überspringen von Nebenversionen nicht. Beispielsweise Upgrades zwischen:
- 1.12.x ->1.13.x: zulässig.
- 1.13.x ->1.14.x: zulässig.
- 1.12.x ->1.14.x: nicht zulässig.
So führen Sie ein Upgrade von 1.12.x -> 1.14.x aus:
- Führen Sie ein Upgrade von 1.12.x -> 1.13.x aus:
- Führen Sie ein Upgrade von 1.13.x -> 1.14.x aus:
Kann ich während des erweiterten Verfügbarkeitsfensters einen neuen Cluster erstellen?
Ja, Sie können während des erweiterten Verfügbarkeitsfensters einen neuen 1.xx.x-Cluster erstellen. Sie sollten jedoch einen neuen Cluster mit der neuesten unterstützten Version erstellen.
Kann ich während des erweiterten Verfügbarkeitsfensters ein Upgrade eines Clusters auf eine neuere Version durchführen?
Ja, Sie können während des erweiterten Verfügbarkeitsfensters ein Upgrade eines N-3-Clusters auf ein N-2-Cluster durchführen? Wenn Sie derzeit ein N-4-Cluster haben, können Sie die erweiterte Verfügbarkeit verwenden, um zuerst ein Upgrade von N-4 auf N-3 durchzuführen und dann mit dem Upgrade auf eine unterstützte Version (N-2) fortzufahren.
Kann ich weiterhin neue Knotenpools hinzufügen, auch wenn ich mich in einem erweiterten Verfügbarkeitsfenster befinde? Oder muss ich ein Upgrade durchführen?
Ja, Sie dürfen dem Cluster Knotenpools hinzufügen.