Aktualisieren eines Azure Red Hat OpenShift-Clusters mit gehosteten Steuerungsebenen (Vorschau)

Aktualisieren Sie Ihre Azure Red Hat OpenShift mit gehosteten Kontrollebenenclustern, um auf neue OpenShift-Features, Sicherheitsupdates und Fehlerbehebungen zuzugreifen. Azure Red Hat OpenShift mit gehosteten Steuerebenen verwendet ein entkoppeltes Upgrademodell, bei dem die Steuerungsebene und die Knotenpools unabhängig voneinander aktualisiert werden. Verwenden Sie dieses Upgrademodell, um Upgrades der Y-Stream-Steuerungsebene und Knotenpoolupgrades zu planen, die ihren Wartungsfenstern entsprechen.

Voraussetzungen

• Ein vorhandener Azure Red Hat OpenShift-Cluster mit gehosteten Steuerungsebenen.
• Azure CLI Version 2.67.0 oder höher. Informationen zum Installieren oder Aktualisieren finden Sie unter Installieren der Azure CLI.

• Die ARO HCP CLI-Erweiterung wird installiert. Wenn Sie es installieren müssen, führen Sie az extension add --name aro aus.

• Die Rolle "Mitwirkender" und die Rolle "Benutzerzugriffsadministrator" (oder die Rolle "Besitzer") in der Ressourcengruppe oder dem Abonnement, die den Cluster enthält.

Wie Upgrades funktionieren

Azure Red Hat OpenShift mit gehosteten Steuerebenen verwendet ein entkoppeltes Upgrademodell, bei dem die Steuerungsebene und die Knotenpools unabhängig voneinander aktualisiert werden, mit Versionskompatibilitätsregeln, die steuern, welche Kombinationen unterstützt werden.

Aktualisierungen der Steuerungsebene

Zwei Arten von Steuerebenenupgrades sind vorhanden:

• Z-Stream-Upgrades (Patch): Red Hat Site Reliability Engineers (SREs) wenden diese Upgrades automatisch an. Z-Stream-Upgrades sind Wartungsupdates innerhalb derselben Nebenversion, z. B. ein Upgrade von 4.22.1 auf 4.22.2. Diese Upgrades wenden Sicherheits- und Bugfixes an, ohne Clustervorgänge zu blockieren. Sie können weiterhin Knotenpools erstellen, Workloads skalieren und Anwendungen bereitstellen, während die SREs die Steuerungsebene auf eine neue Z-Stream-Version aktualisieren. Sie müssen keine Maßnahmen für Upgrades der Z-Stream-Steuerungsebene ergreifen.

• Y-Stream-Upgrades (Nebenversion): Sie initiieren diese Upgrades mithilfe der Azure CLI. Y-Stream-Upgrades verschieben die Steuerebene auf eine neue Nebenversion, z. B. ein Upgrade von 4.21 auf 4.22. Sie steuern, wann y-Stream-Upgrades stattfinden, damit Sie Upgrades an Ihren Änderungsverwaltungsprozessen und Wartungsfenstern ausrichten können.

Upgrades von Knotenpools

Sie initiieren Upgrades von Knotenpools immer selbst, sowohl bei Z-Stream- als auch bei Y-Stream-Versionen. Upgrades von Knotenpools verwenden eine Strategie der schrittweisen Ersetzung, bei der während des Upgrades jeder Knoten im Knotenpool ersetzt wird. Sie können mehrere Knotenpools gleichzeitig aktualisieren.

Unterstützte Versionskombinationen

Bevor Sie Ihr Cluster aktualisieren, sollten Sie die Einschränkungen hinsichtlich der Versionsabweichungen zwischen der Steuerebene und den Knotenpools verstehen. Das Verletzen dieser Einschränkungen kann Ihren Cluster in einem nicht unterstützten Zustand belassen.

Es gelten die folgenden Regeln:

