Bagikan melalui


Membuat dan memprovisikan Kluster menggunakan Azure CLI

Artikel ini menjelaskan cara membuat Kluster dengan menggunakan Azure Command Line Interface (AzCLI). Dokumen ini juga menunjukkan kepada Anda cara memeriksa status, memperbarui, atau menghapus Kluster.

Prasyarat

  • Verifikasi bahwa Network Fabric Controller dan Cluster Manger ada di wilayah Azure Anda
  • Verifikasi bahwa Network Fabric berhasil disediakan

Panduan dan metrik API

Panduan API menyediakan informasi tentang penyedia sumber daya dan model sumber daya, dan API.

Metrik yang dihasilkan dari data pengelogan tersedia dalam metrik Azure Monitor.

Batasan

  • Penamaan - Aturan penamaan dapat ditemukan di sini.

Membuat Kluster

Sumber daya Kluster Infrastruktur mewakili penyebaran platform lokal dalam Manajer Kluster. Semua sumber daya khusus platform lainnya bergantung padanya untuk siklus hidupnya.

Anda harus membuat Network Fabric sebelum penyebaran lokal ini. Setiap instans lokal Operator Nexus memiliki asosiasi satu-ke-satu dengan Network Fabric.

Buat Kluster menggunakan 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 untuk operasi kluster

Nama Parameter Deskripsi
CLUSTER_NAME Nama Sumber Daya Kluster
LOCATION Wilayah Azure tempat Kluster disebarkan
CL_NAME Lokasi Kustom Manajer Kluster dari portal Azure
CLUSTER_RG Nama grup sumber daya kluster
LAW_ID ID Ruang Kerja Analitik Log untuk Kluster
CLUSTER_LOCATION Nama lokal Kluster
AGGR_RACK_RESOURCE_ID RackID untuk Aggregator Rack
AGGR_RACK_SKU SKU Rak untuk Rak Agregator *Lihat SKU Cloud Jaringan Nexus Operator
AGGR_RACK_SN Nomor Seri Rak untuk Rak Agregator
AGGR_RACK_LOCATION Lokasi fisik rak untuk Aggregator Rack
AGGR_RACK_BMM Digunakan hanya untuk penyebaran rak tunggal, kosong untuk multi-rak
SA_NAME Nama Perangkat Storage Appliance
SA_PASS Kata sandi admin Storage Appliance
SA_USER Pengguna admin Storage Appliance
SA_SN Nomor Seri Peralatan Penyimpanan
COMPX_RACK_RESOURCE_ID RackID untuk CompX Rack; ulangi untuk setiap rak dalam definisi komputasi-rak
COMPX_RACK_SKU SKU Rak untuk CompX Rack; ulangi untuk setiap rak dalam definisi rak komputasi *Lihat SKU Cloud Jaringan Nexus Operator
COMPX_RACK_SN Nomor Seri Rak untuk Rak CompX; ulangi untuk setiap rak dalam definisi komputasi-rak
COMPX_RACK_LOCATION Lokasi fisik rak untuk CompX Rack; ulangi untuk setiap rak dalam definisi komputasi-rak
COMPX_SVRY_BMC_PASS Kata sandi Compx Rack Servery Baseboard Management Controller (BMC) ; ulangi untuk setiap rak dalam definisi komputasi-rak dan untuk setiap server di rak
COMPX_SVRY_BMC_USER Pengguna Compx Rack Servery BMC; ulangi untuk setiap rak dalam definisi komputasi-rak dan untuk setiap server di rak
COMPX_SVRY_BMC_MAC Alamat MAC Compx Rack Servery BMC; ulangi untuk setiap rak dalam definisi komputasi-rak dan untuk setiap server di rak
COMPX_SVRY_BOOT_MAC Alamat MAC Kartu Antarmuka Jaringan (NIC) boot Compx Rack ServerY; ulangi untuk setiap rak dalam definisi komputasi-rak dan untuk setiap server di rak
COMPX_SVRY_SERVER_DETAILS Detail Compx Rack Servery; ulangi untuk setiap rak dalam definisi komputasi-rak dan untuk setiap server di rak
COMPX_SVRY_SERVER_NAME Nama Compx Rack ServerY; ulangi untuk setiap rak dalam definisi komputasi-rak dan untuk setiap server di rak
MRG_NAME Nama grup sumber daya terkelola kluster
MRG_LOCATION Wilayah Azure kluster
NF_ID Referensi ke Network Fabric
SP_APP_ID ID Aplikasi Perwakilan Layanan
SP_PASS Kata Sandi Perwakilan Layanan
SP_ID ID Perwakilan Layanan
TENANT_ID ID penyewa langganan
SUBSCRIPTION_ID ID Langganan
KV_RESOURCE_ID Key Vault ID
CLUSTER_TYPE Jenis kluster, Tunggal, atau MultiRack
CLUSTER_VERSION Versi Kluster Network Cloud (NC)
TAG_KEY1 Tag1 opsional untuk diteruskan ke Pembuatan Kluster
TAG_VALUE1 Nilai tag1 opsional untuk diteruskan ke Buat Kluster
TAG_KEY2 Tag2 opsional untuk diteruskan ke Pembuatan Kluster
TAG_VALUE2 Nilai tag2 opsional untuk diteruskan ke Buat Kluster

