Tworzenie i aprowizuj klaster przy użyciu interfejsu wiersza polecenia platformy Azure

W tym artykule opisano sposób tworzenia klastra przy użyciu interfejsu wiersza polecenia platformy Azure (AzCLI). W tym dokumencie pokazano również, jak sprawdzić stan, aktualizację lub usunąć klaster.

Wymagania wstępne

• Sprawdź, czy kontroler sieci szkieletowej i menedżer klastra istnieją w regionie świadczenia usługi Azure
• Sprawdź, czy sieć szkieletowa sieci szkieletowej została pomyślnie aprowizowana

Przewodnik i metryki interfejsu API

Przewodnik po interfejsie API zawiera informacje na temat dostawców zasobów i modeli zasobów oraz interfejsów API.

Metryki wygenerowane na podstawie danych rejestrowania są dostępne w metrykach usługi Azure Monitor.

Ograniczenia

• Nazewnictwo — reguły nazewnictwa można znaleźć tutaj.

Tworzenie klastra

Zasób klastra infrastruktury reprezentuje lokalne wdrożenie platformy w Menedżerze klastra. Wszystkie inne zasoby specyficzne dla platformy są zależne od niego na potrzeby ich cyklu życia.

Przed wdrożeniem lokalnym należy utworzyć sieć szkieletową sieci szkieletowej. Każde wystąpienie lokalne Operatora Nexus ma jedno do jednego skojarzenia z siecią szkieletową sieci szkieletowej.

Utwórz klaster przy użyciu interfejsu wiersza polecenia platformy Azure:

az networkcloud cluster create --name "$CLUSTER_NAME" --location "$LOCATION" \
  --extended-location name="$CL_NAME" type="CustomLocation" \
  --resource-group "$CLUSTER_RG" \
  --analytics-workspace-id "$LAW_ID" \
  --cluster-location "$CLUSTER_LOCATION" \
  --network-rack-id "$AGGR_RACK_RESOURCE_ID" \
  --rack-sku-id "$AGGR_RACK_SKU"\
  --rack-serial-number "$AGGR_RACK_SN" \
  --rack-location "$AGGR_RACK_LOCATION" \
  --bare-metal-machine-configuration-data "["$AGGR_RACK_BMM"]" \
  --storage-appliance-configuration-data '[{"adminCredentials":{"password":"$SA_PASS","username":"$SA_USER"},"rackSlot":1,"serialNumber":"$SA_SN","storageApplianceName":"$SA_NAME"}]' \
  --compute-rack-definitions '[{"networkRackId": "$COMPX_RACK_RESOURCE_ID", "rackSkuId": "$COMPX_RACK_SKU", "rackSerialNumber": "$COMPX_RACK_SN", "rackLocation": "$COMPX_RACK_LOCATION", "storageApplianceConfigurationData": [], "bareMetalMachineConfigurationData":[{"bmcCredentials": {"password":"$COMPX_SVRY_BMC_PASS", "username":"$COMPX_SVRY_BMC_USER"}, "bmcMacAddress":"$COMPX_SVRY_BMC_MAC", "bootMacAddress":"$COMPX_SVRY_BOOT_MAC", "machineDetails":"$COMPX_SVRY_SERVER_DETAILS", "machineName":"$COMPX_SVRY_SERVER_NAME"}]}]'\
  --managed-resource-group-configuration name="$MRG_NAME" location="$MRG_LOCATION" \
  --network fabric-id "$NF_ID" \
  --cluster-service-principal application-id="$SP_APP_ID" \
    password="$SP_PASS" principal-id="$SP_ID" tenant-id="$TENANT_ID" \
  --subscription "$SUBSCRIPTION_ID" \
  --secret-archive "{key-vault-id:$KVRESOURCE_ID, use-key-vault:true}" \
  --cluster-type "$CLUSTER_TYPE" --cluster-version "$CLUSTER_VERSION" \
  --tags $TAG_KEY1="$TAG_VALUE1" $TAG_KEY2="$TAG_VALUE2"

Parametry dla operacji klastra

