Upgrade der Clusterlaufzeit von Azure CLI

In diesem Anleitungshandbuch werden die Schritte zum Installieren der erforderlichen Azure CLI und Erweiterungen erläutert, die für die Interaktion mit Operator Nexus erforderlich sind.

Voraussetzungen

1. Installieren Sie die neueste Version der passenden CLI-Erweiterungen.
2. Die neueste CLI-Erweiterung ist erforderlich. Sie kann nach den hier aufgeführten Schritten installiert werden.
3. Abonnementzugriff zum Ausführen von CLI-Befehlen der Azure Operator Nexus Network Fabric (NF) und Netzwerkcloud (NC)-Erweiterung.
4. Sammeln Sie die folgenden Informationen:
   • Abonnement-ID ()
   • Clustername ()
   • Ressourcengruppe ()
5. Der detaillierte Clusterstatus muss sein .
6. Cluster-zu-Cluster-Manager-Konnektivität muss sein .
7. Azure Voraussetzungen (Log Analytics Workspace, Storage Account, Key Vault) müssen überprüft werden. Diese Ressourcen werden überprüft, bevor das Upgrade beginnt. Siehe clusterverwaltete Identität und vom Benutzer bereitgestellte Ressourcen.
8. Unter Clusterworkload-Computeservern
   • Drei von vier Steuerebenenknoten müssen den Energiezustand , den Cordon-Status , den Zustand "Bereit" und "Herabgestuft " aufweisen.
     • Der Knoten "Ersatzsteuerungsebene" sollte sich im Zustand "Power" , "Ready" und "Degraded " befinden.
   • Die Management-Server sind in zwei Gruppen auf ungeraden und geraden nummerierten Racks unterteilt. Für jede Gruppe muss sich mindestens die Hälfte der Server im Power State , Cordon-Status , Ready-Zustand und Degraded-Zustand befinden.
     • Es wird empfohlen, mehr als 50% der Verwaltungsebenenserver zur Verfügung zu haben, um risiken zu mindern.
   • Compute-Plane-Servernummern variieren je nach den individuellen Schwellenwerteinstellungen für die Clusterlaufzeit. Kunden müssen ihre Mindestanzahl basierend auf ihren Einstellungen ermitteln, indem sie nach Power-Status , Cordon-Status , Bereit-Zustand und Herabgestuft suchen.
9. Wählen Sie unter "Clusterverwaltete Ressourcengruppe" den Gruppennamen aus, um zur Seite "Ressourcengruppe" zu wechseln.
   • Suchen Sie in der Ressourcengruppe nach Kubernetes - Azure Arc, um die Azure Arc Informationen zu identifizieren und auszuwählen. Der Status sollte sein .
     • Wählen Sie auf der Azure Arc-Seite "Einstellungen" > Erweiterungen aus.
       • sollte sich im Status befinden.
     • sollte sich im Status befinden.

Überprüfen der aktuellen Laufzeitversion

Überprüfen Sie die aktuelle Clusterlaufzeitversion vor dem Upgrade: Überprüfen der aktuellen Clusterlaufzeitversion.

Suchen aller verfügbaren Runtimeversionen

Über das Azure-Portal

Um verfügbare upgradefähige Laufzeitversionen zu finden, navigieren Sie im Azure portal zum Zielcluster. Navigieren Sie im Übersichtsbereich des Clusters zur Registerkarte "Verfügbare Upgradeversionen ".

Auf der Registerkarte "Verfügbare Upgradeversionen " können wir die verschiedenen Clusterversionen sehen, die derzeit für das Upgrade verfügbar sind. Der Operator kann aus den aufgelisteten Ziellaufzeitversionen auswählen. Fahren Sie nach der Auswahl mit dem Upgrade des Clusters fort.

Via Azure CLI

Verfügbare Upgrades können über die Azure CLI abgerufen werden:

az networkcloud cluster show --name "<CLUSTER>" \
--resource-group "<CLUSTER_RG>" \
--subscription "<SUBSCRIPTION>" | grep -A8 availableUpgradeVersions

In der Ausgabe finden Sie die -Eigenschaft. Sehen Sie sich das Feld an:

  "availableUpgradeVersions": [
    {
      "controlImpact": "True",
      "expectedDuration": "Upgrades may take up to 4 hours + 2 hours per rack",
      "impactDescription": "Workloads will be disrupted during rack-by-rack upgrade",
      "supportExpiryDate": "2023-07-31",
      "targetClusterVersion": "3.3.0",
      "workloadImpact": "True"
    }
  ],

Wenn keine Clusterupgrades verfügbar sind, ist die Liste leer.

