Erstellen und Bereitstellen eines Clusters mithilfe der Azure CLI

Artikel
12/21/2024

In diesem Artikel wird das Erstellen eines Clusters mithilfe der Azure-Befehlszeilenschnittstelle (AzCLI) erstellen beschrieben. Außerdem veranschaulicht dieses Dokument, wie Sie den Status überprüfen, Updates durchführen oder einen Cluster löschen.

Voraussetzungen

Vergewissern Sie sich, dass der Netzwerk-Fabric Controller und der Cluster-Manager in Ihrer Azure-Region vorhanden sind.
Überprüfen, ob Network Fabric erfolgreich bereitgestellt wurde

API-Leitfaden und -Metriken

Der API-Leitfaden enthält Informationen zu den Ressourcenanbietern, Ressourcenmodellen und APIs.

Die aus den Protokollierungsdaten generierten Metriken finden Sie unter Azure Monitor-Metriken.

Begrenzungen

Benennung: Benennungsregeln finden Sie hier.

Erstellen eines Clusters

Die Infrastrukturclusterressource stellt eine lokale Bereitstellung der Plattform im Cluster-Manager dar. Alle anderen plattformspezifischen Ressourcen sind in Bezug auf ihren Lebenszyklus davon abhängig.

Es empfiehlt sich, die Network Fabric-Instanz vor dieser lokalen Bereitstellung zu erstellen. Jede lokale Operator Nexus-Instanz weist eine 1:1-Zuordnung mit einem Netzwerkfabric auf.

Erstellen Sie den Cluster mithilfe der Azure CLI:

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"

Parameter für Clustervorgänge

Parametername	Beschreibung
CLUSTER_NAME	Ressourcenname des Clusters
LOCATION	Die Azure-Region, in der der Cluster bereitgestellt wird
CL_NAME	Der benutzerdefinierte Cluster Manager-Speicherort aus dem Azure-Portal
CLUSTER_RG	Der Name der Clusterressourcengruppe
LAW_ID	ID des Log Analytics-Arbeitsbereichs für den Cluster
CLUSTER_LOCATION	Der lokale Name des Clusters
AGGR_RACK_RESOURCE_ID	Rack-ID für das Aggregator-Rack
AGGR_RACK_SKU	Rack-SKU für Aggregator Rack *Siehe Operator Nexus Network Cloud SKUs
AGGR_RACK_SN	Rackseriennummer für das Aggregator-Rack
AGGR_RACK_LOCATION	Physischer Rackstandort für das Aggregator-Rack
AGGR_RACK_BMM	Nur für die Bereitstellung eines Einzelracks verwendet, leer bei mehreren Racks
SA_NAME	Gerätename der Speicherappliance
SA_PASS	Administratorkennwort der Speicherappliance
SA_USER	Administratorbenutzer der Speicherappliance
SA_SN	Seriennummer der Speicherappliance
COMPX_RACK_RESOURCE_ID	Rack-ID für CompX-Rack, für jedes Rack in „compute-rack-definitions“ wiederholen
COMPX_RACK_SKU	Rack-SKU für CompX-Rack, für jedes Rack in „compute-rack-definitions“ wiederholen *Siehe Operator Nexus Network Cloud SKUs
COMPX_RACK_SN	Rackseriennummer für CompX-Rack, für jedes Rack in „compute-rack-definitions“ wiederholen
COMPX_RACK_LOCATION	Physischer Standort für CompX-Rack, für jedes Rack in „compute-rack-definitions“ wiederholen
COMPX_SVRY_BMC_PASS	BMC-Kennwort (Baseboard-Verwaltungscontroller) für CompX-Rack-ServerY; für jedes Rack in „compute-rack-definitions“ und für jeden Server im Rack wiederholen
COMPX_SVRY_BMC_USER	Benutzer für CompX-Rack-ServerY-BMC; für jedes Rack in „compute-rack-definitions“ und für jeden Server im Rack wiederholen
COMPX_SVRY_BMC_MAC	MAC-Adresse für CompX-Rack-ServerY-BMC; für jedes Rack in „compute-rack-definitions“ und für jeden Server im Rack wiederholen
COMPX_SVRY_BOOT_MAC	MAC-Adresse von Boot-NIC (Netzwerkadapter) für CompX-Rack-ServerY; für jedes Rack in „compute-rack-definitions“ und für jeden Server im Rack wiederholen
COMPX_SVRY_SERVER_DETAILS	Details für CompX-Rack-ServerY; für jedes Rack in „compute-rack-definitions“ und für jeden Server im Rack wiederholen
COMPX_SVRY_SERVER_NAME	Name für CompX-Rack-ServerY; für jedes Rack in „compute-rack-definitions“ und für jeden Server im Rack wiederholen
MRG_NAME	Name der verwalteten Clusterressourcengruppe
MRG_LOCATION	Azure-Region für Cluster
NF_ID	Verweis auf Network Fabric
SP_APP_ID	App-ID des Dienstprinzipals
SP_PASS	Kennwort des Dienstprinzipals
SP_ID	Dienstprinzipal-ID:
TENANT_ID	ID des Abonnementmandanten
SUBSCRIPTION_ID	Abonnement-ID
KV_RESOURCE_ID	Key Vault-ID
CLUSTER_TYPE	Art des Clusters: einzeln oder MultiRack
CLUSTER_VERSION	NC-Version (Network Cloud) des Clusters
TAG_KEY1	Optionales tag1 zum Übergeben an die Clustererstellung
TAG_VALUE1	Wert des optionalen tag1 zum Übergeben an die Clustererstellung
TAG_KEY2	Optionales tag2 zum Übergeben an die Clustererstellung
TAG_VALUE2	Wert des optionalen tag2 zum Übergeben an die Clustererstellung

