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. Instalacja interfejsu wiersza polecenia platformy Azure musi być zainstalowana.
2. Rozszerzenie interfejsu networkcloud wiersza polecenia jest wymagane. networkcloud Jeśli rozszerzenie nie jest zainstalowane, można go zainstalować, wykonując kroki wymienione tutaj.
3. Dostęp do witryny Azure Portal, aby klaster docelowy został uaktualniony.
4. Musisz zalogować się do tej samej subskrypcji co klaster docelowy za pośrednictwem az login
5. Klaster docelowy musi znajdować się w stanie uruchomienia ze wszystkimi węzłami płaszczyzny sterowania w dobrej kondycji i 80% węzłów obliczeniowych w stanie uruchomionym i w dobrej kondycji.

Znajdowanie dostępnych wersji środowiska uruchomieniowego

Za pośrednictwem portalu

Aby znaleźć dostępne wersje środowiska uruchomieniowego z możliwością uaktualnienia, przejdź do klastra docelowego w witrynie Azure Portal. W okienku przeglądu 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 polecenia przejdź do uaktualnienia klastra.

Za pośrednictwem interfejsu wiersza polecenia platformy Azure

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

az networkcloud cluster show --name "clusterName" --resource-group "resourceGroup"

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 będzie pusta.

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 "clusterName" --target-cluster-version
  "versionNumber" --resource-group "resourceGroupName"

Uaktualnienie środowiska uruchomieniowego jest długim procesem. Uaktualnienie najpierw uaktualnia węzły zarządzania, a następnie sekwencyjnie stojak według stojaka dla węzłów roboczych. Uaktualnienie jest uważane za zakończone, gdy 80% węzłów roboczych na stojak i 100% węzłów zarządzania zostało pomyślnie uaktualnionych. Może to mieć wpływ na obciążenia, gdy węzły robocze w stojaku są w trakcie uaktualniania, jednak obciążenia we wszystkich innych stojakach nie będą mieć wpływu. Zachęcamy do rozważenia umieszczania obciążeń w świetle tego projektu implementacji.

Uaktualnienie wszystkich węzłów trwa wiele godzin, ale może potrwać więcej, jeśli inne procesy, takie jak aktualizacje oprogramowania układowego, również są częścią uaktualnienia. Ze względu na długość procesu uaktualniania zaleca się okresowe sprawdzanie stanu szczegółów klastra dla bieżącego stanu uaktualnienia. Aby sprawdzić stan uaktualnienia, sprawdź szczegółowy stan klastra. To 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.

Uaktualnienie klastra jest w toku, gdy parametr detailedStatus jest ustawiony na Updating i szczegółoweStatusMessage pokazuje postęp uaktualniania. Niektóre przykłady postępu uaktualniania pokazane w szczegółowymStatusMessage to Waiting for control plane upgrade to complete..., Waiting for nodepool "<rack-id>" to finish upgrading...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 "clusterName" --resource-group "resourceGroupName"

Dane wyjściowe powinny być informacjami klastra docelowego, a szczegółowy komunikat o stanie i stanie klastra powinien być obecny. Aby uzyskać bardziej szczegółowe informacje na temat postępu uaktualniania, poszczególne elementy BMM w każdym stojaku można sprawdzić pod kątem stanu. Przykład tej funkcji znajduje się w sekcji referencyjnej w obszarze Role maszyny BareMetal.

Konfigurowanie parametrów progu obliczeniowego na potrzeby uaktualniania środowiska uruchomieniowego przy użyciu metody updateStrategy klastra

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 "<clusterName>" /
--resource-group "<resourceGroup>" /
--update-strategy strategy-type="Rack" threshold-type="PercentSuccess" /
threshold-value="<thresholdValue>" max-unavailable=<maxNodesOffline> /
wait-time-minutes=<waitTimeBetweenRacks>

Wymagane parametry:

• typ strategii: definiuje strategię aktualizacji. W takim przypadku "Rack" oznacza, że aktualizacje są wykonywane w stojaku po stojaku. Wartość domyślna to "Rack".
• typ progu: określa sposób obliczania progu w jednostkach zdefiniowanych przez strategię. Wartość domyślna to "PercentSuccess".
• threshold-value: wartość progowa liczbowa używana do oceny aktualizacji. Wartość domyślna to 80.

