Upgrade eines Azure Operator Nexus Kubernetes-Clusters

Artikel
08/22/2024

Dieser Artikel enthält Anweisungen zum Aktualisieren eines Operator Nexus-Clusters, um die neuesten Funktionen und Sicherheitsupdates zu erhalten. Im Rahmen des Kubernetes-Clusterlebenszyklus müssen regelmäßige Upgrades auf die aktuelle Kubernetes-Version ausgeführt werden. Es ist wichtig, jeweils die aktuellen Sicherheitsversionen anzuwenden oder bei einem Upgrade die neuesten Features zu erhalten. In diesem Artikel erfahren Sie, wie Sie auf Upgrades für Ihren Kubernetes-Cluster überprüfen, diese konfigurieren und anwenden.

Begrenzungen

Der Standardupgradeprozess für Cluster ist die horizontale Skalierung, was bedeutet, dass mindestens ein zusätzlicher Knoten hinzugefügt wird (oder so viele Knoten wie in Max. Anstieg konfiguriert). Wenn nicht genügend Kapazität verfügbar ist, kann das Upgrade nicht erfolgreich ausgeführt werden.
Wenn neue Kubernetes-Versionen verfügbar sind, werden Mandantencluster nicht automatisch aktualisiert. Benutzer sollten das Upgrade initiieren, wenn alle Netzwerkfunktionen im Cluster bereit sind, die neue Kubernetes-Version zu unterstützen. Weitere Informationen finden Sie unter Aktualisieren des Clusters.
Operator Nexus bietet clusterweite Upgrades und sorgt für Konsistenz in allen Knotenpools. Das Upgrade eines einzelnen Knotenpools wird nicht unterstützt. Außerdem wird das Knotenimage als Teil des Clusterupgrades aktualisiert, wenn eine neue Version verfügbar ist.
Anpassungen an Agentknoten gehen während Clusterupgrades verloren. Es wird empfohlen, diese Anpassungen in DaemonSet zu platzieren, anstatt manuelle Änderungen an der Knotenkonfiguration vorzunehmen, um sie nach dem Upgrade beizubehalten.
Änderungen an Add-On-Konfigurationen von Kernen werden im Rahmen des Clusterupgradeprozesses in der Standard-Add-On-Konfiguration wiederhergestellt. Vermeiden Sie das Anpassen der Add-On-Konfiguration (z. B. Calico usw.), um potenzielle Upgradefehler zu verhindern. Wenn bei der Wiederherstellung der Add-On-Konfiguration Probleme auftreten, kann dies zu Upgradefehlern führen.
Beim Upgrade des Operator Nexus Kubernetes-Clusters können Nebenversionen von Kubernetes nicht übersprungen werden. Sie müssen alle Upgrades nacheinander nach der Hauptversionsnummer ausführen. Beispielsweise sind die Upgrades 1.14.x ->1.15.x oder 1.15.x ->1.16.x zulässig, das Upgrade 1.14.x ->1.16.x ist jedoch nicht möglich. Wenn Ihre Version um mehr als eine Hauptversion niedriger ist, sollten Sie mehrere sequenzielle Upgrades durchführen.
Die Werte für maximalen Anstieg und/oder maximal nicht verfügbar müssen während der Clustererstellung festgelegt werden. Sie können diese Werte nicht mehr ändern, nachdem der Cluster erstellt wurde. Weitere Informationen finden Sie in upgradeSettings unter Erstellen eines Operator Nexus Kubernetes-Clusters.

Voraussetzungen

Ein Azure Operator Nexus Kubernetes-Cluster, der in einer Ressourcengruppe in Ihrem Azure-Abonnement bereitgestellt wird.
Wenn Sie Azure CLI verwenden, müssen Sie für diesen Artikel die neueste Azure CLI-Version ausführen. Informationen zum Durchführen einer Installation oder eines Upgrades finden Sie bei Bedarf unter Installieren der Azure CLI.
Mindestens erforderliche networkcloud az-cli-Erweiterungsversion: 2.0.b3
Grundlegendes zum Konzept der Versionspakete. Weitere Informationen finden Sie unter Nexus Kubernetes-Versionspakete.

Überprüfen auf verfügbare Upgrades

