Memecahkan masalah manajemen Kubernetes dan kluster beban kerja di AKS Arc

Saat menjalankan perintah Remove-ClusterNode, simpul dikeluarkan dari kluster failover, tetapi jika Remove-AksHciNode tidak dijalankan setelahnya, simpul akan tetap ada di CloudAgent.

Karena simpul dihapus dari kluster, tetapi tidak dari CloudAgent, jika Anda menggunakan VHD untuk membuat simpul baru, kesalahan "File tidak ditemukan" muncul. Masalah ini terjadi karena VHD berada dalam penyimpanan bersama, dan simpul yang dihapus tidak memiliki akses ke simpul tersebut.

Untuk mengatasi masalah ini, hapus simpul fisik dari kluster lalu ikuti langkah-langkah berikut:

1. Jalankan Remove-AksHciNode untuk membatalkan pendaftaran node dari CloudAgent.
2. Lakukan pemeliharaan rutin, seperti pencitraan ulang mesin.
3. Tambahkan node kembali ke kluster.
4. Jalankan Add-AksHciNode untuk mendaftarkan node dengan CloudAgent.

Dengan kluster besar, perintah Get-AksHciLogs dapat memunculkan pengecualian, gagal menghitung node, atau tidak akan menghasilkan file output c:\wssd\wssdlogs.zip.

Ini karena perintah PowerShell untuk membuat zip file, 'Compress-Archive', memiliki batas ukuran file output 2 GB.

Setelah memutakhirkan atau meningkatkan skala kluster beban kerja, pod pembaruan sertifikat sekarang dalam status crash loop karena pod mengharapkan file YAML tato sertifikat dari lokasi file /etc/Kubernetes/pki.

Masalah ini mungkin disebabkan oleh file konfigurasi yang ada di mesin virtual sarana kontrol tetapi tidak di mesin virtual node pekerja.

Untuk mengatasi masalah ini, salin file YAML tato sertifikat secara manual dari node sarana kontrol ke semua node pekerja.

1. Salin file YAML dari mesin virtual sarana kontrol pada kluster beban kerja ke direktori mesin host Anda saat ini:

ssh clouduser@<comtrol-plane-vm-ip> -i (get-mocconfig).sshprivatekey
sudo cp /etc/kubernetes/pki/cert-tattoo-kubelet.yaml ~/
sudo chown clouduser cert-tattoo-kubelet.yaml
sudo chgrp clouduser cert-tattoo-kubelet.yaml
(Change file permissions here, so that `scp` will work)
scp -i (get-mocconfig).sshprivatekey clouduser@<comtrol-plane-vm-ip>:~/cert*.yaml .\

1. Salin file YAML dari mesin host ke mesin virtual node pekerja. Sebelum menyalin file, Anda harus mengubah nama mesin di file YAML ke nama node yang menjadi target penyalinan Anda (ini adalah nama node untuk sarana kontrol kluster beban kerja).

scp -i (get-mocconfig).sshprivatekey .\cert-tattoo-kubelet.yaml clouduser@<workernode-vm-ip>:~/cert-tattoo-kubelet.yaml

3. Jika informasi pemilik serta grup dalam file YAML belum diatur ke akar, atur informasi tersebut ke akar:

ssh clouduser@<workernode-vm-ip> -i (get-mocconfig).sshprivatekey
sudo cp ~/cert-tattoo-kubelet.yaml /etc/kubernetes/pki/cert-tattoo-kubelet.yaml (copies the certificate file to the correct location)
sudo chown root cert-tattoo-kubelet.yaml
sudo chgrp root cert-tattoo-kubelet.yaml

4. Ulangi langkah 2 dan 3 untuk semua node pekerja.

Perintah PowerShell Aks-Hci tidak memvalidasi memori yang tersedia pada server host sebelum membuat simpul Kubernetes. Masalah ini menyebabkan memori habis dan mesin virtual tidak bisa dimulai.

Kegagalan tersebut saat ini tidak ditangani dengan baik, dan penyebaran akan berhenti merespons tanpa pesan kesalahan yang jelas. Jika Anda memiliki penyebaran yang berhenti merespons, buka Pemantau Peristiwa dan periksa pesan kesalahan terkait Hyper-V yang menunjukkan bahwa memori tidak cukup untuk memulai mesin virtual.

