Memperbaiki masalah dan kesalahan yang diketahui saat mengonfigurasi jaringan di AKS Arc

Agen cloud mungkin gagal memulai saat menggunakan nama jalur dengan spasi di dalamnya.

Saat menggunakan Set-AksHciConfig untuk menentukan parameter , -workingDir, -cloudConfigLocation, atau -nodeConfigLocation dengan nama jalur yang berisi karakter spasi, seperti D:\Cloud Share\AKS HCI, layanan kluster agen cloud akan gagal memulai dengan pesan kesalahan berikut (atau serupa):

Failed to start the cloud agent generic cluster service in failover cluster. The cluster resource group os in the 'failed' state. Resources in 'failed' or 'pending' states: 'MOC Cloud Agent Service'

Untuk mengatasi masalah ini, gunakan jalur yang tidak menyertakan spasi, misalnya, C:\CloudShare\AKS-HCI.

Azure Arc untuk kluster yang terhubung dengan Kubernetes dapat memiliki nilai untuk properti distribution JSON yang diatur ke string kosong. Untuk kluster yang terhubung dengan AKS Arc, nilai ini diatur selama penginstalan awal dan tidak pernah diubah selama masa penyebaran.

Untuk mereproduksi masalah, buka jendela Azure PowerShell dan jalankan perintah berikut:

az login
az account set --subscription <sub_id>
az connectedk8s show -g <rg_name> -n

Berikut ini adalah contoh output dari perintah ini:

{
"agentPublicKeyCertificate": <value>
"agentVersion": "1.8.14",
"azureHybridBenefit": "NotApplicable",
"connectivityStatus": "Connected",
"distribution": "",
"distributionVersion": null,
"id": "/subscriptions/<subscription>/resourceGroups/<resource group>/providers/Microsoft.Kubernetes/connectedClusters/<cluster name>",
"identity": {
  "principalId": "<principal id>",
  "tenantId": "<tenant id>",
  "type": "SystemAssigned"
},
"infrastructure": "azure_stack_hci",
"kubernetesVersion": "1.23.12",
"lastConnectivityTime": "2022-11-04T14:59:59.050000+00:00",
"location": "eastus",
"managedIdentityCertificateExpirationTime": "2023-02-02T14:24:00+00:00",
"miscellaneousProperties": null,
"name": "mgmt-cluster",
"offering": "AzureStackHCI_AKS_Management",
"privateLinkScopeResourceId": null,
"privateLinkState": "Disabled",
"provisioningState": "Succeeded",
"resourceGroup": "<resource group>",
"systemData": {
  "createdAt": "2022-11-04T14:29:17.680060+00:00",
  "createdBy": "<>",
  "createdByType": "Application",
  "lastModifiedAt": "2022-11-04T15:00:01.830067+00:00",
  "lastModifiedBy": "64b12d6e-6549-484c-8cc6-6281839ba394",
  "lastModifiedByType": "Application"
},
"tags": {},
"totalCoreCount": 4,
"totalNodeCount": 1,
"type": "microsoft.kubernetes/connectedclusters"
}

Untuk mengatasi masalah ini

Jika output untuk properti JSON distribution mengembalikan string kosong, ikuti instruksi berikut untuk menambal kluster Anda:

1. Salin konfigurasi berikut ke dalam file yang disebut patchBody.json:

   {
      "properties": {
        "distribution": "aks_management"
      }
   }
   

   Penting

   Jika kluster Anda adalah kluster manajemen AKS, nilainya harus diatur ke aks_management. Jika itu adalah kluster beban kerja, kluster harus diatur ke aks_workload.

2. Dari output JSON yang Anda peroleh di atas, salin ID kluster yang terhubung. Ini akan muncul sebagai string panjang dalam format berikut:

   "/subscriptions/<subscription >/resourceGroups/<resource group>/providers/Microsoft.Kubernetes/connectedClusters/<cluster name>",

3. Jalankan perintah berikut untuk menambal kluster Anda. Nilai <cc_arm_id> harus berupa ID yang diperoleh pada langkah 2:

   az rest -m patch -u "<cc_arm_id>?api-version=2022-10-01-preview" -b "@patchBody.json"
   

4. Periksa apakah kluster Anda telah berhasil di-patch dengan menjalankan az connectedk8s show -g <rg_name> -n <cc_name> untuk memastikan properti distribution JSON telah diatur dengan benar.

Gejala:

