Uaktualnianie środowiska uruchomieniowego klastra z poziomu interfejsu wiersza polecenia platformy Azure

W tym przewodniku z instrukcjami opisano kroki instalowania wymaganego interfejsu wiersza polecenia platformy Azure i rozszerzeń wymaganych do interakcji z operatorem Nexus.

Wymagania wstępne

1. Zainstaluj najnowszą wersję odpowiednich rozszerzeń CLI.
2. Wymagane jest najnowsze networkcloud rozszerzenie interfejsu wiersza polecenia. Można go zainstalować, wykonując kroki wymienione tutaj.
3. Dostęp subskrypcyjny do uruchamiania poleceń rozszerzenia CLI dla struktury sieci Azure Operator Nexus (NF) i sieci w chmurze (NC).
4. Zbierz następujące informacje:
   • Identyfikator subskrypcji (SUBSCRIPTION)
   • Nazwa klastra (CLUSTER)
   • Grupa zasobów (CLUSTER_RG)
5. Stan szczegółowy klastra musi mieć wartość Running.
6. Łączność klastra z menedżerem klastra musi mieć wartość Connected.
7. Serwery obliczeniowe klastra obciążenia >>
   • Trzy z czterech węzłów płaszczyzny sterowania muszą mieć stan Onzasilania, stan Uncordonedcordonu, stan Yesgotowości i obniżoną sprawność No.
     • Zapasowy węzeł płaszczyzny sterowania powinien być w stanie Off zasilania, No gotowości i No obniżonej wydajności.
   • Serwery płaszczyzny zarządzania są podzielone na dwie grupy umieszczone na regałach o nieparzystych i parzystych numerach. Dla każdej grupy co najmniej połowa serwerów musi być w stanie zasilania On, stanie Kordonu Uncordoned, stanie gotowości Yes i stanie degradowanym No.
     • Zaleca się utrzymywanie dostępności ponad 50% serwerów warstwy zarządzania w celu ograniczenia ryzyka.
   • Liczby serwerów płaszczyzny obliczeniowej różnią się w zależności od poszczególnych ustawień progu środowiska uruchomieniowego klastra. Klienci muszą określić minimalną liczbę na podstawie ustawień, szukając stanu On zasilania, stanu Uncordoned cordonu, stanu Yes gotowości oraz stanu No obniżonej wydajności.
8. W obszarze Grupa zasobów zarządzanych przez klaster > wybierz nazwę grupy, aby przejść do strony grupy zasobów.
   • W grupie zasobów wyszukaj Kubernetes - Azure Arc , aby zidentyfikować informacje usługi Azure Arc i wybrać je. Stan powinien mieć wartość Connected.
     • Na stronie usługi Azure Arc wybierz pozycję Rozszerzenia ustawień > .
       • nc-platform-extension powinien mieć stan Succeeded.
     • nc-platform-runtime-extension powinien mieć stan Succeeded.

Sprawdzanie bieżącej wersji środowiska uruchomieniowego

Sprawdź bieżącą wersję środowiska uruchomieniowego klastra przed uaktualnieniem: Jak sprawdzić bieżącą wersję środowiska uruchomieniowego klastra.

Znajdowanie dostępnych wersji środowiska uruchomieniowego

Za pośrednictwem witryny Azure Portal

Aby znaleźć dostępne wersje środowiska uruchomieniowego z możliwością uaktualnienia, przejdź do docelowego klastra w witrynie Azure Portal. W okienku Przegląd klastra przejdź do karty Dostępne wersje uaktualnienia .

Na karcie Dostępne wersje uaktualnienia możemy wyświetlić różne wersje klastra, które są obecnie dostępne do uaktualnienia. Operator może wybrać z listy docelowych wersji środowiska uruchomieniowego. Po wybraniu przystąp do aktualizacji klastra.

Przez Azure CLI

Dostępne uaktualnienia można pobierać za pośrednictwem interfejsu wiersza polecenia platformy Azure:

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