Identitas Kluster

Dimulai dengan versi API 2024-07-01, pelanggan dapat menetapkan identitas terkelola ke Kluster. Identitas terkelola yang ditetapkan sistem dan yang Ditetapkan Pengguna didukung.

Setelah ditambahkan, Identitas hanya dapat dihapus melalui panggilan API saat ini.

Lihat Dukungan Kluster Nexus Operator Azure untuk Identitas Terkelola dan Sumber Daya yang Disediakan Pengguna untuk informasi selengkapnya tentang identitas terkelola untuk Kluster Nexus Operator.

Membuat Kluster menggunakan editor templat Azure Resource Manager

Cara alternatif untuk membuat Kluster adalah dengan editor templat ARM.

Untuk membuat kluster dengan cara ini, Anda perlu menyediakan file templat (cluster.jsonc) dan file parameter (cluster.parameters.jsonc). Anda dapat menemukan contoh untuk kluster SKU 8-Rack 2M16C menggunakan dua file ini:

cluster.jsonc , cluster.parameters.jsonc

Catatan

Untuk mendapatkan pemformatan yang benar, salin file kode mentah. Nilai dalam file cluster.parameters.jsonc spesifik pelanggan dan mungkin bukan daftar lengkap. Perbarui bidang nilai untuk lingkungan spesifik Anda.

  1. Navigasi ke portal Azure di browser web dan masuk.
  2. Cari 'Sebarkan templat kustom' di bilah pencarian portal Azure, lalu pilih dari layanan yang tersedia.
  3. Klik Bangun templat Anda sendiri di editor.
  4. Klik Muat file. Temukan file templat cluster.jsonc Anda dan unggah.
  5. Klik Simpan.
  6. Klik Edit parameter.
  7. Klik Muat file. Temukan file parameter cluster.parameters.jsonc Anda dan unggah.
  8. Klik Simpan.
  9. Pilih Langganan yang benar.
  10. Cari grup Sumber Daya untuk melihat apakah sudah ada. Jika tidak, buat grup Sumber Daya baru.
  11. Pastikan semua Detail Instans sudah benar.
  12. Klik Tinjau + buat.

Validasi kluster

Pembuatan Kluster Nexus Operator yang berhasil menghasilkan pembuatan sumber daya Azure di dalam langganan Anda. ID kluster, status provisi kluster, dan status penyebaran dikembalikan sebagai hasil dari keberhasilan cluster create.

Lihat status Kluster:

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

Pembuatan Kluster selesai ketika provisioningState sumber daya menunjukkan: "provisioningState": "Succeeded"

Pengelogan kluster

Log pembuatan kluster dapat dilihat di lokasi berikut:

  1. portal Azure log Aktivitas Resource/ResourceGroup.
  2. Azure CLI dengan --debug bendera diteruskan pada baris perintah.

Mengatur ambang penyebaran

Ada dua jenis ambang penyebaran yang dapat diatur pada kluster sebelum penyebaran kluster. Mereka adalah compute-deployment-threshold dan update-strategy.

--compute-deployment-threshold - Ambang validasi yang menunjukkan kegagalan simpul komputasi yang diizinkan selama validasi perangkat keras lingkungan.

Jika compute-deployment-threshold tidak diatur, defaultnya adalah sebagai berikut:

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

Jika pelanggan meminta compute-deployment-threshold bahwa itu berbeda dari default 80%, Anda dapat menjalankan perintah pembaruan kluster berikut.

Contoh di bawah ini adalah untuk pelanggan yang meminta jenis "PercentSuccess" dengan tingkat keberhasilan 97%.

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

Memvalidasi pembaruan

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

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

Dalam contoh ini, jika kurang dari 97% simpul komputasi yang disebarkan melewati validasi perangkat keras, penyebaran kluster akan gagal. CATATAN: Semua sarana kontrol kubernetes (KCP) dan sarana manajemen nexus (NMP) harus melewati validasi perangkat keras. Jika 97% atau lebih dari simpul komputasi yang disebarkan melewati validasi perangkat keras, penyebaran kluster akan berlanjut ke fase provisi bootstrap. Selama provisi bootstrap komputasi, update-strategy (di bawah) digunakan untuk simpul komputasi.