Nazwa parametru	opis
CLUSTER_NAME	Nazwa zasobu klastra
LOKALIZACJA	Region świadczenia usługi Azure, w którym wdrożono klaster
CL_NAME	Lokalizacja niestandardowa Menedżera klastra w witrynie Azure Portal
CLUSTER_RG	Nazwa grupy zasobów klastra
LAW_ID	Identyfikator obszaru roboczego usługi Log Analytics dla klastra
CLUSTER_LOCATION	Lokalna nazwa klastra
AGGR_RACK_RESOURCE_ID	RackID dla stojaka agregatora
AGGR_RACK_SKU	Jednostka SKU stojaka dla stojaka agregatora *Zobacz Operator Nexus jednostki SKU chmury sieciowej
AGGR_RACK_SN	Numer seryjny stojaka dla stojaka agregatora
AGGR_RACK_LOCATION	Lokalizacja fizyczna stojaka dla stojaka agregatora
AGGR_RACK_BMM	Używane tylko do wdrażania w jednym stojaku, puste dla wielu stojaków
SA_NAME	Nazwa urządzenia magazynu
SA_PASS	Hasło administratora urządzenia magazynu
SA_USER	Administrator urządzenia magazynu
SA_SN	Numer seryjny urządzenia magazynu
COMPX_RACK_RESOURCE_ID	RackID dla regałów CompX; powtórzenie dla każdego stojaka w definicjach compute-rack
COMPX_RACK_SKU	Jednostka SKU stojaka dla stojaka CompX; powtórz dla każdego stojaka w definicjach compute-rack-definition *Zobacz Operator Nexus Network Cloud SKU
COMPX_RACK_SN	Numer seryjny stojaka dla stojaka CompX; powtórzenie dla każdego stojaka w definicjach compute-rack
COMPX_RACK_LOCATION	Lokalizacja fizyczna stojaka dla stojaka CompX; powtórzenie dla każdego stojaka w definicjach compute-rack
COMPX_SVRY_BMC_PASS	CompX Rack Servery Baseboard Management Controller (BMC) hasło; powtórz dla każdego stojaka w definicjach compute-rack i dla każdego serwera w stojaku
COMPX_SVRY_BMC_USER	CompX Rack Servery BMC użytkownika; powtórz dla każdego stojaka w definicjach compute-rack i dla każdego serwera w stojaku
COMPX_SVRY_BMC_MAC	CompX Rack Servery BMC MAC address; powtórz dla każdego stojaka w definicjach compute-rack i dla każdego serwera w stojaku
COMPX_SVRY_BOOT_MAC	Adres MAC karty SIECIOWEJ (NIC) karty sieciowej CompX Rack ServerY boot; powtórz dla każdego stojaka w definicjach compute-rack i dla każdego serwera w stojaku
COMPX_SVRY_SERVER_DETAILS	Szczegóły serwera CompX Rack; powtórz dla każdego stojaka w definicjach compute-rack i dla każdego serwera w stojaku
COMPX_SVRY_SERVER_NAME	CompX Rack ServerY name; powtórz dla każdego stojaka w definicjach compute-rack i dla każdego serwera w stojaku
MRG_NAME	Nazwa zarządzanej grupy zasobów klastra
MRG_LOCATION	Region klastra platformy Azure
NF_ID	Odwołanie do sieci szkieletowej sieci szkieletowej
SP_APP_ID	Identyfikator aplikacji jednostki usługi
SP_PASS	Hasło jednostki usługi
SP_ID	Identyfikator jednostki usługi
TENANT_ID	Identyfikator dzierżawy subskrypcji
SUBSCRIPTION_ID	Identyfikator subskrypcji
KV_RESOURCE_ID	Identyfikator usługi Key Vault
CLUSTER_TYPE	Typ klastra, pojedynczego lub wielorackowego
CLUSTER_VERSION	Wersja klastra w chmurze sieciowej (NC)
TAG_KEY1	Opcjonalny tag1 do przekazania do tworzenia klastra
TAG_VALUE1	Opcjonalna wartość tag1 do przekazania do tworzenia klastra
TAG_KEY2	Opcjonalny tag2 do przekazania do tworzenia klastra
TAG_VALUE2	Opcjonalna wartość tag2 do przekazania do tworzenia klastra

Tożsamość klastra

Począwszy od wersji interfejsu API 2024-07-01, klient może przypisać tożsamość zarządzaną do klastra. Obsługiwane są tożsamości zarządzane przypisane przez system i przypisane przez użytkownika.