W danych wyjściowych możesz znaleźć availableUpgradeVersions właściwość i spojrzeć na targetClusterVersion pole:

  "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"
    }
  ],

Jeśli nie ma dostępnych uaktualnień klastra, lista jest pusta.

Skonfiguruj parametry progu obliczeniowego dla aktualizacji środowiska uruchomieniowego przy użyciu klastra updateStrategy

Następujące polecenie interfejsu wiersza polecenia platformy Azure służy do konfigurowania parametrów progu obliczeniowego dla uaktualnienia środowiska uruchomieniowego:

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>"

Wymagane parametry:

• typ strategii: definiuje strategię aktualizacji. Używane ustawienia to Rack (Rack-by-Rack) LUB PauseAfterRack (Pauza dla użytkownika przed rozpoczęciem każdego cyklu stojaka). Domyślna wartość to Rack. Aby przeprowadzić uaktualnienie środowiska uruchomieniowego klastra przy użyciu PauseAfterRack strategii, wykonaj kroki opisane w temacie Upgrade Cluster Runtime with PauseAfterRack Strategy (Uaktualnianie środowiska uruchomieniowego klastra za pomocą strategii PauseAfterRack).
• typ progu: określa sposób obliczania progu w jednostkach zdefiniowanych przez strategię. Używane ustawienia to PercentSuccess LUB CountSuccess. Domyślna wartość to PercentSuccess.
• threshold-value: wartość progowa liczbowa używana do oceny aktualizacji. Domyślna wartość to 80.

Parametry opcjonalne:

• maksymalna niedostępność: maksymalna liczba węzłów roboczych, które mogą być w trybie offline, czyli szafa serwerowa uaktualniana jednocześnie. Domyślna wartość to 32767.
• czas-oczekiwania-minuty: Opóźnienie lub okres oczekiwania przed aktualizacją stojaka. Domyślna wartość to 15.

Poniższy przykład dotyczy klienta korzystającego ze strategii Rack-by-Rack z Procentem Sukcesu 60% i 1-minutową przerwą.

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>"

Sprawdź aktualizację:

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

W tym przykładzie, jeśli mniej niż 60% węzłów obliczeniowych aprowizowanych w stojaku nie powiedzie się (na zasadzie każdego stojaka), uaktualnienie klastra czeka na czas nieokreślony do momentu spełnienia warunku. Jeśli 60% lub więcej węzłów obliczeniowych zostanie pomyślnie przydzielonych, wdrożenie klastra przechodzi do następnej szafy węzłów obliczeniowych. Jeśli w stojaku występuje zbyt wiele awarii, należy naprawić sprzęt, aby można było kontynuować uaktualnianie.

Poniższy przykład dotyczy klienta używającego strategii "rack-by-rack" z typem progu wynoszącym 10 węzłów na każdy stojak oraz 1-minutową przerwą.

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>"

Sprawdź aktualizację:

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

W tym przykładzie, jeśli aprowizacja mniej niż 10 węzłów obliczeniowych w stojaku zakończy się niepowodzeniem (na zasadzie Stojak-po-Stojaku), uaktualnienie klastra będzie czekać bezterminowo, aż warunek zostanie spełniony. Jeśli zostanie pomyślnie aprowizowanych co najmniej 10 węzłów obliczeniowych, wdrożenie klastra przechodzi do następnej szafy węzłów obliczeniowych. Jeśli w stojaku występuje zbyt wiele awarii, należy naprawić sprzęt, aby można było kontynuować uaktualnianie.

Uaktualnianie środowiska uruchomieniowego klastra przy użyciu interfejsu wiersza polecenia

Aby przeprowadzić uaktualnienie środowiska uruchomieniowego, użyj następującego polecenia interfejsu wiersza polecenia platformy Azure:

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