Überprüfen Sie, welche Kubernetes-Releases für Ihren Cluster verfügbar sind, indem Sie die folgenden Schritte ausführen:

Mithilfe der Azure-Befehlszeilenschnittstelle

Der folgende Azure CLI-Befehl gibt die verfügbaren Upgrades für Ihren Cluster zurück:

az networkcloud kubernetescluster show --name <NexusK8sClusterName> --resource-group <ResourceGroup> --output json --query availableUpgrades

Beispielausgabe:

[
  {
    "availabilityLifecycle": "GenerallyAvailable",
    "version": "v1.25.4-4"
  },
  {
    "availabilityLifecycle": "GenerallyAvailable",
    "version": "v1.25.6-1"
  },
  {
    "availabilityLifecycle": "GenerallyAvailable",
    "version": "v1.26.3-1"
  }
]

Verwenden des Azure-Portals

Melden Sie sich beim Azure-Portal an.
Navigieren Sie zur Ihrem Operator Nexus Kubernetes-Cluster.
Wählen Sie unter Übersicht die Registerkarte Verfügbare Upgrades aus.

Auswählen einer Version für das Upgrade

Die Ausgabe der verfügbaren Upgrades gibt an, dass mehrere Versionen zur Aktualisierung ausgewählt werden können. In diesem spezifischen Szenario wird der aktuelle Cluster auf Version v1.25.4-3. ausgeführt. Daher sind die verfügbaren Upgradeoptionen v1.25.4-4 und die neueste Patchversion v1.25.6-1.. Darüber hinaus ist auch eine neue Nebenversion verfügbar.

Sie haben die Möglichkeit, auf eine der verfügbaren Versionen zu aktualisieren. Es wird jedoch empfohlen, das Upgrade auf die neueste verfügbare major-minor-patch-versionbundle-Version durchzuführen.

Hinweis

Das Eingabeformat für die Version ist major.minor.patch oder major.minor.patch-versionbundle. Die Versionseingabe muss eine der verfügbaren Upgradeversionen sein. Wenn beispielsweise die aktuelle Version des Clusters 1.1.1-1 ist, sind gültige Versionseingaben 1.1.1-2 oder 1.1.1-x. Während 1.1.1 ein gültiges Format ist, wird kein Update ausgelöst, da die aktuelle Version bereits 1.1.1 ist. Um ein Update zu initiieren, können Sie die vollständige Version mit dem Versionspaket angeben, z. B. 1.1.1-2. 1.1.2 und 1.2.x sind jedoch eine gültige Eingabe und verwenden das neueste Versionspaket, das für 1.1.2 oder 1.2.x verfügbar ist.

Durchführen eines Upgrades für den Cluster

Während des Clusterupgradeprozesses führt Operator Nexus die folgenden Vorgänge aus:

Fügen Sie dem Cluster einen neuen Steuerebenenknoten mit der angegebenen Kubernetes-Version hinzu.
Nachdem der neue Knoten hinzugefügt wurde, legen Sie einen der alten Steuerebenenknoten ab, und stellen Sie sicher, dass die darauf ausgeführten Arbeitslasten ordnungsgemäß auf andere fehlerfreie Steuerebenenknoten verschoben werden.
Nachdem der alte Steuerebenenknoten geleert wurde, wird er entfernt, und dem Cluster wird ein neuer Steuerebenenknoten hinzugefügt.
Dieser Prozess wird wiederholt, bis alle Steuerebenenknoten im Cluster aktualisiert wurden.
Beim Upgrade von Workerknoten über Anstieg (Standard):
- Für jeden Agentpool im Cluster wird ein neuer Workerknoten (oder so viele Konten, wie in Max. Anstieg konfiguriert) mit der festgelegten Kubernetes-Version hinzugefügt. Mehrere Agentpools werden gleichzeitig aktualisiert.
- Führen Sie eine Absperrung und einen Ausgleich eines der alten Workerknoten durch, um die Unterbrechung der ausgeführten Anwendungen zu minimieren. Wenn Sie „Max. Anstieg“ verwenden, werden so viele Workerknoten gleichzeitig abgesperrt und ausgeglichen, wie die Anzahl der angegebenen Pufferknoten beträgt.
- Nachdem der alte Workerknoten geleert wurde, wird er entfernt, und ein neuer Workerknoten mit der neuen Kubernetes-Version wird dem Cluster hinzugefügt (oder so viele Knoten wie in Max. Anstieg konfiguriert).
Beim Upgrade von Workerknoten ohne Anstieg:
- Für jeden Agentpool im Cluster wird ein alter Workerknoten (oder so viele Knoten wie durch max nicht verfügbar konfiguriert) abgesperrt, geleert und dann entfernt, bevor er durch einen neuen Workerknoten mit der angegebenen Kubernetes-Version ersetzt wird. Mehrere Agentpools werden gleichzeitig aktualisiert.
- Während des Upgrades wird die Clusterkapazität vorübergehend verringert, da Pods, die aus dem alten Workerknoten geleert wurden, nicht sofort über einen neuen Knoten verfügen, zu dem sie wechseln können. Dies kann dazu führen, dass Pods in einen ausstehenden Zustand versetzt werden, wenn nicht genügend Kapazität vorhanden ist. Daher ist es wichtig, Ihren Cluster so zu entwerfen, dass er die Anforderungen an die Anwendungskapazität erfüllt, insbesondere bei Upgrades ohne Anstieg.
Dieser Prozess wird wiederholt, bis alle Workerknoten im Cluster aktualisiert wurden.