Clusteridentität

Ab der API-Version 2024-07-01 kann ein Kunde einem Cluster eine verwaltete Identität zuweisen. Es werden sowohl systemseitig als auch benutzerseitig zugewiesene verwaltete Identitäten unterstützt.

Eine verwaltete Identität kann dem Cluster im Rahmen der Erstellung oder bei einer Aktualisierung mithilfe folgender Parameter zugewiesen werden:

--mi-system-assigned – Eine systemseitig zugewiesene verwaltete Identität wird aktiviert. Nach dem Hinzufügen kann die Identität derzeit nur über den API-Aufruf entfernt werden.
--mi-user-assigned – Durch Leerzeichen getrennte Ressourcen-IDs der benutzerseitig zugewiesenen verwalteten Identitäten, die hinzugefügt werden sollen. Nach dem Hinzufügen kann die Identität derzeit nur über den API-Aufruf entfernt werden.

Erstellen des Clusters mithilfe des Azure Resource Manager-Vorlagen-Editors

Eine alternative Möglichkeit zum Erstellen eines Clusters ist der ARM-Vorlagen-Editor.

Um den Cluster auf diese Weise zu erstellen, müssen Sie eine Vorlagendatei (cluster.jsonc) und eine Parameterdatei (cluster.parameters.jsonc) bereitstellen. Beispiele für einen 8-Rack 2M16C-SKU-Cluster finden Sie unter Verwendung dieser beiden Dateien:

cluster.jsonc , cluster.parameters.jsonc

Hinweis

Um die richtige Formatierung zu erhalten, kopieren Sie die Rohcodedatei. Die Werte in der Datei cluster.parameters.jsonc sind kundenspezifisch und stellen möglicherweise keine vollständige Liste dar. Aktualisieren Sie dann die Werte entsprechend Ihrer jeweiligen Umgebung.