To polecenie inicjuje proces uaktualniania środowiska uruchomieniowego dla określonego klastra. Samo polecenie zwykle kończy się w ciągu około 5 minut, ale to polecenie uruchamia tylko proces uaktualniania. Rzeczywiste uaktualnienie środowiska uruchomieniowego jest nadal wykonywane w tle i może potrwać kilka godzin, ponieważ uaktualnia stojak węzłów według stojaka i instaluje nową wersję systemu operacyjnego.

Szczegółowe informacje o stanie i diagnostyce dla kroku inicjowania są dostępne w witrynie Azure Portal w JSON View zasobie klastra (Operator Nexus). Poniższe informacje znajdują się we wpisie updateVersion pola w przypadku korzystania z wersji interfejsu properties.actionStates API lub nowszej 2025-07-01-preview .

• Godzina rozpoczęcia i zakończenia akcji.
• Bieżący stan (Succeeded, Failed, lub InProgress).
• Dowolny dodatkowy kontekst lub komunikat o błędzie skojarzony z bieżącym stanem.
• Identyfikator korelacji dla oryginalnej cluster update-version operacji, jak pokazano również w dzienniku aktywności platformy Azure.
• Uporządkowana lista poszczególnych kroków i ich stan — na przykład Validate Cluster conditions and upgrade versions, i Initiate Platform Runtime Extension update.

Przykładowy JSON View wynik dla zasobu klastra (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"
          }
        ]
      }
    ]
  }
}

Po zakończeniu tego polecenia rozpocznie się proces uaktualniania pełnego środowiska uruchomieniowego. Ten proces może potrwać kilka godzin, w zależności od liczby stojaków w klastrze i liczby węzłów roboczych w każdym stojaku.

• Aktualizacja najpierw uaktualnia węzły zarządzania, a następnie sekwencyjnie stelaż po stelażu dla węzłów roboczych.
• Serwery zarządzania są podzielone na dwie grupy, które są uaktualniane oddzielnie. Takie podejście umożliwia korzystanie ze składników działających na serwerach zarządzania w celu zapewnienia odporności podczas uaktualniania środowiska uruchomieniowego przez zastosowanie reguł koligacji.
• Nazwy CDN korzystają również z tej funkcji, umieszczając jedno wystąpienie w każdej grupie zarządzania.
• Nie ma interakcji klienta z tą funkcją. Jednak w węzłach zarządzania mogą być widoczne dodatkowe etykiety umożliwiające zidentyfikowanie grup.

Uaktualnienie jest uważane za zakończone, gdy 80% węzłów roboczych na regał i 50% węzłów zarządzania w każdej grupie zostaną pomyślnie uaktualnione. Może to mieć wpływ na obciążenie, gdy węzły robocze w jednym stojaku są w trakcie aktualizacji, natomiast nie ma to wpływu na obciążenia we wszystkich innych stojakach. Zachęcamy do rozważenia umieszczania obciążeń w świetle tego projektu implementacji.

Aktualizowanie wszystkich węzłów trwa wiele godzin, w zależności od liczby szaf w klastrze. Ze względu na długość procesu uaktualniania stan szczegółów klastra powinien być okresowo sprawdzany pod kątem bieżącego stanu uaktualnienia. Aby sprawdzić stan uaktualnienia, sprawdź szczegółowy stan klastra. Sprawdzenie można wykonać za pośrednictwem portalu lub AZ CLI.

Aby wyświetlić stan uaktualnienia za pośrednictwem witryny Azure Portal, przejdź do docelowego zasobu klastra. Na ekranie Przegląd klastra wyświetlany jest szczegółowy stan wraz ze szczegółowym komunikatem o stanie.

Uaktualnianie klastra jest w toku, gdy parametr detailedStatus jest ustawiony na Updating, a szczegółowy status pokazuje postęp aktualizacji. Niektóre przykłady postępu uaktualniania pokazanego w szczegółowychStatusMessage to Waiting for control plane upgrade to complete..., Waiting for nodepool "<rack-id>" to finish upgrading..., i itp.