• Proksi diaktifkan di AKS Arc. Layanan WSSDAgent terjebak dalam status starting . Muncul sebagai berikut:
• Test-NetConnection -ComputerName <computer IP/Name> -Port <port> dari simpul tempat agen node gagal menuju agen cloud bekerja dengan baik pada sistem (bahkan ketika wssdagent gagal memulai)
• Curl.exe dari simpul tempat agen gagal menuju agen cloud mereproduksi masalah dan terjebak: curl.exe https://<computerIP>:6500
• Untuk memperbaiki masalah, berikan --noproxy bendera ke curl.exe. Curl mengembalikan kesalahan dari wssdcloudagent. Ini diharapkan karena curl bukan klien GRPC. Curl tidak terjebak menunggu ketika Anda mengirim --noproxy bendera. Jadi mengembalikan kesalahan dianggap sebagai keberhasilan di sini):

curl.exe --noproxy '*' https://<computerIP>:65000

Kemungkinan pengaturan proksi diubah menjadi proksi yang rusak pada host. Pengaturan proksi untuk AKS Arc adalah variabel lingkungan yang diwarisi dari proses induk pada host. Pengaturan ini hanya disebarluaskan ketika layanan baru dimulai atau yang lama memperbarui atau me-reboot. Ada kemungkinan bahwa pengaturan proksi yang salah diatur pada host, dan mereka disebarluaskan ke WSSDAgent setelah pembaruan atau boot ulang, yang menyebabkan WSSDAgent gagal.

Anda harus memperbaiki pengaturan proksi dengan mengubah variabel lingkungan pada komputer. Pada komputer, ubah variabel dengan perintah berikut:

  [Environment]::SetEnvironmentVariable("https_proxy", <Value>, "Machine")
  [Environment]::SetEnvironmentVariable("http_proxy", <Value>, "Machine")
  [Environment]::SetEnvironmentVariable("no_proxy", <Value>, "Machine")

Reboot mesin sehingga manajer layanan, dan WSSDAgent, mengambil proksi tetap.

Kesalahan ini terjadi karena setiap kali pod CAPH dimulai, login ke cloudagent dicoba dan sertifikat disimpan dalam volume penyimpanan sementara, yang akan dibersihkan pada pod yang dimulai ulang. Oleh karena itu, setiap kali pod dimulai ulang, sertifikat dihancurkan dan upaya masuk baru dilakukan.

Upaya masuk memulai rutinitas perpanjangan, yang memperbarui sertifikat ketika hampir kedaluwarsa. Pod CAPH memutuskan apakah login diperlukan jika sertifikat tersedia atau tidak. Jika sertifikat tersedia, login tidak dicoba, dengan asumsi rutinitas perpanjangan sudah ada.

Namun, pada restart kontainer, direktori sementara tidak dibersihkan, sehingga file masih bertahan dan upaya masuk tidak dilakukan, menyebabkan rutinitas perpanjangan tidak dimulai. Ini menyebabkan kedaluwarsa sertifikat.

Untuk mengurangi masalah ini, mulai ulang pod CAPH menggunakan perintah berikut:

kubectl delete pod pod-name

Saat menjalankan Set-AksHciConfig, Anda mungkin mengalami kesalahan berikut:

WinRM service is already running on this machine.
WinRM is already set up for remote management on this computer.
Powershell remoting to TK5-3WP08R0733 was not successful.
At C:\Program Files\WindowsPowerShell\Modules\Moc\0.2.23\Moc.psm1:2957 char:17
+ ...             throw "Powershell remoting to "+$env:computername+" was n ...
+                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : OperationStopped: (Powershell remo...not successful.:String) [], RuntimeException
    + FullyQualifiedErrorId : Powershell remoting to TK5-3WP08R0733 was not successful.

Sering kali, kesalahan ini terjadi sebagai akibat dari perubahan token pengguna (karena perubahan dalam keanggotaan grup), perubahan kata sandi, atau kata sandi yang kedaluwarsa. Dalam kebanyakan kasus, masalah dapat diperbaiki dengan keluar dari komputer dan masuk kembali. Jika kesalahan masih terjadi, Anda dapat membuat tiket dukungan melalui portal Azure.

Masalah ini menyebabkan kluster AKS Arc tetap dalam status ScalingControlPlane untuk jangka waktu yang lama.

Untuk mereprodusi

Get-AksHciCluster -Name <cluster name> | select *

Status                : {ProvisioningState, Details}
ProvisioningState     : ScalingControlPlane
KubernetesVersion     : v1.22.6
PackageVersion        : v1.22.6-kvapkg.0
NodePools             : {nodepoolA, nodepoolB}
WindowsNodeCount      : 0
LinuxNodeCount        : 1
ControlPlaneNodeCount : 1
ControlPlaneVmSize    : Standard_D4s_v3
AutoScalerEnabled     : False
AutoScalerProfile     :
Name                  : <cluster name>