• Die Nebenversion des Knotenpools darf die Nebenversion der Steuerebene nicht überschreiten. Ein Knotenpool kann eine höhere Z-Stream-Version (Patch) als die Steuerebene innerhalb derselben Nebenversion ausführen. Aktualisieren Sie die Control Plane immer zuerst auf die Ziel-Nebenversion, bevor Sie Knotenpools auf dieselbe Nebenversion aktualisieren.
• Zwei Nebenversionsunterstützungsfenster. Die Steuerebene unterstützt Knotenpools in zwei Nebenversionen von y-Stream. Beispielsweise unterstützt eine Steuerungsebene mit Version 4.22 Knotenpools mit Version 4.21 und 4.20, unterstützt jedoch keine Knotenpools mit Version 4.19.
• Bis zu zwei Minor-Versionssprünge. Sie können einen Knotenpool auf eine neuere Z-Stream-Version innerhalb derselben Nebenversion aktualisieren oder bis zu zwei Nebenversionen springen. Sie können beispielsweise einen Knotenpool von 4.20.z auf 4.22.z, aber nicht von 4.20.z auf 4.23.z aktualisieren. Die Zielversion darf die Nebenversion der Steuerebene nicht überschreiten.

Die folgende Tabelle enthält Beispiele für zulässige und unzulässige Versionskombinationen:

Überprüfen der aktuellen Clusterversion

Überprüfen Sie vor dem Upgrade die aktuelle OpenShift-Version Ihres Clusters.

oc get clusterversion version

Die Ausgabe zeigt die aktuelle OpenShift-Version:

NAME      VERSION   AVAILABLE   PROGRESSING   SINCE   STATUS
version   4.20.26   True        False         70s     Cluster version is 4.20.26

Entfernen Sie die Steuerungsebene

Um die Steuerebene auf eine neue Nebenversion (y-stream) zu aktualisieren, listen Sie die verfügbaren Versionen auf, und initiieren Sie dann das Upgrade mithilfe von Azure CLI.

1. Legen Sie die Umgebungsvariablen für Ihre Ressourcengruppe, den Clusternamen und Azure Region fest, sofern noch nicht geschehen:

   CUSTOMER_RG_NAME="<resource-group-name>"
   CLUSTER_NAME="<cluster-name>"
   LOCATION="<azure-region>"
   

2. Auflisten der verfügbaren OpenShift-Versionen in Ihrer Azure Region, indem Sie den folgenden Befehl ausführen:

   az aro hcp get-versions \
     --location "${LOCATION}" \
     --query "[].{name:Name, channelGroup:ChannelGroup}" \
     --output table
   

   Die Ausgabe listet die verfügbaren Versionen auf:

   Name     ChannelGroup
   -------  --------------
   4.22.0   stable
   4.22.1   stable
   4.22.2   stable
   4.22.3   stable
   ...
   

3. Identifizieren Sie die Zielversion für Ihr Upgrade. Sie können nur auf die nächste Nebenversion aktualisieren. Wenn ihre Steuerebene beispielsweise Version 4.20 ausführt, können Sie ein Upgrade auf Version 4.21 durchführen, aber nicht direkt auf Version 4.22.

4. Aktualisieren Sie die Steuerebene, indem Sie den folgenden Befehl ausführen. Ersetzen Sie <target-version> durch die gewünschte OpenShift-Version, z. B. 4.22:

   az aro hcp cluster update \
     --name "${CLUSTER_NAME}" \
     --resource-group "${CUSTOMER_RG_NAME}" \
     --version "<target-version>"
   

5. Überprüfen Sie, ob die Upgradeanforderung angenommen wurde, indem Sie den Bereitstellungsstatus überprüfen:

   az aro hcp cluster show \
     --name "${CLUSTER_NAME}" \
     --resource-group "${CUSTOMER_RG_NAME}" \
     --query "{version:properties.version, provisioningState:properties.provisioningState}"
   

   Wenn provisioningState den Wert Succeeded zurückgibt, überprüft der Dienst den Upgradepfad von der aktuellen Version zur Zielversion und stößt das Upgrade an. Das Upgrade wird im Hintergrund ausgeführt, ohne andere Vorgänge im Cluster zu blockieren. Wenn provisioningStateFailed zurückgibt, konnte der Dienst den Upgradepfad nicht validieren.

Upgrade eines Knotenpools

Nachdem Sie die Steuerebene aktualisiert haben, können Sie einen oder mehrere Knotenpools auf eine kompatible Version aktualisieren. Upgrades von Knotenpools verwenden eine Strategie der schrittweisen Ersetzung, bei der während des Upgrades jeder Knoten ersetzt wird.