Uaktualnianie klastra zostało ukończone, gdy parametr detailedStatus jest ustawiony na Running , a element detailedStatusMessage wyświetla komunikat Cluster is up and running

Aby wyświetlić stan uaktualnienia za pośrednictwem interfejsu wiersza polecenia platformy Azure, użyj polecenia az networkcloud cluster show.

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

Wynik powinien zawierać informacje o docelowym klastrze, a szczegóły dotyczące statusu i szczegółowy komunikat o stanie powinny być uwzględnione. Aby uzyskać bardziej szczegółowe informacje na temat postępu uaktualniania, poszczególne węzły w każdym stojaku można sprawdzić pod kątem stanu. Przykład sprawdzania stanu znajduje się w sekcji referencyjnej w obszarze Role maszyny BareMetal.

Często zadawane pytania

Rozpoznawanie utknięcia/zatrzymania uaktualnienia klastra

Podczas uaktualniania środowiska uruchomieniowego uaktualnienie może zakończyć się niepowodzeniem, ale stan szczegółów odzwierciedla, że uaktualnienie jest nadal w toku. Ponieważ ukończenie uaktualnienia środowiska uruchomieniowego może zająć bardzo dużo czasu, obecnie nie określono ustawionej długości limitu czasu. W związku z tym zaleca się również okresowe sprawdzanie szczegółowego statusu klastra i dzienników, aby ustalić, czy uaktualnienie próbuje nieustannie się aktualizować.

Możemy zidentyfikować indefinitely attempting to upgrade sytuację, przeglądając logi klastra, szczegółową wiadomość i szczegółową wiadomość o stanie. Jeśli wystąpi przekroczenie limitu czasu, zauważymy, że klaster jest stale uzgadniany przez ten sam czas i nie przechodzi do przodu. W tym miejscu zalecamy sprawdzenie dzienników klastra lub skonfigurowanie usługi LAW, aby sprawdzić, czy wystąpił błąd, czy konkretne uaktualnienie powoduje brak postępu.

Identyfikacja zatrzymanej/zablokowanej aktualizacji układu bare metal

Przewodnik po identyfikowaniu problemów z aprowizowaniem węzłów procesu roboczego znajduje się w części Rozwiązywanie problemów z aprowizowaniem maszyn bez systemu operacyjnego.

Awaria sprzętowa nie wymaga ponownego wykonania uaktualnienia

Jeśli wystąpi awaria sprzętowa podczas uaktualniania, uaktualnienie środowiska uruchomieniowego będzie kontynuowane tak długo, jak są spełnione określone progi dla węzłów obliczeniowych i zarządzania/sterowania. Po naprawieniu lub zastąpieniu maszyny zostanie ona aprowizowana przy użyciu systemu operacyjnego bieżącego środowiska uruchomieniowego platformy, który zawiera docelową wersję środowiska uruchomieniowego. Jeśli szafa została zaktualizowana przed awarią, zaktualizowana wersja środowiska wykonawczego zostanie użyta przy ponownej aprowizacji węzłów. Jeśli specyfikacja stojaka nie została zaktualizowana do uaktualnionej wersji środowiska uruchomieniowego przed awarią sprzętu, maszyna aprowizuje poprzednią wersję środowiska uruchomieniowego po naprawie sprzętu. Maszyna jest uaktualniana wraz z stojakiem, gdy stojak rozpocznie uaktualnianie.

Po uaktualnieniu środowiska uruchomieniowego klaster wyświetla stan "Niepowodzenie" w trakcie wdrażania.

Podczas uaktualniania środowiska uruchomieniowego klaster wprowadza stan Upgrading. Jeśli uaktualnienie środowiska uruchomieniowego zakończy się niepowodzeniem, klaster przejdzie w stan przygotowania. Składniki infrastruktury (np. urządzenie magazynu) mogą powodować błędy podczas uaktualniania. W niektórych scenariuszach może być konieczne diagnozowanie niepowodzenia z pomocą techniczną firmy Microsoft.