Masalah ini telah diperbaiki dalam versi AKS Arc terbaru. Sebaiknya perbarui kluster AKS Arc Anda ke rilis terbaru.

Untuk mengurangi masalah ini, hubungi dukungan untuk menambal status simpul sarana kontrol secara manual untuk menghapus kondisi MachineOwnerRemediatedCondition dari status komputer melalui kubectl.

Kluster beban kerja mungkin tidak ditemukan jika kumpulan alamat IP dari dua penyebaran AKS di Azure Stack HCI sama atau tumpang tindih. Jika Anda menyebarkan dua host AKS dan menggunakan konfigurasi yang sama AksHciNetworkSetting untuk keduanya, PowerShell dan Windows Admin Center akan berpotensi gagal menemukan kluster beban kerja karena server API akan diberi alamat IP yang sama di kedua kluster, yang mengakibatkan konflik.

Pesan kesalahan yang Anda terima akan terlihat mirip dengan contoh yang ditunjukkan di bawah.

A workload cluster with the name 'clustergroup-management' was not found.
At C:\Program Files\WindowsPowerShell\Modules\Kva\0.2.23\Common.psm1:3083 char:9
+         throw $("A workload cluster with the name '$Name' was not fou ...
+         ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : OperationStopped: (A workload clus... was not found.:String) [], RuntimeException
    + FullyQualifiedErrorId : A workload cluster with the name 'clustergroup-management' was not found.

Untuk mengatasi masalah ini, hapus salah satu kluster dan buat pengaturan jaringan kluster AKS baru yang memiliki jaringan yang tidak tumpang tindih dengan kluster lain.

Menjalankan perintah Get-AksHciClusterNetwork menyediakan daftar semua konfigurasi jaringan virtual. Namun, perintah tidak menunjukkan alokasi alamat IP saat ini.

Untuk mengetahui alamat IP apa yang saat ini digunakan dalam jaringan virtual, gunakan langkah-langkah di bawah ini:

1. Untuk mendapatkan grup, jalankan perintah berikut:

Get-MocGroup -location MocLocation

2. Untuk mendapatkan daftar alamat IP yang saat ini sedang digunakan, dan daftar alamat IP virtual yang tersedia atau digunakan, jalankan perintah berikut:

Get-MocNetworkInterface -Group <groupName> | ConvertTo-Json -depth 10

3. Gunakan perintah berikut untuk melihat daftar alamat IP virtual yang saat ini sedang digunakan:

Get-MocLoadBalancer -Group <groupName> | ConvertTo-Json -depth 10

Alamat IP kluster ditampilkan sebagai "Gagal" selama pra-pemeriksaan. Pra-pemeriksaan ini menguji bahwa semua alamat IPv4 dan nama jaringan DNS online dan dapat dijangkau. Misalnya, IPv4 atau nama jaringan yang gagal dapat menyebabkan pengujian ini gagal.

Untuk mengatasinya, lakukan langkah-langkah berikut:

1. Jalankan perintah berikut:

   Get-ClusterGroup -name "Cluster Group" | Get-ClusterResource
   

2. Pastikan bahwa semua nama jaringan dan alamat IP berada dalam status online.

3. Jalankan kedua perintah berikut:

   Stop-ClusterResource -name "Cluster IP Address x.x.x.x"
   

   dan kemudian

   Start-ClusterResource -name "Cluster IP Address x.x.x.x"
   

Saat Anda menyebarkan AKS di Azure Stack HCI, penyebaran mungkin kehabisan waktu di titik proses yang berbeda tergantung di mana kesalahan konfigurasi terjadi. Anda harus meninjau pesan kesalahan untuk menentukan penyebab dan di mana kesalahan terjadi.

Misalnya, dalam kesalahan berikut, titik tempat kesalahan konfigurasi terjadi adalah di Get-DownloadSdkRelease -Name "mocstack-stable":

$vnet = New-AksHciNetworkSettingSet-AksHciConfig -vnet $vnetInstall-AksHciVERBOSE: 
Initializing environmentVERBOSE: [AksHci] Importing ConfigurationVERBOSE: 
[AksHci] Importing Configuration Completedpowershell : 
GetRelease - error returned by API call: 
Post "https://msk8s.api.cdp.microsoft.com/api/v1.1/contents/default/namespaces/default/names/mocstack-stable/versions/0.9.7.0/files?action=generateDownloadInfo&ForegroundPriority=True": 
dial tcp 52.184.220.11:443: connectex: 
A connection attempt failed because the connected party did not properly
respond after a period of time, or established connection failed because
connected host has failed to respond.At line:1 char:1+ powershell -command
{ Get-DownloadSdkRelease -Name "mocstack-stable"}

Hal ini menunjukkan bahwa node fisik Azure Stack HCI dapat menyelesaikan nama URL unduhan, msk8s.api.cdp.microsoft.com, tetapi node tidak dapat terhubung ke server target.

Untuk mengatasi masalah ini, Anda perlu menentukan di mana kerusakan terjadi dalam alur koneksi. Berikut adalah beberapa langkah untuk mencoba menyelesaikan masalah dari node kluster fisik:

1. Ping nama DNS tujuan: ping msk8s.api.cdp.microsoft.com.
2. Jika Anda mendapatkan respons kembali dan tidak ada waktu istirahat, maka jalur jaringan dasar berfungsi.
3. Jika waktu koneksi habis, maka mungkin ada jeda di jalur data. Untuk informasi selengkapnya, lihat memeriksa pengaturan proksi. Selain itu, mungkin ada kerusakan di jalur pengembalian, jadi Anda harus memeriksa aturan firewall.

Aplikasi yang bergantung pada waktu NTP dapat memicu ratusan pemberitahuan palsu ketika tidak ada sinkronisasi waktu. Jika kluster berjalan di lingkungan proksi, kumpulan simpul Anda mungkin tidak dapat berkomunikasi dengan server NTP default, time.windows.com, melalui proksi atau firewall Anda.

Solusi Sementara

Untuk mengatasi masalah ini, perbarui konfigurasi server NTP pada setiap simpul nodepool untuk menyinkronkan jam. Melakukannya juga akan mengatur jam di setiap pod aplikasi Anda.

Prasyarat

• Alamat server NTP yang dapat diakses di setiap simpul nodepool.
• Akses ke file kubeconfig kluster beban kerja.
• Akses ke kubeconfig kluster manajemen.

Langkah-langkah

1. Jalankan perintah berikut kubectl menggunakan kubeconfig kluster beban kerja untuk mendapatkan daftar simpul di dalamnya:

   kubectl --kubeconfig <PATH TO KUBECONFIG> get nodes -owide
   

2. Jalankan perintah berikut kubectl untuk menghubungkan nama simpul dari perintah sebelumnya ke simpul nodepool kluster beban kerja. Catat alamat IP yang relevan dari output perintah sebelumnya.

   kubectl --kubeconfig (Get-KvaConfig).kubeconfig get machine -l cluster.x-k8s.io/cluster-name=<WORKLOAD_CLUSTER_NAME>
   

3. Dengan menggunakan output dari langkah-langkah sebelumnya, jalankan langkah-langkah berikut untuk setiap simpul nodepool yang memerlukan konfigurasi NTP-nya diperbarui:

   1. SSH ke dalam nodepool VM:

      ssh -o StrictHostKeyChecking=no -i (Get-MocConfig).sshPrivateKey clouduser@<NODEPOOL_IP>
      

   2. Verifikasi bahwa server NTP yang dikonfigurasi tidak dapat dijangkau:

      sudo timedatectl timesync-status
      

      Jika output terlihat seperti ini, maka server NTP tidak dapat dijangkau dan perlu diubah:

      Server: n/a (time.windows.com)
      Poll interval: 0 (min: 32s; max 34min 8s)
      Packet count: 0
      

   3. Untuk memperbarui server NTP, jalankan perintah berikut untuk mengatur server NTP dalam file konfigurasi timesync ke server yang dapat diakses dari VM nodepool:

      # make a backup of the config file
      sudo cp /etc/systemd/timesyncd.conf ~/timesyncd.conf.bak
      
      # update the ntp server
      NTPSERVER="NEW_NTP_SERVER_ADDRESS"
      sudo sed -i -E "s|^(NTP=)(.*)$|\1$NTPSERVER|g" /etc/systemd/timesyncd.conf
      
      # verify that the NTP server is updated correctly - check the value for the field that starts with "NTP="
      sudo cat /etc/systemd/timesyncd.conf 
      

   4. Mulai ulang layanan timesync:

      sudo systemctl restart systemd-timesyncd.service
      

   5. Verifikasi bahwa server NTP dapat diakses:

      sudo timedatectl timesync-status
      

   6. Verifikasi bahwa jam menunjukkan waktu yang benar:

      date
      

4. Pastikan bahwa setiap simpul nodepool menunjukkan waktu yang sama dengan menjalankan perintah dari langkah 3.f.

5. Jika aplikasi Anda tidak memperbarui waktunya secara otomatis, hidupkan ulang pod-nya.

Langkah berikutnya

• Rangkuman Pemecahan Masalah
• Masalah dan kesalahan penginstalan
• Masalah penyimpanan diketahui