Hinweis

Das Clusterupgrade erstellt keine neuen Knoten und ersetzt die alten Knoten, wenn die Imageversion des Betriebssystems und die Kubernetes-Version zwischen Versionspaketen identisch bleiben. Dies wird erwartet, da das Upgrade nur Updates für Add-On-Versionen anstelle neuer Betriebssystem- oder K8s-Versionen enthalten kann. Da kein rollierendes Upgrade erforderlich ist, gibt es keine Absperrung und Entleerung der Knoten, sodass keine Pod-Unterbrechungen auftreten.

Wichtig

Stellen Sie sicher, dass alle PodDisruptionBudgets (PDBs) die Verschiebung von jeweils mindestens einem Podreplikat zulassen, da der Vorgang des Entleeren/Entfernens andernfalls nicht ausgeführt werden kann. Wenn der Entleerungsvorgang nicht ausgeführt werden kann, wird auch der Upgradevorgang nicht ausgeführt, um sicherzustellen, dass die Anwendungen nicht unterbrochen werden. Beheben Sie die Ursache für die Beendigung des Vorgangs (z. B. falsche PDBs, unzureichendes Kontingent usw.), und wiederholen Sie den Vorgang. Es ist auch möglich, einen Entleerungstimeout pro Workerknotenpool zu konfigurieren, nach dem der Knoten entfernt wird, auch wenn die Leerung der Pods noch nicht abgeschlossen ist. Dadurch kann verhindert werden, dass Upgrades durch falsch konfigurierte PDBs blockiert werden. Die Einstellung für den Entleerungstimeout ist in Sekunden konfiguriert und ist standardmäßig auf 1800 festgelegt.

Führen Sie ein Upgrade Ihres Clusters mithilfe des Befehls networkcloud kubernetescluster update durch.

az networkcloud kubernetescluster update --name myNexusK8sCluster --resource-group myResourceGroup --kubernetes-version v1.26.3

Überprüfen Sie mit dem Befehl show, ob das Upgrade erfolgreich war.

az networkcloud kubernetescluster show --name myNexusK8sCluster --resource-group myResourceGroup --output json --query kubernetesVersion

Die Ausgabe im folgenden Beispiel zeigt, dass im Cluster nun Version v1.26.3 ausgeführt wird:

"v1.26.3"

Stellen Sie sicher, dass der Cluster fehlerfrei ist.

az networkcloud kubernetescluster show --name myNexusK8sCluster --resource-group myResourceGroup --output table

Die Ausgabe im folgenden Beispiel zeigt, dass der Cluster fehlerfrei ist:

Name                 ResourceGroup          ProvisioningState    DetailedStatus    DetailedStatusMessage             Location
------------------   ---------------------  -------------------  ----------------  --------------------------------  --------------
myNexusK8sCluster    myResourceGroup        Succeeded            Available         Cluster is operational and ready  southcentralus