Navigieren Sie in einem Webbrowser zum Azure-Portal, und melden Sie sich an.
Suchen Sie über die Suchleiste im Azure-Portal nach „Benutzerdefinierte Vorlage bereitstellen“, und wählen Sie sie dann aus den verfügbaren Diensten aus.
Klicken Sie auf Eigene Vorlage im Editor erstellen.
Klicken Sie auf "Datei laden". Suchen Sie die Vorlagendatei "cluster.jsonc", und laden Sie sie hoch.
Klicken Sie auf Speichern.
Klicken Sie auf Parameter bearbeiten.
Klicken Sie auf "Datei laden". Suchen Sie die Parameterdatei "cluster.parameters.jsonc", und laden Sie sie hoch.
Klicken Sie auf Speichern.
Wählen Sie das richtige Abonnement aus.
Suchen Sie nach der Ressourcengruppe, um festzustellen, ob sie bereits vorhanden ist. Falls nicht, erstellen Sie eine neue Ressourcengruppe.
Stellen Sie sicher, dass alle Instanzendetails korrekt sind.
Klicken Sie auf Überprüfen + erstellen.

Clustervalidierung

Bei erfolgreicher Erstellung des Operator Nexus-Clusters wird in Ihrem Abonnement eine Azure-Ressource erstellt. Die Cluster-ID, der Clusterbereitstellungsstatus und der Bereitstellungsstatus werden als Ergebnis eines erfolgreichen cluster create-Vorgangs zurückgegeben.

Zeigen Sie den Status des Clusters an:

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

Die Clustererstellung ist abgeschlossen, wenn für provisioningState der Ressource Folgendes angezeigt wird: "provisioningState": "Succeeded"

Clusterprotokollierung

Protokolle zur Clustererstellung können an den folgenden Stellen angezeigt werden:

Aktivitätsprotokolle für Ressourcen/Ressourcengruppen im Azure-Portal
Azure CLI mit in der Befehlszeile übergebenem Flag --debug

Festlegen von Bereitstellungsschwellenwerten

Es gibt zwei Typen von Bereitstellungsschwellenwerten, die vor der Clusterbereitstellung in einem Cluster festgelegt werden können. Diese sind compute-deployment-threshold und update-strategy.

--compute-deployment-threshold: Dieser Überprüfungsschwellenwert gibt die zulässigen Fehler von Serverknoten während einer Hardwareüberprüfung in der Umgebung an.

Wenn compute-deployment-threshold nicht festgelegt wurde, gelten die folgenden Standardwerte:

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

Wenn ein Kunde einen compute-deployment-threshold anfordert, der vom Standardwert von 80 % abweicht, können Sie den folgenden Clusterupdatebefehl ausführen.

Das folgende Beispiel zeigt einen Kunden, der den Typ „PercentSuccess“ mit einer Erfolgsquote von 97 % anfordert.

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

Überprüfen von Updates

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

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

Wenn in diesem Beispiel weniger als 97 % der bereitgestellten Serverknoten die Hardwareüberprüfung bestehen, schlägt die Clusterbereitstellung fehl. HINWEIS: Alle Komponenten auf Kubernetes-Steuerungsebene (KCP) und Nexus-Verwaltungsebene (NMP) müssen die Hardwareüberprüfung bestehen. Wenn mindestens 97 % der bereitgestellten Serverknoten die Hardwareüberprüfung bestehen, wird die Clusterbereitstellung mit der Bootstrap-Bereitstellungsphase fortgesetzt. Während der Bootstrap-Bereitstellung von Computeressourcen wird die update-strategy (unten) für Serverknoten verwendet.

--update-strategy: Diese Strategie für Clusterupdates gibt die zulässigen Serverknotenfehler während der Bootstrap-Bereitstellung an.

Wenn ein Kunde einen update-strategy-Schwellenwert anfordert, der vom Standardwert von 80 % abweicht, können Sie den folgenden Clusterupdatebefehl ausführen.

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>

Der Strategietyp (strategy-type) kann „Rack“ (Rack zu Rack) ODER „PauseAfterRack“ sein (vor dem Fortfahren auf Kundenantwort warten) lauten.