Saat menjalankan Get-AksHciCluster untuk memverifikasi status penginstalan AKS Arc di Windows Admin Center, output menunjukkan kesalahan: "Rilis dengan versi 1.0.3.10818 TIDAK DITEMUKAN." Namun, saat menjalankan Get-AksHciVersion, itu menunjukkan versi yang sama diinstal. Kesalahan ini menunjukkan bahwa build telah kedaluwarsa.

Untuk mengatasi masalah ini, jalankan Uninstall-AksHci, lalu jalankan build AKS Arc baru.

Saat menggunakan alat administrasi kluster untuk memindahkan mesin virtual dari satu node (Node A) ke node lain (Node B) di kluster Azure Stack HCI, mesin virtual mungkin gagal untuk memulai pada node baru. Setelah dipindahkan kembali ke node asli, mesin virtual juga akan gagal untuk memulai di sana.

Masalah ini terjadi karena logika untuk membersihkan migrasi pertama berjalan secara asinkron. Akibatnya, logika "pembaruan lokasi mesin virtual" Azure Kubernetes Service akan menemukan mesin virtual pada Hyper-V asli pada simpul A dan menghapusnya, bukan membatalkan pendaftarannya.

Untuk mengatasi masalah ini, pastikan mesin virtual telah berhasil dimulai pada node baru sebelum memindahkannya kembali ke node asli.

Saat menggunakan PowerShell untuk membuat kluster dengan alamat IP statis dan kemudian mencoba meningkatkan jumlah simpul pekerja di kluster beban kerja, penginstalan macet di "jumlah sarana kontrol pada 2, masih menunggu status yang diinginkan: 3." Setelah jangka waktu tertentu, pesan kesalahan lain muncul: "Kesalahan: waktu habis menunggu kondisi."

Ketika Get-AksHciCluster dijalankan, ini menunjukkan bahwa node sarana kontrol dibuat dan diprovisikan serta berada dalam status Ready. Namun, ketika kubectl get nodes dijalankan, ia menampilkan bahwa simpul sarana kontrol telah dibuat tetapi tidak disediakan dan tidak dalam status Siap.

Jika Anda mendapatkan kesalahan ini, verifikasi bahwa alamat IP telah ditetapkan ke node yang dibuat menggunakan Hyper-V Manager atau PowerShell:

(Get-VM |Get-VMNetworkAdapter).IPAddresses |fl

Kemudian, verifikasi pengaturan jaringan untuk memastikan ada cukup alamat IP yang tersisa di kumpulan untuk membuat lebih banyak mesin virtual.

Perintah seperti Update-AksHci, , Update-AksHciCertificates, Update-AksHciClusterCertificatesdan semua interaksi dengan kluster manajemen, dapat mengembalikan "Kesalahan: Anda harus masuk ke server (Tidak Sah)."

Kesalahan ini dapat terjadi ketika file kubeconfig kedaluwarsa. Untuk memeriksa apakah kedaluwarsa, jalankan skrip berikut:

$kubeconfig= $(get-kvaconfig).kubeconfig
$certDataRegex = '(?ms).*client-certificate-data:\s*(?<CertData>[^\n\r]+)'
$certDataMatch = Select-String -Path $kubeconfig -Pattern $certDataRegex
$certData = $certDataMatch.Matches[0].Groups['CertData'].Value
$certObject = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2
$certObject.Import([System.Convert]::FromBase64String($certData))
$expiryDate = $certObject.GetExpirationDateString()
$expiryDate

Jika skrip ini menampilkan tanggal yang lebih awal dari tanggal saat ini, maka file kubeconfig telah kedaluwarsa.

Untuk mengurangi masalah, salin file admin.conf , yang ada di dalam VM sarana kontrol manajemen, ke host HCI:

• SSH ke VM sarana kontrol manajemen:

  • Dapatkan IP VM sarana kontrol manajemen:

    get-clusternode | % {Get-vm -computerName $_ } | get-vmnetworkadapter | select Name, IPAddresses
    

  • SSH ke dalamnya:

    ssh -o StrictHostKeyChecking=no -i (Get-MocConfig).sshPrivateKey clouduser@<mgmt-control-plane-ip>
    

• Salin file ke lokasi clouduser :

  cp /etc/kubernetes/admin.conf /home/clouduser/admin.conf
  

• Berikan akses ke clouduser:

  sudo chown clouduser:clouduser admin.conf
  

• [Opsional] Buat cadangan file kubeconfig :

  mv $(Get-KvaConfig).kubeconfig "$((Get-KvaConfig).kubeconfig).backup"
  

• Salin file:

  scp -i (get-mocconfig).sshPrivateKey clouduser@10.64.92.14:~/admin.conf $(Get-KvaConfig).kubeconfig
  