Anpassen des Upgrades über Knotenanstieg oder nicht verfügbar

Standardmäßig konfiguriert AKS Upgrades für einen Anstieg mit einem zusätzlichen Knoten. Ein Standardwert von eins für die Einstellung des maximalen Anstiegs ermöglicht Operator Nexus das Minimieren von Workloadunterbrechungen, indem vor dem Absperren/Ausgleichen vorhandener Anwendungen ein zusätzlicher Knoten erstellt wird, um einen Knoten einer älteren Version zu ersetzen. Der maximale Anstiegswert kann pro Knotenpool angepasst werden, um einen Kompromiss zwischen Upgradegeschwindigkeit und Upgradeunterbrechung zu ermöglichen. Wenn Sie den maximalen Anstiegswert erhöhen, wird der Upgradevorgang schneller abgeschlossen. Wenn Sie einen großen Wert für den maximalen Anstieg festlegen, kann es während des Upgradeprozesses zu Unterbrechungen kommen.

Beispielsweise ermöglicht ein maximaler Anstiegswert von 100 % den schnellstmöglichen Upgradevorgang (wobei die Knotenanzahl verdoppelt wird), führt aber auch dazu, dass alle Knoten im Knotenpool gleichzeitig ausgeglichen werden. Sie könnten für Testumgebungen einen höheren Wert verwenden. Für Produktionsknotenpools wird ein maximaler Anstiegswert von 33 % empfohlen.

Es ist nicht immer empfehlenswert, ein Upgrade über einen Anstieg durchzuführen, z. B. in ressourcenbeschränkten Umgebungen. Upgrades können auch ohne Anstieg fortgesetzt werden, wobei zuerst ein Workerknoten entfernt und dann ersetzt wird. Das bedeutet, dass keine zusätzliche Ressource benötigt wird, führt jedoch zu Zeiträumen mit reduzierter Kapazität, in denen Pods möglicherweise nicht in einem Knoten geplant werden können. Dieser Upgradetyp wird pro Knotenpool durch die Einstellung „max. nicht verfügbar“ gesteuert. Standardmäßig ist „max. nicht verfügbar“ auf „0“ festgelegt. Dies gibt an, dass höchstens 0 Knoten nicht verfügbar sein dürfen, d. h. dieser Upgradetyp tritt nicht standardmäßig auf.

Für den maximalen Anstieg und maximal nicht verfügbar akzeptiert die API sowohl ganzzahlige Werte als auch einen prozentualen Wert. Eine ganze Zahl, z. B. 5, gibt an, dass fünf Knoten ansteigen/nicht verfügbar gemacht werden können. Der Wert „50 %“ gibt einen Wert des Anstiegs/der Nichtverfügbarkeit der Hälfte der aktuellen Knotenanzahl im Pool an.

Entweder maximaler Anstieg oder maximale Nichtverfügbarkeit müssen mindestens 1 (oder 1 %) sein, andernfalls gibt es keinen Mechanismus, mit dem der Cluster aktualisiert werden kann. Ein Prozentwert wird auf die nächste Knotenanzahl aufgerundet. Sowohl der maximale Anstieg als auch die maximale Nichtverfügbarkeit können auf maximal 100 % festgelegt werden. Wenn der „Max Surge“-Wert höher als die erforderliche Anzahl von Knoten ist, die aktualisiert werden soll, wird die Anzahl der Knoten, die aktualisiert werden soll, für den „Max Surge“-Wert verwendet.

Der maximale Anstieg und die maximale Nichtverfügbarkeit können gleichzeitig konfiguriert werden. In diesem Fall wird das Upgrade über eine Mischung aus Anstieg und Nichtverfügbarkeit fortgesetzt.

Wichtig

Die Kubernetes-Standardworkloads wechseln von selbst auf die neuen Knoten, wenn sie von den zu entfernenden Knoten entleert werden. Beachten Sie, dass der Operator Nexus Kubernetes-Dienst keine Workloadzusagen für nicht standardmäßiges Kubernetes-Verhalten machen kann.

Nächste Schritte

Weitere Informationen über Nexus Kubernetes-Versionspakete.

Freigeben über