Der Schwellenwerttyp (threshold-type) kann „PercentSuccess“ ODER „CountSuccess“ sein.

Wenn updateStrategy nicht festgelegt wurde, gelten die folgenden Standardwerte:

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

Das folgende Beispiel zeigt einen Kunden, der die Rack-zu-Rack-Strategie mit einer prozentualen Erfolgsrate von 60 % und einer Pause von 1 Minute verwendet.

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>

Überprüfen von Updates:

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

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

Wenn in diesem Beispiel weniger als 60 % der in einem Rack bereitgestellten Serverknoten nicht bereitgestellt werden (auf Rack-zu-Rack-Basis), schlägt die Clusterbereitstellung fehl. Wenn mindestens 60 % der Serverknoten erfolgreich bereitgestellt werden, wird die Clusterbereitstellung mit dem nächsten Rack mit Serverknoten fortgesetzt.

Das folgende Beispiel zeigt einen Kunden, der die Rack-zu-Rack-Strategie mit dem Schwellenwerttyp CountSuccess mit 10 Knoten pro Rack und einer Pause von 1 Minute verwendet.

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>

Überprüfen von Updates:

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

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

Wenn in diesem Beispiel weniger als 10 Serverknoten in einem Rack bereitgestellt werden (auf Rack-zu-Rack-Basis), schlägt die Clusterbereitstellung fehl. Wenn mindestens 10 Serverknoten erfolgreich bereitgestellt werden, wird die Clusterbereitstellung mit dem nächsten Rack mit Serverknoten fortgesetzt.

Hinweis

Bereitstellungsschwellenwerte können nach dem Start der Clusterbereitstellung nicht mehr geändert werden.

Bereitstellen eines Clusters

Nach dem Erstellen des Clusters kann die Aktion „Cluster bereitstellen“ ausgelöst werden. Die Aktion für die Clusterbereitstellung erstellt das Bootstrapimage und stellt den Cluster bereit.

Der Bereitstellungsvorgang initiiert eine Reihe von Ereignissen im Cluster-Manager.

Überprüfung der Cluster-/Rackeigenschaften
Generierung eines startbaren Images für den kurzlebigen Bootstrap-Cluster (Überprüfung der Infrastruktur)
Interaktion mit der IPMI-Schnittstelle (Intelligent Platform Management Interface) des Bootstrap-Zielcomputers
Ausführung von Hardwareüberprüfungen
Überwachung des Clusterbereitstellungsprozesses

Stellen Sie den lokalen Cluster bereit:

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

Tipp

Um den Status des az networkcloud cluster deploy-Befehls zu überprüfen, kann er mithilfe des --debug-Flags ausgeführt werden. Auf diese Weise können Sie den Header Azure-AsyncOperation oder Location abrufen, der zum Abfragen der operationStatuses-Ressource verwendet wird. Ausführlichere Schritte finden Sie im Abschnitt Clusterbereitstellung fehlgeschlagen. Optional kann der Befehl asynchron mit dem --no-wait-Flag ausgeführt werden.

Clusterbereitstellung mit Hardwareprüfung

Während der Bereitstellung eines Clusters ist einer der Schritte, die ausgeführt werden, die Hardwareprüfung. Bei der Hardwareprüfungsprozedur werden verschiedene Tests und Überprüfungen der über die Rackdefinition des Clusters bereitgestellten Maschinen durchgeführt. Basierend auf den Ergebnissen dieser Prüfungen und allen übersprungenen Computern wird festgestellt, ob genügend Knoten bestanden haben und/oder verfügbar sind, um die für die weitere Bereitstellung erforderlichen Schwellenwerte zu erreichen.

Wichtig