Saat Anda memeriksa Hyper-V manager, permintaan CPU dan memori yang tinggi untuk kluster manajemen dapat diabaikan dengan aman. Permintaan tersebut biasanya berhubungan dengan lonjakan penggunaan sumber daya komputasi saat memprovisikan kluster beban kerja.

Meningkatkan ukuran memori ataupun CPU untuk kluster manajemen belum menunjukkan peningkatan yang signifikan serta dapat diabaikan.

Anda akan melihat masalah ini jika mengikuti langkah-langkah berikut:

1. Membuat klaster Kubernetes.
2. Skalakan kluster ke lebih dari dua node.
3. Hapus node dengan menjalankan perintah berikut:

kubectl delete node <node-name>

4. Kembalikan daftar node dengan menjalankan perintah berikut:

kubectl get nodes

Node yang dihapus tidak tercantum dalam output. 5. Buka jendela PowerShell dengan hak administratif, dan jalankan perintah berikut:

get-vm

Node yang dihapus masih terdaftar.

Kegagalan ini menyebabkan sistem tidak menyadari bahwa simpul hilang; oleh karena itu, simpul baru tidak akan di-spin up.

Jika Anda tidak menggunakan kluster manajemen atau beban kerja selama lebih dari 60 hari, sertifikat kedaluwarsa, dan Anda harus memperbaruinya sebelum dapat meningkatkan AKS Arc. Ketika kluster AKS tidak ditingkatkan dalam waktu 60 hari, token plug-in KMS dan sertifikat keduanya kedaluwarsa dalam 60 hari. Kluster masih berfungsi. Namun, karena lebih dari 60 hari, Anda perlu memanggil dukungan Microsoft untuk meningkatkan. Jika kluster di-boot ulang setelah periode ini, kluster akan tetap dalam keadaan tidak berfungsi.

Untuk mengatasi masalah ini, jalankan langkah-langkah berikut:

1. Perbaiki sertifikat kluster manajemen dengan memutar token secara manual, lalu mulai ulang plug-in dan kontainer KMS.
2. Perbaiki sertifikat mocctl dengan menjalankan Repair-MocLogin.
3. Perbaiki sertifikat kluster beban kerja dengan memutar token secara manual, lalu mulai ulang plug-in dan kontainer KMS.

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 AksHciNetworkSetting yang sama untuk keduanya, PowerShell dan Windows Admin Center 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.

Penyebaran kluster besar mungkin kehabisan waktu setelah dua jam. Namun, ini adalah waktu habis statis.

Anda dapat mengabaikan kejadian waktu habis ini saat operasi berjalan di latar belakang. Gunakan perintah kubectl get nodes untuk mengakses kluster Anda dan memantau kemajuannya.

Saat mencoba penyebaran AKS di Azure Stack HCI setelah beberapa hari, Kubectl tidak menjalankan perintah apa pun. Log plug-in Key Management Service (KMS) menampilkan pesan kesalahan rpc error:code = Unauthenticated desc = Valid Token Required_. After running [Repair-AksHciCerts](./reference/ps/repair-akshcicerts.md) to try to fix the issue, a different error appeared: _failed to repair cluster certificates.

Cmdlet Repair-AksHciClusterCerts gagal jika server API mati. Jika AKS di Azure Stack HCI belum diperbarui selama 60 hari atau lebih, saat Anda mencoba menghidupkan ulang plug-in KMS, prosesnya tidak akan dimulai. Kegagalan ini juga menyebabkan server API gagal.

Untuk memperbaiki masalah ini, Anda perlu memutar token secara manual lalu menghidupkan ulang plug-in dan kontainer KMS guna mendapatkan cadangan server API. Untuk melakukannya, jalankan langkah-langkah berikut:

1. Putar token dengan menjalankan perintah berikut:

   $ mocctl.exe security identity rotate --name "KMSPlugin-<cluster-name>-moc-kms-plugin" --encode=false --cloudFqdn (Get-AksHciConfig).Moc.cloudfqdn > cloudlogin.yaml
   

2. Salin token ke mesin virtual menggunakan perintah berikut. Pengaturan ip dalam perintah di bawah ini mengacu pada alamat IP dari sarana kontrol host AKS.

   $ scp -i (Get-AksHciConfig).Moc.sshPrivateKey .\cloudlogin.yaml clouduser@<ip>:~/cloudlogin.yaml $ ssh -i (Get-AksHciConfig).Moc.sshPrivateKey clouduser@<ip> sudo mv cloudlogin.yaml /opt/wssd/k8s/cloudlogin.yaml
   