Tożsamość zarządzana można przypisać do klastra podczas tworzenia lub aktualizowania operacji, podając następujące parametry:

• --mi-system-assigned — włącz tożsamość zarządzaną przypisaną przez system. Po dodaniu tożsamość można usunąć tylko za pośrednictwem wywołania interfejsu API w tej chwili.
• --mi-user-assigned — identyfikatory zasobów rozdzielonych spacjami tożsamości zarządzanych przypisanych przez użytkownika do dodania. Po dodaniu tożsamość można usunąć tylko za pośrednictwem wywołania interfejsu API w tej chwili.

Tworzenie klastra przy użyciu edytora szablonów usługi Azure Resource Manager

Alternatywnym sposobem utworzenia klastra jest użycie edytora szablonów usługi ARM.

Aby utworzyć klaster w ten sposób, należy podać plik szablonu (cluster.jsonc) i plik parametrów (cluster.parameters.jsonc). Przykłady klastra jednostki SKU 8-Rack 2M16C można znaleźć przy użyciu tych dwóch plików:

cluster.jsonc , cluster.parameters.jsonc

Uwaga

Aby uzyskać poprawne formatowanie, skopiuj nieprzetworzonego pliku kodu. Wartości w pliku cluster.parameters.jsonc są specyficzne dla klienta i mogą nie być kompletną listą. Zaktualizuj pola wartości dla określonego środowiska.

1. Przejdź do witryny Azure Portal w przeglądarce internetowej i zaloguj się.
2. Wyszukaj ciąg "Wdróż szablon niestandardowy" na pasku wyszukiwania w witrynie Azure Portal, a następnie wybierz go z dostępnych usług.
3. Kliknij pozycję Utwórz własny szablon w edytorze.
4. Kliknij pozycję Załaduj plik. Znajdź plik szablonu cluster.jsonc i przekaż go.
5. Kliknij opcję Zapisz.
6. Kliknij pozycję Edytuj parametry.
7. Kliknij pozycję Załaduj plik. Znajdź plik parametrów cluster.parameters.jsonc i przekaż go.
8. Kliknij opcję Zapisz.
9. Wybierz poprawną subskrypcję.
10. Wyszukaj grupę zasobów, aby sprawdzić, czy już istnieje. Jeśli nie, utwórz nową grupę zasobów.
11. Upewnij się, że wszystkie szczegóły wystąpienia są poprawne.
12. Kliknij pozycję Przejrzyj i utwórz.

Walidacja klastra

Pomyślne utworzenie klastra Operator Nexus powoduje utworzenie zasobu platformy Azure w ramach subskrypcji. Identyfikator klastra, stan aprowizacji klastra i stan wdrożenia są zwracane w wyniku pomyślnego działania cluster create.

Wyświetl stan klastra:

az networkcloud cluster show --cluster-name "<clusterName>" /
--resource-group "<resourceGroupName>" /
--subscription <subscriptionID>

Tworzenie klastra zostanie ukończone po provisioningState wyświetleniu elementu zasobu: "provisioningState": "Succeeded"

Rejestrowanie klastra

Dzienniki tworzenia klastra można wyświetlić w następujących lokalizacjach:

1. Dzienniki aktywności zasobu/grupy zasobów w witrynie Azure Portal.
2. Interfejs wiersza polecenia platformy Azure z flagą --debug przekazaną w wierszu polecenia.

Ustawianie progów wdrożenia

Istnieją dwa typy progów wdrożenia, które można ustawić w klastrze przed wdrożeniem klastra. Są to compute-deployment-threshold i update-strategy.

--compute-deployment-threshold — próg weryfikacji wskazujący dozwolone błędy węzłów obliczeniowych podczas walidacji sprzętu środowiska.

Jeśli compute-deployment-threshold nie jest ustawiona, wartości domyślne są następujące:

      "strategyType": "Rack",
      "thresholdType": "PercentSuccess",
      "thresholdValue": 80,
      "waitTimeMinutes": 1

Jeśli klient żąda compute-deployment-threshold wartości innej niż domyślna 80%, możesz uruchomić następujące polecenie aktualizacji klastra.

Poniższy przykład dotyczy typu żądania klienta "PercentSuccess" z współczynnikiem powodzenia wynoszącym 97%.