Der Hardwareprüfungsprozess schreibt die Ergebnisse in die bei der Clustererstellung angegebene analyticsWorkspaceId. Darüber hinaus wird der bereitgestellte Dienstprinzipal im Clusterobjekt für die Authentifizierung für die Datensammlungs-API des Log Analytics-Arbeitsbereichs verwendet. Diese Funktion ist nur während einer neuen Bereitstellung (Greenfield) sichtbar. Vorhandene Cluster verfügen nicht über die rückwirkend verfügbaren Protokolle.

Hinweis

Der RAID-Controller wird während der Clusterbereitstellung zurückgesetzt, wobei alle Daten von den virtuellen Datenträgern des Servers gelöscht werden. Alle BMC-Warnungen (Baseboard--Verwaltungscontroller) von virtuellen Datenträgern können in der Regel ignoriert werden, es sei denn, es gibt weitere Warnungen zu physischen Datenträgern und/oder RAID-Controllern.

Standardmäßig schreibt der Hardwareprüfungsprozess die Ergebnisse in die analyticsWorkspaceId des konfigurieren Clusters. Aufgrund der Art der Datenerfassung und der Schemaauswertung des Log Analytics-Arbeitsbereichs kann es jedoch zu Verzögerungen bei der Erfassung kommen, die einige Minuten oder länger dauern können. Aus diesem Grund wird die Clusterbereitstellung fortgesetzt, auch wenn die Ergebnisse nicht in den Log Analytics-Arbeitsbereich geschrieben wurden. Um dieses mögliche Ereignis zu vermeiden, werden die Ergebnisse aus Redundanzgründen auch im Cluster-Manager protokolliert.

Im Log Analytics-Arbeitsbereich des bereitgestellten Clusterobjekts sollte eine neue benutzerdefinierte Tabelle mit dem Namen des Clusters als Präfix und dem Suffix *_CL angezeigt werden. Im Abschnitt Protokolle der LAW-Ressource kann eine Abfrage für die neue benutzerdefinierte Protokolltabelle *_CL ausgeführt werden.

Clusterbereitstellung mit Überspringen eines bestimmten Bare-Metal-Computers

Der --skip-validation-for-machines-Parameter stellt die Namen von Bare-Metal-Computern im Cluster dar, die während der Hardwareüberprüfung übersprungen werden sollen. Übersprungene Knoten werden nicht überprüft und nicht zum Knotenpool hinzugefügt. Außerdem werden übersprungene Knoten nicht auf die Gesamtzahl angerechnet, die für die Berechnung der Schwellenwerte verwendet wird.

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

Fehler bei der Clusterbereitstellung

Um den Status eines asynchronen Vorgangs nachzuverfolgen, nehmen Sie die Ausführung mit einem aktivierten --debug-Flag vor. Wenn --debug angegeben ist, kann der Fortschritt der Anforderung überwacht werden. Die Vorgangsstatus-URL lässt sich ermitteln, indem man in der Debugausgabe in der HTTP-Antwort auf die Erstellungsanforderung nach dem Header Azure-AsyncOperation oder Location sucht. Die Header können das im HTTP-API-Aufruf verwendete Feld OPERATION_ID bereitstellen.

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"

Die Ausgabe ähnelt dem JSON-Strukturbeispiel. Wenn der Fehlercode HardwareValidationThresholdFailed ist, enthält die Fehlermeldung eine Liste der Bare-Metal-Computer mit Fehlern bei der Hardwareprüfung (z. B. COMP0_SVR0_SERVER_NAME, COMP1_SVR1_SERVER_NAME). Diese Namen können verwendet werden, um die Protokolle nach weiteren Details zu parsen.

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

Ein weiteres Beispiel finden Sie im Artikel Nachverfolgen asynchroner Vorgänge mithilfe der Azure CLI. Weitere Informationen, die hilfreich sein können, wenn bestimmte Computer die Validierung oder Bereitstellung nicht bestehen, finden Sie im Artikel Problembehandlung bei der BMM-Bereitstellung.

Überprüfung der Clusterbereitstellung

Zeigen Sie den Status des Clusters im Portal oder über die Azure CLI an:

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