3. Hidupkan ulang plug-in KMS dan kontainer.

   Untuk mendapatkan ID kontainer, jalankan perintah berikut:

   $ ssh -i (Get-AksHciConfig).Moc.sshPrivateKey clouduser@<ip> "sudo docker container ls | grep 'kms'"
   

   Output akan muncul dengan bidang berikut:

   CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
   

   Output akan terlihat mirip dengan contoh ini:

   4169c10c9712 f111078dbbe1 "/kms-plugin" 22 minutes ago Up 22 minutes k8s_kms-plugin_kms-plugin-moc-lll6bm1plaa_kube-system_d4544572743e024431874e6ba7a9203b_1
   

4. Terakhir, hidupkan ulang kontainer dengan menjalankan perintah berikut:

   $ ssh -i (Get-AksHciConfig).Moc.sshPrivateKey clouduser@<ip> "sudo docker container kill <Container ID>"
   

Pada penginstalan AKS di Azure Stack HCI dengan ekstensi Windows Admin Center versi 1.82.0, kluster manajemen disiapkan menggunakan PowerShell, dan percobaan dilakukan untuk menyebarkan kluster beban kerja menggunakan Windows Admin Center. Salah satu mesin telah menginstal modul PowerShell versi 1.0.2, dan mesin lain telah menginstal modul PowerShell 1.1.3. Upaya untuk menyebarkan kluster beban kerja gagal dengan kesalahan "Parameter tidak dapat ditemukan yang cocok dengan nama parameter 'nodePoolName'." Kesalahan ini mungkin terjadi karena versi tidak cocok. Dimulai dengan PowerShell versi 1.1.0, parameter -nodePoolName <String> telah ditambahkan ke cmdlet -nodePoolName <String>, dan menurut desain, parameter ini sekarang wajib saat menggunakan ekstensi Windows Admin Center versi 1.82.0.

Untuk mengatasi masalah ini, lakukan salah satu hal berikut ini:

• Gunakan PowerShell untuk memperbarui kluster beban kerja secara manual ke versi 1.1.0 atau yang lebih baru.
• Gunakan Windows Admin Center untuk memperbarui kluster ke versi 1.1.0 atau ke versi PowerShell terbaru.

Masalah ini tidak terjadi jika kluster manajemen disebarkan menggunakan Windows Admin Center, karena sudah menginstal modul PowerShell terbaru.

Saat Anda menyebarkan AKS di Azure Stack HCI, lalu menjalankan kubectl get pods, pod dalam simpul yang sama terjebak dalam status Mengakhiri . Komputer menolak koneksi SSH karena simpul kemungkinan mengalami permintaan memori yang tinggi. Masalah ini terjadi karena node Windows terlalu banyak diprovisikan, dan tidak ada cadangan untuk komponen inti.

Untuk menghindari situasi ini, tambahkan batas sumber daya dan permintaan sumber daya untuk CPU dan memori ke spesifikasi pod untuk memastikan bahwa node tidak diprovisikan secara berlebihan. Node Windows tidak mendukung pengeluaran berdasarkan batas sumber daya, jadi Anda harus memperkirakan berapa banyak kontainer yang akan digunakan lalu memastikan node memiliki jumlah CPU dan memori yang cukup. Anda dapat menemukan informasi lebih lanjut dalam persyaratan sistem.

Penskalaan otomatis kluster dapat gagal ketika Anda menggunakan kebijakan Azure berikut pada kluster manajemen host AKS Anda: "Kluster Kubernetes tidak boleh menggunakan namespace default." Ini terjadi karena kebijakan, ketika diterapkan pada kluster manajemen host AKS, memblokir pembuatan profil autoscaler di namespace default. Untuk memperbaiki masalah ini, pilih salah satu opsi berikut:

• Hapus instalan ekstensi Azure Policy pada kluster manajemen host AKS. Pelajari selengkapnya tentang menghapus instalan ekstensi Azure Policy di sini.
• Ubah cakupan kebijakan Azure untuk mengecualikan kluster manajemen host AKS. Pelajari selengkapnya tentang cakupan Azure Policy di sini.
• Atur mode penegakan kebijakan ke "Dinonaktifkan" untuk kluster manajemen host AKS. Pelajari selengkapnya tentang mode penegakan di sini.

