Upgrade der Clusterlaufzeit von Azure CLI

In dieser Anleitung 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 networkcloud CLI-Erweiterung ist erforderlich. Sie kann nach den hier aufgeführten Schritten installiert werden.
3. Abonnementzugriff zum Ausführen der CLI-Erweiterungsbefehle für das Azure Operator Nexus Network Fabric (NF) und die Netzwerk-Cloud (NC).
4. Sammeln Sie die folgenden Informationen:
   • Abonnement-ID (SUBSCRIPTION)
   • Clustername (CLUSTER)
   • Ressourcengruppe (CLUSTER_RG)
5. Der detaillierte Clusterstatus muss sein Running.
6. Cluster-zu-Cluster-Manager-Konnektivität muss sein Connected.
7. Unter Clusterworkload-Computeservern >>
   • Drei von vier Steuerebenenknoten müssen den Energiezustand On, den Cordon-Status Uncordoned, den Zustand "Bereit" Yesund "Herabgestuft No" aufweisen.
     • Der Knoten "Ersatzsteuerungsebene" sollte sich im Zustand "Power" Off, "Ready" Nound "Degraded No" 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 On, Cordon-Status Uncordoned, Ready-Zustand Yes und Degraded-Zustand No 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 On, Cordon-Status Uncordoned, Bereit-Zustand Yes und Herabgestuft No suchen.
8. 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 wählen Sie diese aus. Der Status sollte sein Connected.
     • Wählen Sie auf der Seite 'Azure Arc' die Optionen 'Einstellungen' und 'Erweiterungen' > aus.
       • nc-platform-extension sollte sich im Status Succeededbefinden.
     • nc-platform-runtime-extension sollte sich im Status Succeededbefinden.

Überprüfen der aktuellen Laufzeitversion

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

Suchen aller verfügbaren Runtimeversionen

Verwenden des Azure-Portals

Um verfügbare upgradefähige Laufzeitversionen zu finden, navigieren Sie zum Zielcluster im Azure-Portal. 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.

Über Azure-Befehlszeilenschnittstelle

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 availableUpgradeVersions-Eigenschaft. Sehen Sie sich das Feld targetClusterVersion 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 von Rechenschwellenwerten für das Upgrade der Laufzeitumgebung mithilfe von Cluster updateStrategy

Der folgende Azure CLI-Befehl wird verwendet, um die Computeschwellenwerte für ein Runtimeupgrade zu konfigurieren:

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

Erforderliche Parameter:

• strategy-type: Definiert die Updatestrategie. Die verwendete Einstellung ist Rack (Rack-für-Rack) ODER PauseAfterRack (Pause für Benutzer bevor jeder Rack startet). Der Standardwert ist Rack. Führen Sie ein Cluster-Laufzeitupgrade mithilfe der PauseAfterRack 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 PercentSuccess OR CountSuccess. Der Standardwert ist PercentSuccess.
• threshold-value: Der numerische Schwellenwert, der zum Auswerten einer Aktualisierung verwendet wird. Der Standardwert ist 80.

Optionale Parameter:

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

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

Wenn in diesem Beispiel weniger als 60 % der in einem Rack bereitgestellten Computeknoten nicht bereitgestellt werden (auf Rack-by-Rack-Basis), wartet das Clusterupgrade unbegrenzt, bis die Bedingung erfüllt ist. Wenn mindestens 60 % der Computeknoten erfolgreich bereitgestellt werden, wird die Clusterbereitstellung mit dem nächsten Rack mit Computeknoten fortgesetzt. Wenn zu viele Fehler im Rack auftreten, muss die Hardware repariert werden, bevor das Upgrade fortgesetzt werden kann.

Das folgende Beispiel ist für einen Kunden, der rack-by-Rack-Strategie mit einer Schwellenwertart CountSuccess 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

Wenn in diesem Beispiel weniger als 10 Computeknoten, die in einem Rack bereitgestellt werden, nicht bereitgestellt werden (auf Rack-by-Rack-Basis), wartet das Clusterupgrade unbegrenzt, bis die Bedingung erfüllt ist. Wenn mindestens 10 Computeknoten erfolgreich bereitgestellt werden, wird die Clusterbereitstellung mit dem nächsten Rack mit Computeknoten fortgesetzt. Wenn zu viele Fehler im Rack auftreten, muss die Hardware repariert werden, bevor das Upgrade fortgesetzt werden kann.

Upgrade der Clusterlaufzeit mit CLI

Verwenden Sie den folgenden Azure CLI-Befehl, um ein Upgrade der Runtime auszuführen:

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 im Azure-Portal in JSON View der Ressource Cluster (Operator Nexus) verfügbar. Die folgenden Informationen sind im updateVersion Eintrag des properties.actionStates Felds enthalten, wenn Sie die API-Version 2025-07-01-preview oder höher verwenden.

• Start- und Endzeit der Aktion.
• Aktueller Status (Succeeded, Failedoder InProgress).
• 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 Activity-Protokoll dargestellt.
• Eine sortierte Liste der einzelnen Schritte und deren Status , z. B Validate Cluster conditions and upgrade versions. und Initiate Platform Runtime Extension update.

Beispielausgabe JSON View für die Clusterressource (Operator Nexus):

{
  "properties": {
    "actionStates": [
      {
        "correlationId": "b66643b7-2e1d-4a5c-a954-ca0e38368984",
        "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 das 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 Updating festgelegt ist und „detailedStatusMessage“ den Fortschritt der Bereitstellung anzeigt. Einige Beispiele für den Upgradefortschritt in detailedStatusMessage sind Waiting for control plane upgrade to complete..., Waiting for nodepool "<rack-id>" to finish upgrading... usw.

Das Clusterupgrade ist abgeschlossen, wenn „detailedStatus“ auf Running gesetzt ist und „detailedStatusMessage“ die Meldung Cluster is up and running anzeigt.

Verwenden Sie az networkcloud cluster show, um den Upgradestatus über die Azure CLI anzuzeigen.

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 Runtime-Upgrades kann es vorkommen, dass das Upgrade nicht fortgesetzt wird, der Detailstatus aber anzeigt, dass das Upgrade noch läuft. Da das Laufzeitupgrade sehr lange dauern kann, bis es erfolgreich abgeschlossen ist, gibt es zurzeit keine festgelegte Timeoutlänge. Daher ist es ratsam, auch regelmäßig den Detailstatus und die Protokolle Ihres Clusters zu überprüfen, um zu ermitteln, ob Ihr Upgrade unbegrenzt versucht, ein Upgrade durchzuführen.

Eine indefinitely attempting to upgrade-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 Upgrading. Wenn das Laufzeitupgrade fehlschlägt, wechselt der Cluster in einen Failed Bereitstellungszustand. Infrastrukturkomponenten (z. B. die Storage Appliance) können während des Upgrades Fehler verursachen. In einigen Szenarien kann es erforderlich sein, den Fehler mit dem Microsoft-Support zu diagnostizieren.