Konfigurieren Sie Berechnungsschwellenwerte für das Laufzeit-Upgrade mithilfe von Cluster

Der folgende Azure CLI Befehl wird verwendet, um die Berechnungsschwellenwerte für ein Laufzeitupgrade zu konfigurieren:

az networkcloud cluster update \
--name "<CLUSTER>" \
--resource-group "<CLUSTER_RG>" \
--subscription "<SUBSCRIPTION>" \
--update-strategy strategy-type="<strategyType>" threshold-type="<thresholdType>" \
threshold-value="<thresholdValue>" max-unavailable="<maxNodesOffline>" \
wait-time-minutes="<waitTimeBetweenRacks>"

Erforderliche Parameter:

• strategy-type: Definiert die Updatestrategie. Die verwendete Einstellung ist (Rack-für-Rack) ODER (Pause für Benutzer bevor jeder Rack startet). Der Standardwert ist . Führen Sie ein Cluster-Laufzeitupgrade mithilfe der Strategie durch, indem Sie die Schritte ausführen, die im Upgrade der Cluster-Laufzeit mit der PauseAfterRack-Strategie beschrieben sind.
• threshold-type: Bestimmt, wie der Schwellenwert ausgewertet werden soll, und wird in den Einheiten angewendet, die durch die Strategie definiert sind. Verwendete Einstellungen sind OR . Der Standardwert ist .
• threshold-value: Der numerische Schwellenwert, der zum Auswerten einer Aktualisierung verwendet wird. Der Standardwert ist .

Optionale Parameter:

• max-unavailable: Die maximale Anzahl von Workerknoten, die offline sein können, d. h. jeweils ein Rack wird aktualisiert. Der Standardwert ist .
• wait-time: Verzögerung oder Wartezeit vor dem Aktualisieren eines Racks. Der Standardwert ist .

Upgradeverhalten basierend auf dem Schwellenwerttyp "PercentSuccess"

Das folgende Beispiel ist für einen Kunden, der die Rack-by-Rack-Strategie mit einer Erfolgsrate von 60 %% und einer 1-minütigen Pause verwendet.

az networkcloud cluster update --name "<CLUSTER>" \
--resource-group "<CLUSTER_RG>" \
--update-strategy strategy-type="Rack" threshold-type="PercentSuccess" \
threshold-value=60 wait-time-minutes=1 \
--subscription "<SUBSCRIPTION>"

Überprüfen von Updates:

az networkcloud cluster show --name "<CLUSTER>" \
--resource-group "<CLUSTER_RG>" \
--subscription "<SUBSCRIPTION>" | grep -A5 updateStrategy

  "updateStrategy": {
    "maxUnavailable": 32767,
      "strategyType": "Rack",
      "thresholdType": "PercentSuccess",
      "thresholdValue": 60,
      "waitTimeMinutes": 1

Sobald in diesem Beispiel 60% der Maschinen in einem Rack erfolgreich aktualisiert wurden, berücksichtigt das System den erreichten Schwellenwert und setzt fort, das nächste Rack zu aktualisieren, während alle verbleibenden Maschinen im aktuellen Rack weiterhin bereitgestellt werden. Wenn der Schwellenwert nicht erreicht wird – was bedeutet, dass weniger als 60% der Computer im Rack upgraden konnten und stattdessen fehlgeschlagen sind, wird das Clusterupgrade angehalten. Wenn ein Upgrade angehalten wird, stellt das System eine detaillierte Statusmeldung im Cluster bereit, die den Grund erklärt. Zu diesem Zeitpunkt müssen die problematischen Maschinen im Rack repariert werden, und ein Vorgang zur Fortsetzung der Aktualisierungsversion des Clusters muss ausgelöst werden, um das Upgrade abzuschließen und fortzusetzen.

Um den Upgradestatus über die Azure portal anzuzeigen, navigieren Sie zur zielbezogenen Clusterressource. Auf dem Bildschirm "Clusterübersicht " wird der detaillierte Status zusammen mit einer detaillierten Statusmeldung bereitgestellt.

Die Clusterbereitstellung ist in Bearbeitung, wenn „detailedStatus“ auf festgelegt ist und „detailedStatusMessage“ den Fortschritt der Bereitstellung anzeigt. Einige Beispiele für den Upgradefortschritt in detailedStatusMessage sind , usw.

Das Clusterupgrade ist abgeschlossen, wenn „detailedStatus“ auf gesetzt ist und „detailedStatusMessage“ die Meldung anzeigt.

Wenn die Meldung "Detaillierter Status" anzeigt, dass das Upgrade angehalten wurde, sieht die Meldung wie folgt aus:

Führen Sie zum Fortsetzen des Laufzeitupgrades den folgenden Az networkcloud cli-Befehl aus.

az networkcloud cluster continue-update-version --cluster-name "<CLUSTER>" \
--resource-group="<CLUSTER_RG>" \
--subscription="<SUBSCRIPTION>"

Upgradeverhalten basierend auf dem Schwellentyp "CountSuccess"

Das folgende Beispiel ist für einen Kunden, der rack-by-Rack-Strategie mit einer Schwellenwertart von 10 Knoten pro Rack und einer Pause von 1 Minuten verwendet.

az networkcloud cluster update --name "<CLUSTER>" \
--resource-group "<CLUSTER_RG>" \
--update-strategy strategy-type="Rack" threshold-type="CountSuccess" \
threshold-value=10 wait-time-minutes=1 \
--subscription "<SUBSCRIPTION>"

Überprüfen von Updates:

az networkcloud cluster show --name "<CLUSTER>" \
--resource-group "<CLUSTER_RG>" \
--subscription "<SUBSCRIPTION>" | grep -A5 updateStrategy

  "updateStrategy": {
    "maxUnavailable": 32767,
      "strategyType": "Rack",
      "thresholdType": "CountSuccess",
      "thresholdValue": 10,
      "waitTimeMinutes": 1

In diesem Beispiel wechselt das Upgrade zum nächsten Rack, wenn mindestens 10 Knoten erfolgreich aktualisiert werden, während die verbleibenden Maschinen im aktuellen Rack weiterhin bereitgestellt werden. Wenn das Upgrade von mindestens 10 Maschinen im Rack fehlschlägt, wird das Clusterupgrade angehalten. In diesem Fall muss die erforderliche Hardware repariert werden, bevor die Aktion zur Weiterführung des Versionsupdates ausgeführt wird, um das Upgrade abzuschließen.

Informationen zur Problembehandlung bei Bare-Metal-Computern finden Sie unter Troubleshoot Azure Operator Nexus Serverprobleme

KCP-Maschinenupgrades

Kubernetes Control Plane (KCP)-Maschinen haben strenge Verfügbarkeitsanforderungen während Laufzeitupgrades. Im Gegensatz zu Computeknoten, bei denen Upgrades fortgesetzt werden können, wenn Schwellenwertanforderungen erfüllt sind, schlägt das Upgrade fehl, wenn KCP-Computer nicht alle erfolgreich bereitgestellt werden können.

Wenn während eines Laufzeitupgrades ein KCP-Computerfehler auftritt:

1. Das Upgrade wird angehalten, und der Cluster tritt in einen fehlgeschlagenen Zustand ein.
2. Die detaillierte Statusmeldung zeigt den Fehlschlag des Steuerungs-Ebene-Upgrades an.
3. Die betroffenen KCP-Maschinen müssen repariert oder ersetzt werden.
4. Nachdem Hardwareprobleme behoben wurden, muss das Upgrade mithilfe des Befehls wie zuvor ausgelöst werden.

Diese strenge Anforderung stellt die Stabilität der Clustersteuerungsebene sicher und verhindert potenzielle Clusterverwaltungsprobleme, die sich aus einer teilweise aktualisierten oder ungesunden Kontrollebene ergeben könnten.

Upgrade der Clusterlaufzeit mit CLI

Um ein Upgrade der Laufzeit auszuführen, verwenden Sie den folgenden Azure CLI Befehl:

az networkcloud cluster update-version --cluster-name "<CLUSTER>" \
--target-cluster-version "<versionNumber>" \
--resource-group "<CLUSTER_RG>" \
--subscription "<SUBSCRIPTION>"

Dieser Befehl initiiert den Laufzeitupgradeprozess für den angegebenen Cluster. Der Befehl selbst wird in der Regel innerhalb von etwa 5 Minuten abgeschlossen, aber dieser Befehl startet nur den Upgradevorgang. Das eigentliche Laufzeit-Upgrade läuft im Hintergrund weiter und kann mehrere Stunden dauern, da es Knoten Rack für Rack aktualisiert und die neue Betriebssystemversion installiert.

Detaillierte Status- und Diagnoseinformationen für den Initiierungsschritt sind in Azure portal in der ressource JSON View der Ressource Cluster (Operator Nexus) verfügbar. Die folgenden Informationen sind im Eintrag des Felds enthalten, wenn Sie die API-Version oder höher verwenden.

• Start- und Endzeit der Aktion.
• Aktueller Status (, oder ).
• Alle zusätzlichen Kontext- oder Fehlermeldungen, die dem aktuellen Status zugeordnet sind.
• Die Korrelations-ID für den ursprünglichen cluster update-version-Vorgang, wie auch im Azure Aktivitätsprotokoll gezeigt.
• Eine sortierte Liste der einzelnen Schritte und deren Status , z. B . und .

Beispielausgabe für die Clusterressource (Operator Nexus):

{
  "properties": {
    "actionStates": [
      {
        "correlationId": "aaaa0000-bb11-2222-33cc-444444dddddd",
        "status": "Completed",
        "actionType": "Microsoft.NetworkCloud/clusters/updateVersion",
        "endTime": "2025-08-01T03:46:13Z",
        "message": "Cluster upgrade to 4.6.0 successfully initiated - monitor progress via cluster detailed status",
        "startTime": "2025-08-01T03:42:08Z",
        "stepStates": [
          {
            "status": "Completed",
            "endTime": "2025-08-01T03:42:08Z",
            "message": "Cluster validation and version checks passed",
            "startTime": "2025-08-01T03:42:08Z",
            "stepName": "Validate Cluster conditions and upgrade versions"
          },
          {
            "status": "Completed",
            "endTime": "2025-08-01T03:46:11Z",
            "message": "Platform Runtime Extension deployment initiated",
            "startTime": "2025-08-01T03:42:39Z",
            "stepName": "Initiate Platform Runtime Extension update"
          },
          {
            "status": "Completed",
            "endTime": "2025-08-01T03:46:11Z",
            "message": "Platform Runtime Extension installation completed",
            "startTime": "2025-08-01T03:46:11Z",
            "stepName": "Monitor Platform Runtime Extension readiness"
          },
          {
            "status": "Completed",
            "endTime": "2025-08-01T03:46:13Z",
            "message": "Platform Cluster version updated successfully",
            "startTime": "2025-08-01T03:46:13Z",
            "stepName": "Update Platform Cluster version specification"
          }
        ]
      }
    ]
  }
}

Sobald dieser Befehl abgeschlossen ist, beginnt der vollständige Laufzeitupgradeprozess. Dieser Vorgang kann je nach Anzahl der Racks im Cluster und der Anzahl der Arbeitsknoten in jedem Rack mehrere Stunden dauern.

• Das Upgrade aktualisiert zuerst die Verwaltungsknoten und dann sequenziell Rack für Rack die Workerknoten.
• Die Verwaltungsserver sind in zwei Gruppen unterteilt, die separat aktualisiert werden. Mit diesem Ansatz können Komponenten, die auf den Verwaltungsservern ausgeführt werden, die Resilienz während des Laufzeitupgrades durch Anwenden von Affinitätsregeln sicherstellen.
• Die CSNs nutzen diese Funktionalität auch, indem sie eine Instanz in jeder Verwaltungsgruppe platzieren.
• Es gibt keine Kundeninteraktion mit dieser Funktionalität. Es können jedoch zusätzliche Bezeichnungen auf Verwaltungsknoten angezeigt werden, um die Gruppen zu identifizieren.

Das Upgrade gilt als abgeschlossen, wenn 80% der Arbeitsknoten pro Rack und 50% der Verwaltungsknoten in jeder Gruppe erfolgreich aktualisiert worden sind. Workloads können beeinträchtigt werden, während sich die Arbeitsknoten in einem Rack im Upgrade befinden, Workloads in allen anderen Racks sind jedoch nicht betroffen. Angesichts dieses Implementierungsdesigns sollte über die Platzierung von Workloads nachgedacht werden.

Das Upgrade aller Knoten dauert mehrere Stunden, je nachdem, wie viele Racks für den Cluster vorhanden sind. Aufgrund der Länge des Upgradevorgangs wird empfohlen, den Detailstatus des Clusters regelmäßig auf den aktuellen Status des Upgrades zu überprüfen. Um den Status des Upgrades zu überprüfen, beobachten Sie den detaillierten Status des Clusters. Diese Prüfung kann über das Portal oder die az CLI erfolgen.

Um den Upgradestatus über die Azure portal anzuzeigen, navigieren Sie zur zielbezogenen Clusterressource. Auf dem Bildschirm "Clusterübersicht " wird der detaillierte Status zusammen mit einer detaillierten Statusmeldung bereitgestellt.

Die Clusterbereitstellung ist in Bearbeitung, wenn „detailedStatus“ auf festgelegt ist und „detailedStatusMessage“ den Fortschritt der Bereitstellung anzeigt. Einige Beispiele für den Upgradefortschritt in detailedStatusMessage sind , usw.

Das Clusterupgrade ist abgeschlossen, wenn „detailedStatus“ auf gesetzt ist und „detailedStatusMessage“ die Meldung anzeigt.

Um den Upgradestatus über die Azure CLI anzuzeigen, verwenden Sie az networkcloud cluster show.

az networkcloud cluster show --cluster-name "<CLUSTER>" \
--resource-group "<CLUSTER_RG>" \
--subscription "<SUBSCRIPTION>"

Die Ausgabe sollte die Informationen des Zielclusters sein, und die detaillierte Status- und Detailstatusmeldung des Clusters sollte vorhanden sein. Für detailliertere Einblicke in den Upgradefortschritt kann der Status der einzelnen Knoten in jedem Rack überprüft werden. Ein Beispiel für die Überprüfung des Status wird im Referenzabschnitt unter BareMetal Machine-Rollenbereitgestellt.

Häufig gestellte Fragen

Identifizieren, ob das Clusterupgrade angehalten wurde/hängen geblieben ist

Während eines Laufzeitupgrades ist es möglich, dass das Upgrade nicht vorwärts ausgeführt wird, aber der detaillierte Status gibt an, dass das Upgrade noch ausgeführt wird. Da das Laufzeitupgrade sehr lange dauern kann, bis es erfolgreich abgeschlossen ist, gibt es zurzeit keine festgelegte Timeoutlänge. Daher empfiehlt es sich, regelmäßig den detaillierten Status Ihres Clusters und Protokolle zu überprüfen, um festzustellen, ob Ihr Upgrade unbegrenzt versucht, ein Upgrade durchzuführen.

Eine -Situation kann festgestellt werden, indem Sie die Protokolle, die detaillierte Nachricht und die detaillierte Statusmeldung des Clusters betrachten. Wenn ein Timeout aufgetreten ist, würden wir beobachten, dass der Cluster sich ununterbrochen abstimmt und nicht vorwärts kommt. Wir empfehlen, die Clusterprotokolle oder die konfigurierte LAW zu überprüfen, um festzustellen, ob es einen Fehler oder ein bestimmtes Upgrade gibt, das die Ursache für den fehlenden Fortschritt ist.

Identifizieren des Bare Metal Machine Upgrades festgefahren/hängen geblieben

Eine Anleitung zum Identifizieren von Problemen mit Bereitstellungs-Workerknoten finden Sie bei der Problembehandlung bei der Bereitstellung von Bare Metal Machine Provisioning.

Hardwarefehler erfordert keine erneute Ausführung des Upgrades

Wenn während eines Upgrades ein Hardwarefehler aufgetreten ist, wird das Laufzeitupgrade fortgesetzt, solange die festgelegten Schwellenwerte für die Compute- und Verwaltungs-/Steuerungsknoten erfüllt sind. Sobald der Computer behoben oder ersetzt wurde, wird er mit dem Betriebssystem der aktuellen Plattform-Runtime bereitgestellt, das die Zielversion der Runtime enthält. Wenn ein Rack vor einem Fehler aktualisiert wurde, wird die aktualisierte Runtimeversion verwendet, wenn die Knoten neu bereitgestellt werden. Wenn die Spezifikation des Racks vor dem Hardwarefehler nicht auf die aktualisierte Laufzeitversion aktualisiert wurde, stellt der Computer die vorherige Laufzeitversion bereit, wenn die Hardware repariert wird. Die Maschine wird zusammen mit dem Rack aktualisiert, wenn das Rack mit dem Upgrade beginnt.

Nach einem Laufzeitupgrade zeigt der Cluster den Bereitstellungsstatus "Fehlgeschlagen" an.

Während eines Laufzeitupgrades wechselt der Cluster in einen Zustand von . Wenn das Laufzeitupgrade fehlschlägt, wechselt der Cluster in einen Bereitstellungszustand. Infrastrukturkomponenten (z. B. die Storage Appliance) können während des Upgrades Zu Fehlern führen. In einigen Szenarien kann es erforderlich sein, den Fehler mit Microsoft support zu diagnostizieren.

Bare Metal Machine wird nach dem Laufzeitupdate als degradiert angezeigt

Bestimmte Situationen können dazu führen, dass ein Knoten in einem Status zurückgegeben wird. Dies kann passieren, wenn eine der Bedingungen in der Problembehandlung für beeinträchtigte Statusfehler erfüllt ist. Herabgestufter Status bedeutet, dass der Knoten automatisch abgebunden wird, um zu verhindern, dass neue Workloads auf dem Knoten geplant werden, bis das zugrunde liegende Problem behoben ist.