Ini adalah masalah yang sudah diketahui dengan Pembaruan Juli AKS di Azure Stack HCI (versi 1.0.2.10723). Kesalahan terjadi karena waktu layanan CloudAgent habis selama distribusi mesin virtual di beberapa volume bersama kluster dalam sistem.

Untuk mengatasi masalah ini, Anda harus memutakhirkan ke rilis terbaru AKS di Azure Stack HCI.

Jika Anda menyediakan kluster AKS di Azure Stack HCI dengan nol simpul Linux atau Windows, saat Anda menjalankan Get-AksHciCluster, output akan menjadi string kosong atau nilai null.

Null adalah pengembalian yang diharapkan untuk nol simpul.

Saat Anda mematikan kluster manajemen atau beban kerja selama lebih dari empat hari, sertifikat akan kedaluwarsa dan kluster tidak dapat dijangkau. Sertifikat kedaluwarsa karena diputar setiap 3-4 hari untuk alasan keamanan.

Untuk menghidupkan ulang kluster, Anda perlu memperbaiki sertifikat secara manual sebelum dapat melakukan operasi kluster apa pun. Untuk memperbaiki sertifikat, jalankan perintah Repair-AksHciClusterCerts berikut:

Repair-AksHciClusterCerts -Name <cluster-name> -fixKubeletCredentials

Saat menskalakan kluster beban kerja, mesin virtual Linux serta Windows yang sesuai akan ditambahkan sebagai simpul pekerja, tetapi tidak dikonfigurasi sebagai mesin virtual yang sangat tersedia. Saat menjalankan perintah Get-ClusterGroup, mesin virtual Linux yang baru dibuat tidak akan dikonfigurasi sebagai Grup Kluster.

Ini adalah masalah yang sudah diketahui. Setelah boot ulang, kemampuan untuk mengonfigurasi mesin virtual sebagai sangat tersedia terkadang hilang. Solusi saat ini adalah menghidupkan ulang wssdagent pada setiap node Azure Stack HCI. Ini hanya berfungsi untuk VM baru yang dihasilkan dengan membuat kumpulan simpul saat melakukan operasi peluasan skala atau saat membuat kluster Kubernetes baru setelah memulai ulang wssdagent pada simpul. Namun, Anda harus menambahkan mesin virtual yang telah ada secara manual ke kluster failover.

Saat Anda menurunkan skala kluster, sumber daya kluster ketersediaan tinggi berada dalam status gagal saat VM dihapus. Solusi untuk masalah ini adalah menghapus sumber daya yang gagal secara manual.

Kluster AKS yang disebarkan di Azure VM sebelumnya berfungsi dengan baik, tetapi setelah host AKS dimatikan selama beberapa hari, Kubectl perintah tidak berfungsi. Setelah menjalankan perintah Kubectl get nodes atau Kubectl get services, pesan kesalahan ini muncul: Error from server (InternalError): an error on the server ("") has prevented the request from succeeding.

Masalah ini terjadi karena host AKS dimatikan selama lebih dari empat hari, yang menyebabkan sertifikat kedaluwarsa. Sertifikat sering diputar dalam siklus empat hari. Jalankan Repair-AksHciClusterCerts untuk memperbaiki masalah kedaluwarsa sertifikat.

Dalam kluster beban kerja dengan alamat IP statis dan simpul Windows, semua pod dalam simpul (termasuk daemonset pod) terjebak dalam status ContainerCreating . Saat mencoba menyambungkan ke simpul tersebut menggunakan SSH, koneksi gagal dengan kesalahan Connection timed out .

Untuk mengatasi masalah ini, gunakan Manajer Hyper-V atau Manajer Kluster Failover untuk menonaktifkan VM simpul tersebut. Setelah 5 hingga 10 menit, simpul seharusnya dibuat ulang, dengan semua pod berjalan.

Ketika kubelet berada di bawah tekanan disk, kubelet mengumpulkan gambar kontainer yang tidak digunakan, yang mungkin mencakup gambar jeda, dan ketika ini terjadi, ContainerD tidak dapat menarik gambar.

Untuk mengatasi masalah ini, jalankan langkah-langkah berikut:

1. Sambungkan ke simpul yang terpengaruh menggunakan SSH, dan jalankan perintah berikut:

sudo su

2. Untuk menarik gambar, jalankan perintah berikut:

crictl pull ecpacr.azurecr.io/kube-proxy:<Kubernetes version>

Langkah berikutnya

• Rangkuman Pemecahan Masalah
• Masalah dan kesalahan jaringan
• masalah penyimpanan yang diketahui