Die Clusterbereitstellung ist in Bearbeitung, wenn detailedStatus auf Deploying festgelegt ist, und detailedStatusMessage zeigt den Fortschritt der Bereitstellung an. Einige Beispiele für den Bereitstellungsfortschritt in detailedStatusMessage sind Hardware validation is in progress. (wenn der Cluster mit Hardwareüberprüfung bereitgestellt wird), Cluster is bootstrapping., KCP initialization in progress., Management plane deployment in progress., Cluster extension deployment in progress., waiting for "<rack-ids>" to be ready usw.

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

Anzeigen der Verwaltungsversion des Clusters:

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"

Protokollierung der Clusterbereitstellung

Protokolle zur Clustererstellung können an den folgenden Stellen angezeigt werden:

Aktivitätsprotokolle für Ressourcen/Ressourcengruppen im Azure-Portal
Azure CLI mit in der Befehlszeile übergebenem Flag --debug

Aktualisieren von Clusteridentitäten über APIs

Verwaltete Clusteridentitäten können per CLI zugewiesen werden. Die Zuweisung der Identitäten kann über API-Aufrufe aufgehoben werden. Hinweis: <APIVersion> entspricht mindestens der API-Version 2024-07-01.

Führen Sie Folgendes aus, um alle verwalteten Identitäten zu entfernen:

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

Wenn sowohl benutzerseitig als auch systemseitig zugewiesene verwaltete Identitäten hinzugefügt wurden, kann die benutzerseitig zugewiesene Identität entfernt werden, indem type in SystemAssigned geändert wird:
```
az rest --method PATCH --url /subscriptions/$SUB_ID/resourceGroups/$CLUSTER_RG/providers/Microsoft.NetworkCloud/clusters/$CLUSTER_NAME?api-version=<APIVersion> --body @~/uai-body.json
```
Beispiel für den Anforderungstext (uai-body.json):
```
{
  "identity": {
      "type": "SystemAssigned"
  }
}
```

Wenn sowohl benutzerseitig als auch systemseitig zugewiesene verwaltete Identitäten hinzugefügt wurden, kann die systemseitig zugewiesene Identität entfernt werden, indem type in UserAssigned geändert wird:

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

Beispiel für den Anforderungstext (uai-body.json):

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

Wenn mehrere benutzerseitig zugewiesene verwaltete Identitäten hinzugefügt wurden, kann eine davon entfernt werden, indem Sie Folgendes ausführen:

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

Beispiel für den Anforderungstext (uai-body.json):

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

Löschen eines Clusters

Wenn ein Cluster gelöscht wird, werden die Ressourcen in Azure und der Cluster gelöscht, der sich in der lokalen Umgebung befindet.

Hinweis

Wenn im Cluster Mandantenressourcen vorhanden sind, wird der Cluster erst gelöscht, nachdem diese Ressourcen gelöscht worden sind.

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

Freigeben über

Erstellen und Bereitstellen eines Clusters mithilfe der Azure CLI

Voraussetzungen

API-Leitfaden und -Metriken

Begrenzungen

Erstellen eines Clusters

Erstellen Sie den Cluster mithilfe der Azure CLI:

Parameter für Clustervorgänge

Clusteridentität

Erstellen des Clusters mithilfe des Azure Resource Manager-Vorlagen-Editors

Clustervalidierung

Clusterprotokollierung

Festlegen von Bereitstellungsschwellenwerten

Überprüfen von Updates

Bereitstellen eines Clusters

Clusterbereitstellung mit Hardwareprüfung

Clusterbereitstellung mit Überspringen eines bestimmten Bare-Metal-Computers

Fehler bei der Clusterbereitstellung

Überprüfung der Clusterbereitstellung

Protokollierung der Clusterbereitstellung

Aktualisieren von Clusteridentitäten über APIs

Löschen eines Clusters

Feedback

Zusätzliche Ressourcen