1. Legen Sie die Umgebungsvariablen für Ihre Ressourcengruppe, den Clusternamen, den Knotenpoolnamen und Azure Region fest, sofern noch nicht geschehen:

   CUSTOMER_RG_NAME="<resource-group-name>"
   CLUSTER_NAME="<cluster-name>"
   NODE_POOL_NAME="<node-pool-name>"
   LOCATION="<azure-region>"
   

2. Überprüfen Sie die aktuelle Version des Knotenpools, indem Sie den folgenden Befehl ausführen:

   az aro hcp cluster nodepool show \
     --cluster-name "${CLUSTER_NAME}" \
     --name "${NODE_POOL_NAME}" \
     --resource-group "${CUSTOMER_RG_NAME}" \
     --query "properties.version"
   

3. Auflisten der verfügbaren OpenShift-Versionen in Ihrer Azure Region:

   az aro hcp get-versions \
     --location "${LOCATION}" \
     --query "[].{name:Name, channelGroup:ChannelGroup}" \
     --output table
   

4. Wählen Sie eine Zielversion für den Knotenpool aus, der die folgenden Kriterien erfüllt:

   • Die Nebenversion des Ziels ist kleiner oder gleich der Nebenversion der Steuerebene. Der Knotenpool kann eine höhere Patchversion als die Steuerebene innerhalb derselben Nebenversion ausführen.
   • Die Zielversion ist eine neuere Z-Stream-Version innerhalb derselben Nebenversion oder bis zu zwei Nebenversionen. Sie können nicht mehr als zwei Minor-Versionen überspringen. Wenn beispielsweise der Knotenpool Version 4.19.3 ausführt, können Sie ein Upgrade auf 4.19.5 (z-stream), 4.20.x (eine Nebenversion) oder 4.21.x (zwei Nebenversionen) durchführen, jedoch nicht direkt auf 4.22.0.

5. Führen Sie den folgenden Befehl aus, um den Knotenpool zu aktualisieren. Ersetzen Sie <target-version> durch die gewünschte OpenShift-Version, z. B. 4.22.3:

   az aro hcp cluster nodepool update \
     --cluster-name "${CLUSTER_NAME}" \
     --name "${NODE_POOL_NAME}" \
     --resource-group "${CUSTOMER_RG_NAME}" \
     --version "<target-version>"
   

   Das Upgrade beginnt sofort. Während der gestaffelten Ersetzung laufen die Knoten im Knotenpool vorübergehend sowohl in der alten als auch in der neuen Version.

   Note

   Die nodeDrainTimeoutMinutes Eigenschaft eines Knotenpools steuert, wie lange der Cluster während des Upgrades durch Pod Disruption Budgets geschützte Workloads respektiert. Nach Ablauf dieser Schonfrist entfernt der Cluster die verbleibenden Workloads zwangsweise. Der Standardwert wird von der Einstellung auf Clusterebene übernommen. Sie können diesen Wert von 0 (ohne zeitliche Einschränkung bis zum vollständigen Abschluss) bis zu 10080 Minuten (eine Woche) festlegen.

6. Überprüfen Sie, ob die Upgradeanforderung angenommen wurde, indem Sie den Bereitstellungsstatus überprüfen:

   az aro hcp cluster nodepool show \
     --cluster-name "${CLUSTER_NAME}" \
     --name "${NODE_POOL_NAME}" \
     --resource-group "${CUSTOMER_RG_NAME}" \
     --query "{version:properties.version, provisioningState:properties.provisioningState}"
   

   Wenn provisioningStateSucceeded zurückgibt, hat der Dienst den Upgradepfad validiert und das Upgrade des Knotenpools ausgelöst. Das Upgrade wird im Hintergrund ausgeführt, ohne andere Vorgänge im Knotenpool zu blockieren.

7. Wiederholen Sie die Schritte 2 bis 6 für jeden Knotenpool, den Sie aktualisieren möchten. Sie können mehrere Knotenpools gleichzeitig aktualisieren.

Verwandte Inhalte

• Azure Red Hat OpenShift Supportlebenszyklus
• Skalieren und Konfigurieren von Knotenpools