--update-strategy - Strategi untuk memperbarui kluster yang menunjukkan kegagalan simpul komputasi yang diizinkan selama provisi bootstrap.

Jika pelanggan meminta ambang update-strategy batas yang berbeda dari default 80%, Anda dapat menjalankan perintah pembaruan kluster berikut.

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>

Jenis strategi dapat berupa "Rack" (Rack by Rack) ATAU "PauseAfterRack" (Tunggu respons pelanggan untuk melanjutkan).

Jenis ambang batas dapat berupa "PercentSuccess" ATAU "CountSuccess".

Jika updateStrategy tidak diatur, defaultnya adalah sebagai berikut:

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

Contoh di bawah ini adalah untuk pelanggan yang menggunakan strategi Rack by Rack dengan Keberhasilan Persen 60% dan jeda 1 menit.

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>

Verifikasi pembaruan:

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

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

Dalam contoh ini, jika kurang dari 60% dari simpul komputasi yang disediakan dalam rak gagal disediakan (berdasarkan rak berdasarkan rak), penyebaran kluster akan gagal. Jika 60% atau lebih dari simpul komputasi berhasil disediakan, penyebaran kluster berpindah ke rak simpul komputasi berikutnya.

Contoh di bawah ini adalah untuk pelanggan yang menggunakan strategi Rack by Rack dengan jenis ambang batas CountSuccess 10 node per rak dan jeda 1 menit.

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>

Verifikasi pembaruan:

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

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

Dalam contoh ini, jika kurang dari 10 simpul komputasi yang disediakan di rak gagal disediakan (berdasarkan rak berdasarkan rak), penyebaran kluster akan gagal. Jika 10 atau lebih simpul komputasi berhasil disediakan, penyebaran kluster beralih ke rak simpul komputasi berikutnya.

Catatan

Ambang penyebaran tidak dapat diubah setelah penyebaran kluster dimulai.

Sebarkan Kluster

Tindakan sebarkan Kluster dapat dipicu setelah membuat Kluster. Tindakan sebarkan Kluster membuat gambar bootstrap dan menyebarkan Kluster.

Sebarkan Kluster memulai urutan peristiwa yang terjadi di Manajer Kluster.

  1. Validasi properti kluster/rak.
  2. Pembuatan gambar yang dapat di-boot untuk kluster bootstrap ephemeral (Validasi Infrastruktur).
  3. Interaksi dengan antarmuka Intelligent Platform Management Interface (IPMI) dari komputer bootstrap yang ditargetkan.
  4. Melakukan pemeriksaan validasi perangkat keras.
  5. Pemantauan proses penyebaran Kluster.

Sebarkan Kluster lokal:

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

Tip

Untuk memeriksa status az networkcloud cluster deploy perintah, perintah dapat dijalankan menggunakan --debug bendera . Ini akan memungkinkan Anda untuk mendapatkan header atau Location yang Azure-AsyncOperation digunakan untuk mengkueri operationStatuses sumber daya. Lihat bagian Penyebaran Kluster Gagal untuk langkah-langkah yang lebih rinci. Secara opsional, perintah dapat berjalan secara asinkron menggunakan --no-wait bendera .

Penyebaran Kluster dengan validasi perangkat keras

Selama proses penyebaran Kluster, salah satu langkah yang dijalankan adalah validasi perangkat keras. Prosedur validasi perangkat keras menjalankan berbagai pengujian dan pemeriksaan terhadap mesin yang disediakan melalui definisi rak Kluster. Berdasarkan hasil pemeriksaan ini dan setiap komputer yang dilewati pengguna, penentuan dilakukan pada apakah simpul yang cukup lolos dan/atau tersedia untuk memenuhi ambang batas yang diperlukan agar penyebaran berlanjut.

Penting

Proses validasi perangkat keras akan menulis hasilnya ke yang ditentukan analyticsWorkspaceId di Pembuatan Kluster. Selain itu, Perwakilan Layanan yang disediakan dalam objek Kluster digunakan untuk autentikasi terhadap API Pengumpulan Data Ruang Kerja Analitik Log. Kemampuan ini hanya terlihat selama penyebaran baru (Bidang Hijau); kluster yang ada tidak akan memiliki log yang tersedia secara retroaktif.

Catatan

Pengontrol RAID diatur ulang selama penyebaran Kluster menghapus semua data dari disk virtual server. Peringatan disk virtual Baseboard Management Controller (BMC) biasanya dapat diabaikan kecuali ada peringatan disk fisik dan/atau pengontrol RAID tambahan.