Parametry opcjonalne:

• maksymalna niedostępność: maksymalna liczba węzłów roboczych, które mogą być w trybie offline, czyli uaktualniony stojak naraz. Wartość domyślna to 32767.
• wait-time-minutes: Opóźnienie lub okres oczekiwania przed aktualizacją stojaka. Wartość domyślna to 15.

Przykładowe użycie polecenia jest następujące:

az networkcloud cluster update --name "cluster01" --resource-group "cluster01-rg" --update-strategy strategy-type="Rack" threshold-type="PercentSuccess" threshold-value=70 max-unavailable=16 wait-time-minutes=15

Po pomyślnym wykonaniu polecenia określone wartości updateStrategy zostaną zastosowane do klastra:

    "updateStrategy": {
      "maxUnavailable": 16,
      "strategyType": "Rack",
      "thresholdType": "PercentSuccess",
      "thresholdValue": 70,
      "waitTimeMinutes": 15,
    }

Uwaga

Po ustawieniu wartości progowej poniżej 100% możliwe jest, że wszystkie węzły w złej kondycji nie zostaną uaktualnione, ale stan "Klaster" nadal może wskazywać, że uaktualnienie zakończyło się pomyślnie. Aby rozwiązać problemy z maszynami bez systemu operacyjnego, zapoznaj się z tematem Rozwiązywanie problemów z serwerem Nexus operatora platformy Azure

Uaktualnianie za pomocą strategii PauseRack

Począwszy od interfejsu API w wersji 2024-06-01-preview, uaktualnienia środowiska uruchomieniowego można wyzwolić przy użyciu strategii "PauseRack". Po wykonaniu uaktualnienia środowiska uruchomieniowego klastra ze strategią PauseRack zaktualizuje jeden stojak naraz w klastrze, a następnie zatrzyma się, czekając na potwierdzenie przed przejściem do następnego stojaka. Wszystkie istniejące progi będą nadal uwzględniane ze strategią "PauseRack". Aby przeprowadzić uaktualnienie środowiska uruchomieniowego klastra przy użyciu strategii "PauseRack", wykonaj kroki opisane w temacie Uaktualnianie środowiska uruchomieniowego klastra ze strategią wstrzymania stojaka

Często zadawane pytania

Identyfikowanie uaktualnienia klastra zablokowanego/zablokowanego

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 stanu szczegółów klastra i dzienników w celu ustalenia, czy uaktualnienie jest na czas nieokreślony, próbując uaktualnić.

Możemy określić, kiedy tak jest, przeglądając dzienniki klastra, szczegółowy komunikat i szczegółowy komunikat o stanie. Jeśli wystąpiło przekroczenie limitu czasu, zauważylibyśmy, że klaster jest stale uzgadniany przez ten sam czas w nieskończoność, a nie w przyszłości. 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.

Awaria sprzętowa nie wymaga ponownego wykonania uaktualnienia

Jeśli wystąpił błąd sprzętowy podczas uaktualniania, uaktualnienie środowiska uruchomieniowego będzie kontynuowane tak długo, jak długo 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 wystąpi awaria sprzętowa, a uaktualnienie środowiska uruchomieniowego nie powiodło się, ponieważ progi nie zostały spełnione dla węzłów obliczeniowych i kontrolnych, ponowne wykonanie uaktualnienia środowiska uruchomieniowego może być konieczne w zależności od tego, kiedy wystąpił błąd i stan poszczególnych serwerów w stojaku. Jeśli stojak został zaktualizowany przed awarią, uaktualniona wersja środowiska uruchomieniowego zostanie użyta podczas ponownego aprowizacji węzłów. Jeśli specyfikacja stojaka nie została zaktualizowana do uaktualnionej wersji środowiska uruchomieniowego przed awarią sprzętu, maszyna zostanie aprowizowana przy użyciu poprzedniej wersji środowiska uruchomieniowego. Aby uaktualnić do nowej wersji środowiska uruchomieniowego, prześlij nowe żądanie uaktualnienia klastra i uaktualnij tylko węzły z poprzednią wersją środowiska uruchomieniowego. Hosty, które zakończyły się powodzeniem w poprzedniej akcji uaktualnienia, nie będą.