az networkcloud cluster update --name "<clusterName>" /
--resource-group "<resourceGroup>" /
--compute-deployment-threshold type="PercentSuccess" grouping="PerCluster" value=97 /
--subscription <subscriptionID>

Weryfikowanie aktualizacji

az networkcloud cluster show --resource-group "<resourceGroup>" --name "<clusterName>" | grep -a3 computeDeploymentThreshold

  "clusterType": "MultiRack",
  "clusterVersion": "<CLUSTER_VERSION>",
  "computeDeploymentThreshold": {
    "grouping": "PerCluster",
    "type": "PercentSuccess",
    "value": 97

W tym przykładzie, jeśli mniej niż 97% wdrożonych węzłów obliczeniowych przejdzie walidację sprzętu, wdrożenie klastra zakończy się niepowodzeniem. UWAGA: Wszystkie płaszczyzny sterowania kubernetes (KCP) i płaszczyzny zarządzania nexus (NMP) muszą przejść weryfikację sprzętu. Jeśli wdrożono co najmniej 97% węzłów obliczeniowych, przejdą weryfikację sprzętu, wdrożenie klastra będzie kontynuowane w fazie aprowizacji uruchamiania. Podczas inicjowania obsługi rozruchu obliczeniowego update-strategy (poniżej) jest używany dla węzłów obliczeniowych.

--update-strategy — strategia aktualizowania klastra wskazująca dozwolone błędy węzłów obliczeniowych podczas aprowizacji bootstrap.

Jeśli klient zażąda update-strategy progu innego niż wartość domyślna 80%, możesz uruchomić następujące polecenie aktualizacji klastra.

az networkcloud cluster update --name "<clusterName>" /
--resource-group "<resourceGroup>" /
--update-strategy strategy-type="Rack" threshold-type="PercentSuccess" /
threshold-value="<thresholdValue>" wait-time-minutes=<waitTimeBetweenRacks> /
--subscription <subscriptionID>

Typ strategii może mieć wartość "Rack" (Rack by Rack) lub "PauseAfterRack" (Poczekaj na kontynuowanie odpowiedzi klienta).

Typ progu może mieć wartość "PercentSuccess" lub "CountSuccess".

Jeśli właściwość updateStrategy nie jest ustawiona, wartości domyślne są następujące:

      "strategyType": "Rack",
      "thresholdType": "PercentSuccess",
      "thresholdValue": 80,
      "waitTimeMinutes": 1

Poniższy przykład dotyczy klienta korzystającego ze strategii Rack by Rack z wartością procentową sukcesu 60% i 1 minutą wstrzymania.

az networkcloud cluster update --name "<clusterName>" /
--resource-group "<resourceGroup>" /
--update-strategy strategy-type="Rack" threshold-type="PercentSuccess" /
threshold-value=60 wait-time-minutes=1 /
--subscription <subscriptionID>

Sprawdź aktualizację:

az networkcloud cluster show --resource-group "<resourceGroup>" /
--name "<clusterName>" /
--subscription <subscriptionID>| grep -a5 updateStrategy

      "strategyType": "Rack",
      "thresholdType": "PercentSuccess",
      "thresholdValue": 60,
      "waitTimeMinutes": 1

W tym przykładzie, jeśli aprowizacja węzłów obliczeniowych w stojaku nie powiedzie się (na stojaku według stojaka), wdrożenie klastra zakończy się niepowodzeniem. Jeśli pomyślnie aprowizowana jest co najmniej 60% węzłów obliczeniowych, wdrożenie klastra zostanie przeniesione do następnego stojaka węzłów obliczeniowych.

Poniższy przykład dotyczy klienta korzystającego ze strategii Rack by Rack z typem progu CountSuccess 10 węzłów na stojak i 1 minutą wstrzymania.

az networkcloud cluster update --name "<clusterName>" /
--resource-group "<resourceGroup>" /
--update-strategy strategy-type="Rack" threshold-type="CountSuccess" /
threshold-value=10 wait-time-minutes=1 /
--subscription <subscriptionID>

Sprawdź aktualizację:

az networkcloud cluster show --resource-group "<resourceGroup>" /
--name "<clusterName>" /
--subscription <subscriptionID>| grep -a5 updateStrategy

      "strategyType": "Rack",
      "thresholdType": "CountSuccess",
      "thresholdValue": 10,
      "waitTimeMinutes": 1

W tym przykładzie, jeśli aprowizacja w stojaku nie powiedzie się (w stojaku według stojaka) mniej niż 10 węzłów obliczeniowych, wdrożenie klastra zakończy się niepowodzeniem. Jeśli pomyślnie aprowizowana jest co najmniej 10 węzłów obliczeniowych, wdrożenie klastra zostanie przeniesione do następnego stojaka węzłów obliczeniowych.

Uwaga

Nie można zmienić progów wdrożenia po rozpoczęciu wdrażania klastra.

Wdrażanie klastra

Akcja wdrażania klastra może zostać wyzwolona po utworzeniu klastra. Akcja wdróż klaster tworzy obraz bootstrap i wdraża klaster.

Wdróż klaster inicjuje sekwencję zdarzeń występujących w Menedżerze klastra.

1. Sprawdzanie poprawności właściwości klastra/stojaka.
2. Generowanie obrazu rozruchowego dla efemerycznego klastra rozruchowego (walidacja infrastruktury).
3. Interakcja z interfejsem interfejsu IPMI (Intelligent Platform Management Interface) docelowej maszyny rozruchowej.
4. Przeprowadzanie testów weryfikacji sprzętu.
5. Monitorowanie procesu wdrażania klastra.

Wdróż klaster lokalny:

az networkcloud cluster deploy \
  --name "$CLUSTER_NAME" \
  --resource-group "$CLUSTER_RG" \
  --subscription "$SUBSCRIPTION_ID" \
  --no-wait --debug

Napiwek

Aby sprawdzić stan az networkcloud cluster deploy polecenia, można go wykonać przy użyciu flagi --debug . Umożliwi to uzyskanie nagłówka lub używanego Azure-AsyncOperation do wykonywania zapytań dotyczących operationStatuses zasobu.Location Zobacz sekcję Wdrażanie klastra nie powiodło się , aby uzyskać bardziej szczegółowe instrukcje. Opcjonalnie polecenie może być uruchamiane asynchronicznie przy użyciu flagi --no-wait .

Wdrażanie klastra z weryfikacją sprzętu

Podczas procesu wdrażania klastra jednym z wykonanych kroków jest weryfikacja sprzętu. Procedura sprawdzania poprawności sprzętu uruchamia różne testy i sprawdza maszyny dostarczone za pomocą definicji stojaka klastra. Na podstawie wyników tych testów i wszystkich pominiętych maszyn przez użytkownika należy określić, czy są dostępne wystarczające węzły przekazywane i/lub są dostępne, aby spełnić progi niezbędne do kontynuowania wdrażania.

Ważne

Proces weryfikacji sprzętu zapisze wyniki określone w analyticsWorkspaceId sekcji Tworzenie klastra. Ponadto podana jednostka usługi w obiekcie klastra jest używana do uwierzytelniania w interfejsie API zbierania danych obszaru roboczego usługi Log Analytics. Ta funkcja jest widoczna tylko podczas nowego wdrożenia (Green Field); istniejący klaster nie będzie miał dostępnych dzienników z mocą wsteczną.

Uwaga

Kontroler RAID jest resetowany podczas wdrażania klastra wyczyszcząc wszystkie dane z dysków wirtualnych serwera. Alerty dotyczące dysków wirtualnych kontrolera zarządzania płytą główną (BMC) mogą być zwykle ignorowane, chyba że istnieją dodatkowe alerty dotyczące dysków fizycznych i/lub kontrolerów RAID.

Domyślnie proces sprawdzania poprawności sprzętu zapisuje wyniki w skonfigurowanym klastrze analyticsWorkspaceId. Jednak ze względu na charakter zbierania danych obszaru roboczego usługi Log Analytics i oceny schematu może wystąpić opóźnienie pozyskiwania, które może potrwać kilka minut lub więcej. Z tego powodu wdrożenie klastra przebiega nawet wtedy, gdy nie udało się zapisać wyników w obszarze roboczym usługi Log Analytics. Aby ułatwić rozwiązanie tego możliwego zdarzenia, wyniki dla nadmiarowości są również rejestrowane w Menedżerze klastra.

W udostępnionym obszarze roboczym usługi Log Analytics obiektu klastra powinna zostać wyświetlona nowa tabela niestandardowa z nazwą klastra jako prefiksem i sufiksem *_CL . W sekcji Dzienniki zasobu LAW można wykonać zapytanie względem nowej *_CL tabeli dzienników niestandardowych.

Wdrażanie klastra z pominięciem określonej maszyny bez systemu operacyjnego

Parametr --skip-validation-for-machines reprezentuje nazwy maszyn bez systemu operacyjnego w klastrze, które powinny zostać pominięte podczas walidacji sprzętu. Pominięte węzły nie są weryfikowane i nie są dodawane do puli węzłów. Ponadto węzły pominięte nie są liczone względem sumy używanej przez obliczenia progowe.

az networkcloud cluster deploy \
  --name "$CLUSTER_NAME" \
  --resource-group "$CLUSTER_RG" \
  --subscription "$SUBSCRIPTION_ID" \
  --skip-validations-for-machines "$COMPX_SVRY_SERVER_NAME"

Wdrażanie klastra nie powiodło się

Aby śledzić stan operacji asynchronicznej, uruchom polecenie z włączoną flagą --debug . Po --debug określeniu można monitorować postęp żądania. Adres URL stanu operacji można znaleźć, sprawdzając dane wyjściowe debugowania, Azure-AsyncOperation wyszukując nagłówek lub Location w odpowiedzi HTTP na żądanie utworzenia. Nagłówki mogą podać OPERATION_ID pole używane w wywołaniu interfejsu API HTTP.

OPERATION_ID="aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e*99399E995..."
az rest -m GET -u "https://management.azure.com/subscriptions/${SUBSCRIPTION_ID}/providers/Microsoft.NetworkCloud/locations/${LOCATION}/operationStatuses/${OPERATION_ID}?api-version=2022-12-12-preview"

Dane wyjściowe są podobne do przykładu struktury JSON. Gdy kod błędu to HardwareValidationThresholdFailed, komunikat o błędzie zawiera listę maszyn bez systemu operacyjnego, które zakończyły się niepowodzeniem weryfikacji sprzętu (na przykład COMP0_SVR0_SERVER_NAME, COMP1_SVR1_SERVER_NAME). Te nazwy mogą służyć do analizowania dzienników, aby uzyskać więcej szczegółów.

{
  "endTime": "2023-03-24T14:56:59.0510455Z",
  "error": {
    "code": "HardwareValidationThresholdFailed",
    "message": "HardwareValidationThresholdFailed error hardware validation threshold for cluster layout plan is not met for cluster $CLUSTER_NAME in namespace nc-system with listed failed devices $COMP0_SVR0_SERVER_NAME, $COMP1_SVR1_SERVER_NAME"
  },
  "id": "/subscriptions/$SUBSCRIPTION_ID/providers/Microsoft.NetworkCloud/locations/$LOCATION/operationStatuses/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e*99399E995...",
  "name": "aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e*99399E995...",
  "resourceId": "/subscriptions/$SUBSCRIPTION_ID/resourceGroups/$CLUSTER_RESOURCE_GROUP/providers/Microsoft.NetworkCloud/clusters/$CLUSTER_NAME",
  "startTime": "2023-03-24T14:56:26.6442125Z",
  "status": "Failed"
}

Zobacz artykuł Śledzenie operacji asynchronicznych przy użyciu interfejsu wiersza polecenia platformy Azure, aby zapoznać się z innym przykładem. Zobacz artykuł Rozwiązywanie problemów z aprowizowaniem programu BMM, aby uzyskać więcej informacji, które mogą być przydatne w przypadku niepowodzenia walidacji lub wdrożenia określonych maszyn.

Walidacja wdrożenia klastra

Wyświetl stan klastra w portalu lub za pośrednictwem interfejsu wiersza polecenia platformy Azure:

az networkcloud cluster show --resource-group "$CLUSTER_RG" \
  --name "$CLUSTER_NAME"

Wdrożenie klastra jest w toku, gdy parametr detailedStatus jest ustawiony na Deploying i szczegółoweStatusMessage pokazuje postęp wdrażania. Niektóre przykłady postępu wdrażania pokazane w szczegółoweStatusMessage to Hardware validation is in progress. (jeśli klaster jest wdrożony z weryfikacją sprzętu), Cluster is bootstrapping., , KCP initialization in progress.Management plane deployment in progress., Cluster extension deployment in progress., , waiting for "<rack-ids>" to be readyitp.

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

Wyświetl wersję zarządzania klastra:

az k8s-extension list --cluster-name "$CLUSTER_NAME" --resource-group "$MRG_NAME" --cluster-type connectedClusters --query "[?name=='nc-platform-extension'].{name:name, extensionType:extensionType, releaseNamespace:scope.cluster.releaseNamespace,provisioningState:provisioningState,version:version}" -o table --subscription "$SUBSCRIPTION_ID"

Rejestrowanie wdrożenia klastra

Dzienniki tworzenia klastra można wyświetlić w następujących lokalizacjach:

1. Dzienniki aktywności zasobu/grupy zasobów w witrynie Azure Portal.
2. Interfejs wiersza polecenia platformy Azure z flagą --debug przekazaną w wierszu polecenia.

Aktualizowanie tożsamości klastra za pośrednictwem interfejsów API

Tożsamości zarządzane klastra można przypisywać za pośrednictwem interfejsu wiersza polecenia. Cofnij przypisanie tożsamości można wykonać za pośrednictwem wywołań interfejsu API. Uwaga: <APIVersion> interfejs API w wersji 2024-07-01 lub nowszej.

• Aby usunąć wszystkie tożsamości zarządzane, wykonaj następujące polecenie:

  az rest --method PATCH --url /subscriptions/$SUB_ID/resourceGroups/$CLUSTER_RG/providers/Microsoft.NetworkCloud/clusters/$CLUSTER_NAME?api-version=<APIVersion> --body "{\"identity\":{\"type\":\"None\"}}"
  

• Jeśli dodano tożsamości zarządzane przypisane przez użytkownika i przypisane przez system, można je usunąć, aktualizując element type na :SystemAssigned

  az rest --method PATCH --url /subscriptions/$SUB_ID/resourceGroups/$CLUSTER_RG/providers/Microsoft.NetworkCloud/clusters/$CLUSTER_NAME?api-version=<APIVersion> --body @~/uai-body.json
  

  Przykład treści żądania (uai-body.json):

  {
    "identity": {
        "type": "SystemAssigned"
    }
  }
  

• Jeśli dodano tożsamości zarządzane przypisane przez użytkownika i przypisane przez system, można je usunąć, aktualizując element type na UserAssigned:

  az rest --method PATCH --url /subscriptions/$SUB_ID/resourceGroups/$CLUSTER_RG/providers/Microsoft.NetworkCloud/clusters/$CLUSTER_NAME?api-version=<APIVersion> --body @~/uai-body.json
  

  Przykład treści żądania (uai-body.json):

  {
    "identity": {
        "type": "UserAssigned",
    	"userAssignedIdentities": {
    		"/subscriptions/$SUB_ID/resourceGroups/$UAI_RESOURCE_GROUP/providers/Microsoft.ManagedIdentity/userAssignedIdentities/$UAI_NAME": {}
    	}
    }
  }
  

• Jeśli dodano wiele tożsamości zarządzanych przypisanych przez użytkownika, można je usunąć, wykonując następujące czynności:

  az rest --method PATCH --url /subscriptions/$SUB_ID/resourceGroups/$CLUSTER_RG/providers/Microsoft.NetworkCloud/clusters/$CLUSTER_NAME?api-version=<APIVersion> --body @~/uai-body.json
  

  Przykład treści żądania (uai-body.json):

  {
    "identity": {
        "type": "UserAssigned",
    	"userAssignedIdentities": {
    		"/subscriptions/$SUB_ID/resourceGroups/$UAI_RESOURCE_GROUP/providers/Microsoft.ManagedIdentity/userAssignedIdentities/$UAI_NAME": null
    	}
    }
  }
  

Usuwanie klastra

Usunięcie klastra powoduje usunięcie zasobów na platformie Azure i klastra znajdującego się w środowisku lokalnym.

Uwaga

Jeśli w klastrze istnieją jakiekolwiek zasoby dzierżawy, nie zostaną usunięte, dopóki te zasoby nie zostaną usunięte.

az networkcloud cluster delete --name "$CLUSTER_NAME" --resource-group "$CLUSTER_RG"