Secara default, proses validasi perangkat keras menulis hasilnya ke Kluster analyticsWorkspaceIdyang dikonfigurasi . Namun, karena sifat pengumpulan data dan evaluasi skema Ruang Kerja Analitik Log, mungkin ada penundaan penyerapan yang dapat memakan waktu beberapa menit atau lebih. Untuk alasan ini, penyebaran Kluster berlanjut bahkan jika ada kegagalan untuk menulis hasilnya ke Ruang Kerja Analitik Log. Untuk membantu mengatasi kemungkinan peristiwa ini, hasilnya, untuk redundansi, juga dicatat dalam Manajer Kluster.

Di Ruang Kerja Analitik Log objek Kluster yang disediakan, tabel kustom baru dengan nama Kluster sebagai awalan dan akhiran *_CL akan muncul. Di bagian Log sumber daya LAW, kueri dapat dijalankan terhadap tabel Log Kustom baru *_CL .

Penyebaran Kluster dengan melewatkan mesin bare-metal tertentu

Parameter --skip-validation-for-machines mewakili nama mesin bare metal dalam kluster yang harus dilewati selama validasi perangkat keras. Simpul yang dilewati tidak divalidasi dan tidak ditambahkan ke kumpulan simpul. Selain itu, simpul yang dilewati tidak dihitung terhadap total yang digunakan oleh perhitungan ambang batas.

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

Penyebaran Kluster gagal

Untuk melacak status operasi asinkron, jalankan dengan --debug bendera diaktifkan. Ketika --debug ditentukan, kemajuan permintaan dapat dipantau. URL status operasi dapat ditemukan dengan memeriksa output debug yang mencari Azure-AsyncOperation header atau Location pada respons HTTP terhadap permintaan pembuatan. Header dapat menyediakan bidang yang OPERATION_ID digunakan dalam panggilan 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"

Outputnya mirip dengan contoh struct JSON. Ketika kode kesalahan adalah HardwareValidationThresholdFailed, maka pesan kesalahan berisi daftar mesin bare metal yang gagal validasi perangkat keras (misalnya, COMP0_SVR0_SERVER_NAME, COMP1_SVR1_SERVER_NAME). Nama-nama ini dapat digunakan untuk mengurai log untuk detail lebih lanjut.

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

Lihat artikel Melacak Operasi Asinkron Menggunakan Azure CLI untuk contoh lain. Lihat artikel Memecahkan masalah provisi BMM untuk informasi selengkapnya yang mungkin berguna saat komputer tertentu gagal validasi atau penyebaran.

Validasi penyebaran kluster

Lihat status kluster di portal, atau melalui Azure CLI:

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

Penyebaran Kluster sedang berlangsung ketika detailedStatus diatur ke Deploying dan detailedStatusMessage menunjukkan kemajuan penyebaran. Beberapa contoh kemajuan penyebaran yang ditampilkan dalam detailedStatusMessage adalah Hardware validation is in progress. (jika kluster disebarkan dengan validasi perangkat keras), Cluster is bootstrapping., , KCP initialization in progress.Management plane deployment in progress., Cluster extension deployment in progress., waiting for "<rack-ids>" to be ready, dll.

Cuplikan layar portal Azure memperlihatkan klaster menyebarkan kemajuan kcp init.

Cuplikan layar portal Azure memperlihatkan aplikasi ekstensi kemajuan penyebaran kluster.

Penyebaran Kluster selesai ketika detailedStatus diatur ke Running dan detailedStatusMessage menunjukkan pesan Cluster is up and running.

Cuplikan layar portal Azure memperlihatkan penyebaran kluster selesai.

Lihat versi manajemen kluster:

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"

Pengelogan penyebaran kluster

Log pembuatan kluster dapat dilihat di lokasi berikut:

  1. portal Azure log Aktivitas Resource/ResourceGroup.
  2. Azure CLI dengan --debug bendera diteruskan pada baris perintah.

Cuplikan layar portal Azure memperlihatkan kluster menyebarkan log aktivitas kemajuan.

Menghapus kluster

Menghapus kluster akan menghapus sumber daya di Azure dan kluster yang berada di lingkungan lokal.

Catatan

Jika ada sumber daya penyewa yang ada di kluster, sumber daya tersebut tidak akan dihapus hingga sumber daya tersebut dihapus.

Cuplikan layar portal memperlihatkan kegagalan untuk dihapus karena sumber daya penyewa.

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

Catatan

Disarankan untuk menunggu selama 20 menit setelah menghapus kluster sebelum mencoba membuat kluster baru dengan nama yang sama.