Po uaktualnieniu środowiska uruchomieniowego klaster ma stan aprowizacji "Niepowodzenie"

Podczas uaktualniania środowiska uruchomieniowego klaster wprowadza stan Upgrading. W przypadku awarii uaktualnienia środowiska uruchomieniowego klaster przejdzie do Failed stanu aprowizacji. Błędy podczas uaktualniania mogą być spowodowane przez składniki infrastruktury (np. urządzenie magazynu). W niektórych scenariuszach może być konieczne diagnozowanie niepowodzenia z pomocą techniczną firmy Microsoft.

Wpływ na obciążenia dzierżawy rozwiązania Nexus Kubernetes podczas uaktualniania środowiska uruchomieniowego klastra

Podczas uaktualniania środowiska uruchomieniowego węzły klastra Nexus Kubernetes są odprowadzane i opróżniane przed uaktualnieniem hostów bez systemu operacyjnego (BMH). Cordoning węzeł klastra Kubernetes uniemożliwia zaplanowanie na nim nowych zasobników i opróżnianie węzła klastra Kubernetes umożliwia zasobnikom z uruchomionymi obciążeniami dzierżawy możliwość przejścia do innego dostępnego węzła klastra Kubernetes, co pomaga zmniejszyć wpływ na usługi. Skuteczność mechanizmu opróżniania zależy od dostępnej pojemności w klastrze Kubernetes Nexus. Jeśli klaster Kubernetes zbliża się do pełnej pojemności i nie ma miejsca na przeniesienie zasobników, przechodzą do stanu Oczekujące po procesie opróżniania.

Po zakończeniu procesu cordonu i opróżniania węzła klastra dzierżawy następuje uaktualnienie BMH. Każdy węzeł klastra dzierżawy może potrwać do 10 minut, po którym rozpocznie się uaktualnianie BMH. Gwarantuje to postęp uaktualniania BMH. BMHs są uaktualniane jeden stojak naraz, a uaktualnienia są wykonywane równolegle w tym samym stojaku. Uaktualnienie BMH nie czeka na przejście zasobów dzierżawy do trybu online przed kontynuowaniem uaktualniania BMHs w stojaku. Zaletą jest to, że maksymalny całkowity czas oczekiwania na uaktualnienie stojaka jest utrzymywany przez 10 minut niezależnie od liczby dostępnych węzłów. Ten maksymalny czas oczekiwania jest specyficzny dla procedury kordonu i opróżniania i nie jest stosowany do ogólnej procedury uaktualniania. Po zakończeniu każdego uaktualnienia BMH węzeł klastra Nexus Kubernetes uruchamia się, ponownie dołącza do klastra i jest niekordonowany, co umożliwia zaplanowanie zasobników na węźle po raz kolejny.

Należy pamiętać, że węzeł klastra Nexus Kubernetes nie zostanie zamknięty po zakończeniu procesu cordonu i opróżniania. BMH jest ponownie uruchamiany z nowym obrazem, gdy tylko wszystkie węzły klastra Nexus Kubernetes są cordoned i opróżniane, po 10 minutach, jeśli proces opróżniania nie zostanie ukończony. Ponadto kordon i opróżnianie nie są inicjowane dla akcji zasilania lub ponownego uruchomienia BMH; Jest on aktywowany wyłącznie podczas uaktualniania środowiska uruchomieniowego.

Należy pamiętać, że po uaktualnieniu środowiska uruchomieniowego może istnieć wystąpienie, w którym węzeł klastra Kubernetes Nexus pozostaje cordoned. W takim scenariuszu można ręcznie usunąć z węzła, wykonując następujące polecenie

az networkcloud baremetalmachine list -g $mrg --subscription $sub --query "sort_by([].{name:name,kubernetesNodeName:kubernetesNodeName,location:location,readyState:readyState,provisioningState:provisioningState,detailedStatus:detailedStatus,detailedStatusMessage:detailedStatusMessage,powerState:powerState,tags:tags.Status,machineRoles:join(', ', machineRoles),cordonStatus:cordonStatus,createdAt:systemData.createdAt}, &name)" 
--output table