Mengatasi masalah saat memutakhirkan AKS Arc

Artikel ini menjelaskan masalah dan kesalahan yang diketahui yang mungkin Anda temui saat meningkatkan penyebaran Arc Azure Kubernetes Service (AKS) ke rilis terbaru. Anda juga dapat meninjau masalah umum dengan Windows Admin Center dan saat menginstal AKS di Azure Stack HCI.

Setelah peningkatan berhasil, versi PowerShell yang lebih lama tidak dihapus

Versi PowerShell yang lebih lama tidak dihapus.

Untuk mengatasi masalah ini, Anda dapat menjalankan skrip ini untuk menghapus instalasi versi PowerShell yang lebih lama.

Pod perpanjangan sertifikat dalam status perulangan crash

Setelah meningkatkan atau meningkatkan skala kluster target, pod perpanjangan sertifikat sekarang dalam status perulangan crash. Diperlukan file yaml tato sertifikat dari jalur /etc/Kubernetes/pki. File konfigurasi ada di VM simpul sarana kontrol tetapi tidak pada VM simpul pekerja.

Catatan

Masalah ini diperbaiki setelah rilis April 2022.

Untuk mengatasi masalah ini, salin file tato sertifikasi secara manual dari simpul sarana kontrol ke setiap simpul pekerja.

  1. Salin file dari VM sarana kontrol 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 works)
    scp -i (get-mocconfig).sshprivatekey clouduser@<comtrol-plane-vm-ip>:~/cert*.yaml .\
    
  2. Salin file dari mesin host ke VM node pekerja.

    scp -i (get-mocconfig).sshprivatekey .\cert-tattoo-kubelet.yaml clouduser@<workernode-vm-ip>:~/cert-tattoo-kubelet.yaml
    
  3. Tetapkan informasi pemilik dan grup pada file ini kembali ke root jika belum ditetapkan ke root.

    ssh clouduser@<workernode-vm-ip> -i (get-mocconfig).sshprivatekey
    sudo cp ~/cert-tattoo-kubelet.yaml /etc/kubernetes/pki/cert-tattoo-kubelet.yaml (copies the cert file to correct location)
    sudo chown root cert-tattoo-kubelet.yaml
    sudo chgrp root cert-tattoo-kubelet.yaml
    
  4. Ulangi langkah 2 dan 3 untuk setiap simpul pekerja Anda.

Port bocor nodeagent saat tidak dapat bergabung dengan cloudagent karena token kedaluwarsa saat kluster tidak ditingkatkan selama lebih dari 60 hari

Ketika kluster belum ditingkatkan selama lebih dari 60 hari, agen simpul gagal dimulai selama agen simpul dimulai ulang karena kedaluwarsa token. Kegagalan ini menyebabkan agen berada dalam fase awal. Upaya berkelanjutan untuk bergabung dengan cloudagent dapat menghabiskan pasokan port pada host. Status untuk perintah berikut adalah Mulai.

Get-Service wssdagent | Select-Object -Property Name, Status

Perilaku yang diharapkan: Agen simpul harus berada dalam fase awal, yang terus-menerus mencoba bergabung dengan agen cloud, menghabiskan port.

Untuk mengatasi masalah ini, hentikan wssdagent agar tidak berjalan. Karena layanan berada dalam fase awal, hal ini dapat mencegah Anda menghentikan layanan. Jika demikian, matikan proses sebelum mencoba menghentikan layanan.

  1. Konfirmasikan wssdagent sedang di fase awal.

    Get-Service wssdagent | Select-Object -Property Name, Status
    
  2. Hentikan prosesnya.

    kill -Name wssdagent -Force
    
  3. Hentikan layanan.

    Stop-Service wssdagent -Force
    

Catatan

Bahkan setelah menghentikan layanan, proses wssdagent tampaknya dimulai dalam beberapa detik selama beberapa kali sebelum berhenti. Sebelum melanjutkan ke langkah berikutnya, pastikan perintah berikut mengembalikan kesalahan pada semua simpul.

Get-Process -Name wssdagent
PS C:\WINDOWs\system32 Get-process -Name wssdagent 
Get-process : Cannot find a process with the name "wssdaqent". Verify the process name and call the cmdlet again.
At line: 1 char: 1 
+ Get-process -Name wssdagent
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + Categorylnfo          : ObjectNotFound: (wssdagent:String) [Get-Process], ProcessCommandException 
    + FullyQua1ifiedErrorId : NoProcess FoundForGivenName , Microsoft.PowerShell.Commands.Getprocesscommand
  1. Ulangi langkah 1, 2, dan 3 di setiap simpul kluster HCI yang memiliki masalah ini.

  2. Setelah mengonfirmasi wssdagent tidak berjalan, mulai cloudagent jika tidak berjalan.

Start-ClusterGroup -Name (Get-MocConfig).clusterRoleName
  1. Konfirmasikan cloudagent aktif dan berjalan.

    Get-ClusterGroup -Name (Get-MocConfig).clusterRoleName
    
  2. Jalankan perintah berikut untuk memperbaiki wssdagent:

    Repair-Moc
    
  3. Setelah perintah ini selesai, wssdagent harus dalam status berjalan.

    Get-Service wssdagent | Select-Object -Property Name, Status
    

Agen MOC tidak dimulai setelah kegagalan peningkatan

Ketika AKS-HCI gagal meningkatkan dari rilis Mei ke rilis Juni, harapannya adalah bahwa AKS-HCI harus kembali ke rilis Mei dan terus berfungsi. Tetapi meninggalkan agen MOC dalam keadaan berhenti, dan upaya manual untuk memulai agen tidak mengaktifkannya.

Catatan

Masalah ini hanya relevan saat meningkatkan dari rilis Mei ke rilis Juni.

Langkah-langkah untuk mereproduksi masalah

  1. Instal modul AKS-HCI PowerShell versi 1.1.36.
  2. Tingkatkan AKS-HCI. Jika peningkatan gagal, AKS-HCI kembali ke Mei, tetapi agen MOC tidak berfungsi.

Perilaku yang diharapkan

Jika peningkatan Aks-Hci gagal, harapannya adalah bahwa AksHci kembali ke rilis sebelumnya dan terus berfungsi tanpa masalah.

Gejala

Ketidakcocokan antara versi Aks-Hci dan versi MOC

  • Get-AksHciVersion: 1.0.10.10513
  • Get-MocVersion: 1.0.11.10707

Ketidakcocokan antara versi Get-MocVersion dan wssdcloudagent.exe

Get-MocVersion menunjukkan bahwa build Juni diinstal sementara versi wssdcloudagent.exe menunjukkan bahwa build Mei diinstal.

Jalur gambar layanan agen MOC memiliki parameter ID penyebaran

Jalankan perintah berikut untuk memperlihatkan jalur gambar untuk agen cloud:

reg query "HKLM\System\CurrentControlSet\Services\wssdcloudagent"

Contoh output

"C:\Program Files\AksHci\wssdcloudagent.exe" --service --basedir "base dir" --cloudagentfqdn "cloudagent fqdn" --dotfolderpath "dot folder path" --objectdatastore "data store" --clusterresourcename "cluster name" --certificatevalidityfactor 1 --deploymentid "deployment id"

Gunakan perintah berikut untuk memperlihatkan jalur gambar untuk agen simpul: kueri reg "HKLM\System\CurrentControlSet\Services\wssdagent"

Contoh output

"C:\Program Files\AksHci\wssdagent.exe" --service --basedir "base dir" --cloudloginfile "cloud login file path" --dotfolderpath "dotfolder path" --nodeagentfqdn "node fqdn" --objectdatastore "object data store" --wssdproviderspec "provider spec" --deploymentid "deployment id"

Untuk mengurangi masalah, jalankan cmdlet PowerShell berikut:

Set-ItemProperty -Path "HKLM:\System\CurrentControlSet\Services\wssdcloudagent" -Name ImagePath -Value 'above cloud agent image path without the deployment id'
Set-ItemProperty -Path "HKLM:\System\CurrentControlSet\Services\wssdagent" -Name ImagePath -Value 'above node agent image path without the deployment id'

Selama peningkatan, taint, peran, dan label node kustom hilang

Saat meningkatkan, Anda mungkin kehilangan semua taint, peran, dan label kustom yang Anda tambahkan ke node pekerja Anda. Karena AKS adalah layanan terkelola, menambahkan taint, label, dan peran kustom saat dilakukan di luar cmdlet PowerShell yang disediakan atau Windows Admin Center tidak didukung.

Untuk mengatasi masalah ini, jalankan cmdlet New-AksHciNodePool untuk membuat kumpulan node dengan taint untuk node pekerja Anda dengan benar.

AKS Arc keluar dari kebijakan jika kluster beban kerja belum dibuat dalam 60 hari

Jika Anda membuat kluster manajemen tetapi belum menyebarkan kluster beban kerja dalam 60 hari pertama, Anda akan diblokir untuk membuatnya, karena sekarang di luar kebijakan. Dalam situasi ini, saat Anda menjalankan Update-AksHci, proses pembaruan diblokir dengan kesalahan Menunggu penyebaran 'AksHci Billing Operator' siap. Jika Anda menjalankan Sync-AksHciBilling, itu mengembalikan output yang berhasil. Namun, jika Anda menjalankan Get-AksHciBillingStatus, status koneksinya adalah OutofPolicy.

Jika Anda belum menyebarkan kluster beban kerja dalam 60 hari, tagihan akan dianggap keluar dari kebijakan.

Satu-satunya cara untuk memperbaiki masalah ini adalah melakukan penyebaran ulang dengan penginstalan yang bersih.

vNIC hilang setelah reboot mesin

Catatan

Masalah ini diperbaiki dalam rilis Mei 2022 dan yang lebih baru.

Jika simpul Azure Stack HCI di-boot ulang satu demi satu, beberapa komputer virtual kehilangan vNIC yang melekat padanya. Hilangnya vNIC ini menyebabkan VM kehilangan konektivitas jaringan, dan kluster jatuh ke dalam keadaan buruk.

Untuk Mereprodusi

  1. Reboot satu simpul Azure Stack HCI.
  2. Tunggu hingga simpul menyelesaikan reboot. Simpul perlu ditandai Up di kluster failover.
  3. Reboot simpul lainnya.
  4. Ulangi.

Perilaku yang diharapkan Status kluster harus sehat. Semua VM harus memiliki NIC yang melekat padanya.

Untuk mengatasi masalah, gunakan perintah MOC untuk menambahkan vNIC ke VM.

  1. Dapatkan nama vNIC untuk VM.
(Get-MocVirtualMachine -group <group> -name <vmname>).virtualmachineproperties.networkprofile.networkinterfaces

atau

mocctl.exe compute vm get --name <vmname> --group <group>
  1. Sambungkan vNIC ke VM.
Connect-MocNetworkInterface -name <vnicname> -group <group> -virtualMachineName <vmname>

atau

mocctl.exe compute vm nic add --name <vnicname> --vm-name <vmname> --group <group>
  1. Jika perintah koneksi vNIC gagal, coba putuskan sambungan dan sambungkan lagi. Berikut adalah perintah untuk pemutusan sambungan vNIC.
Disconnect-MocNetworkInterface -name <vnicname> -group <group> -virtualMachineName <vmname>

atau

mocctl.exe compute vm nic remove --name <vnicname> --vm-name <vmname> --group <group>

Saat meningkatkan penyebaran, beberapa pod mungkin macet di 'menunggu pod statis memiliki kondisi siap'

Pod terjebak saat menunggu pod statis memiliki kondisi siap.

Untuk merilis pod dan menyelesaikan masalah ini, Anda harus memulai ulang kubelet. Untuk melihat node NotReady dengan pod statik, jalankan perintah berikut:

kubectl get nodes -o wide

Untuk mendapatkan informasi selengkapnya tentang node yang rusak, jalankan perintah berikut:

kubectl describe node <IP of the node>

Gunakan SSH untuk masuk ke node NotReady dengan menjalankan perintah berikut:

ssh -i <path of the private key file> administrator@<IP of the node>

Kemudian, untuk memulai ulang kubelet, jalankan perintah berikut:

/etc/.../kubelet restart

Menjalankan peningkatan menghasilkan kesalahan: 'Terjadi kesalahan saat mengambil informasi peningkatan platform'

Saat menjalankan peningkatan di Pusat Admin Windows, terjadi kesalahan berikut:

Error occurred while fetching platform upgrade information. RemoteException: No match was found for the specified search criteria and module name 'AksHci'. Try Get-PSRepository to see all available registered module repositories.

Pesan kesalahan ini umumnya terjadi ketika AKS di Azure Stack HCI disebarkan di lingkungan dengan proksi yang dikonfigurasi. Saat ini, Windows Admin Center tidak memiliki dukungan untuk menginstal modul di lingkungan proksi.

Untuk mengatasi kesalahan ini, siapkan AKS di Azure Stack HCI menggunakan perintah PowerShell proksi.

Saat meningkatkan kluster Kubernetes dengan Open Policy Agent, proses peningkatan macet

Saat meningkatkan kluster Kubernetes dengan Open Policy Agent (OPA), seperti OPA GateKeeper, prosesnya mungkin macet dan tidak dapat diselesaikan. Masalah ini dapat terjadi karena agen kebijakan dikonfigurasi untuk mencegah menarik citra kontainer dari registri privat.

Untuk mengatasi masalah ini, jika Anda meningkatkan kluster yang disebarkan dengan OPA, pastikan kebijakan Anda memungkinkan untuk menarik citra dari Azure Container Registry. Untuk peningkatan AKS di Azure Stack HCI, Anda harus menambahkan titik akhir berikut dalam daftar kebijakan Anda: ecpacr.azurecr.io.

Pembaruan host OS HCI ke HCIv2 mengganggu instalasi AKS di Azure Stack HCI: OutOfCapacity

Menjalankan pembaruan OS pada host dengan penyebaran AKS di Azure Stack HCI dapat menyebabkan penyebaran memasuki status buruk dan gagal operasi hari kedua. MOC NodeAgent Services mungkin gagal memulai pada host yang diperbarui. Semua panggilan MOC ke simpul gagal.

Catatan

Masalah ini hanya terjadi sesekali.

Untuk mereproduksi: Saat Anda memperbarui kluster dengan penyebaran AKS yang ada dari HCI ke HCIv2, operasi AKS seperti New-AksHciCluster mungkin gagal. Pesan kesalahan menyatakan bahwa node MOC adalah OutOfCapacity. Contohnya:

System.Collections.Hashtable.generic_non_zero1 [Error: failed to create nic test-load-balancer-whceb-nic for machinetest-load-balancer-whceb: unable to create VM network interface: failed to create network interface test-load-balancer-whceb-nic in resource group clustergroup-test: rpc error: code = Unknown desc = Location 'MocLocation' doesn't expose any nodes to create VNIC 'test-load-balancer-whceb-nic' on: OutOfCapacity]

Untuk mengatasi masalah ini, mulai Layanan NodeAgent Moc wssdagent pada node yang terdampak. Tindakan ini akan menyelesaikan masalah, dan mengembalikan penyebaran ke keadaan yang baik. Jalankan perintah berikut:

Get-ClusterNode -ErrorAction Stop | ForEach-Object { Invoke-Command -ComputerName $_ -ScriptBlock { Start-Service wssdagent -WarningAction:SilentlyContinue } }

Peningkatan kluster target macet dengan satu atau beberapa simpul dalam versi Kubernetes lama

Setelah menjalankan Update-AksHciCluster, proses peningkatan akan berjalan.

Jalankan perintah berikut untuk memeriksa apakah ada komputer dengan PHASE Menghapus yang menjalankan versi Kubernetes sebelumnya yang Anda tingkatkan.

kubectl get machines -o wide --kubeconfig (Get-KvaConfig).kubeconfig

Jika ada komputer dengan PHASE Menghapus dan VERSION mencocokkan versi Kubernetes sebelumnya, lanjutkan dengan langkah-langkah berikut.

Untuk mengatasi masalah ini, Anda memerlukan informasi berikut:

  1. Versi Kubernetes tempat Anda meningkatkan kluster beban kerja.
  2. Alamat IP simpul yang macet.

Untuk menemukan informasi ini, jalankan cmdlet dan perintah berikut. Secara default, cmdlet Get-AksHciCredential menulis kubeconfig ke ~/.kube/config. Jika Anda menentukan lokasi yang berbeda untuk kubeconfig kluster beban kerja saat memanggil Get-AksHciCredential, Anda harus menyediakan lokasi tersebut untuk kubectl sebagai argumen lain. Contohnya,kubectl get nodes -o wide --kubeconfig <path to workload cluster kubeconfig>.

Get-AksHciCredential -name <workload cluster name>
kubectl get nodes -o wide

Simpul yang perlu diperbaiki harus menampilkan STATUSReady,SchedulingDisabled. Jika Anda melihat simpul dengan status ini, gunakan INTERNAL-IP dari simpul ini sebagai nilai alamat IP dalam perintah berikut di bawah ini. Gunakan versi Kubernetes yang Anda tingkatkan sebagai nilai versi; ini harus cocok dengan VERSION nilai dari simpul dengan ROLEScontrol-plane,master. Pastikan untuk menyertakan nilai lengkap untuk versi Kubernetes, termasuk v, misalnya v1.22.6.

ssh -i (Get-MocConfig).sshPrivateKey -o StrictHostKeyChecking=no  clouduser@<IP address> sudo crictl pull ecpacr.azurecr.io/kube-proxy:<Kubernetes version>

Setelah menjalankan perintah ssh ini, node yang tersisa dengan versi Kubernetes lama harus dihapus dan peningkatan akan dilanjutkan.

Pembaruan host OS HCI ke HCIv2 mengganggu instalasi AKS di Azure Stack HCI: Tidak dapat menjangkau kluster manajemen

Menjalankan pembaruan OS pada host dengan penyebaran AKS di Azure Stack HCI dapat menyebabkan penyebaran memasuki status buruk, yang membuat server API kluster manajemen tidak dapat dijangkau dan gagal operasi hari kedua. Pod kube-vip tidak dapat menerapkan konfigurasi VIP ke antarmuka, dan akibatnya VIP tidak dapat dijangkau.

Untuk mereproduksi: Perbarui kluster dengan penyebaran AKS HCI yang ada dari HCI ke HCIv2. Kemudian coba jalankan perintah yang mencoba menjangkau kluster manajemen seperti Get-AksHciCluster. Setiap operasi yang mencoba mencapai kluster manajemen gagal dengan kesalahan seperti:

PS C:\Users\wolfpack> Get-AksHciCluster
C:\Program Files\AksHci\kvactl.exe cluster list --kubeconfig="C:\ClusterStorage\Volume1\Msk8s\WorkingDir\1.0.8.10223\kubeconfig-mgmt" System.Collections.Hashtable.generic_non_zero 1 [Error: failed to connect to the cluster: action failed after 9
attempts: Get "https://10.193.237.5:6443/api?timeout=10s": net/http: request canceled while waiting for connection
(Client.Timeout exceeded while awaiting headers)]
At C:\Program Files\WindowsPowerShell\Modules\Kva\1.0.22\Common.psm1:2164 char:9
+         throw $errMessage
+         ~~~~~~~~~~~~~~~~~
    + CategoryInfo          : OperationStopped: (C:\Program File...iting headers)]:String) [], RuntimeException
    + FullyQualifiedErrorId : C:\Program Files\AksHci\kvactl.exe cluster list --kubeconfig="C:\ClusterStorage\Volume1\Msk8s\WorkingDir\1.0.8.10223\kubeconfig-mgmt" System.Collections.Hashtable.generic_non_zero 1 [Error: failed to connect to the cluster: action failed after 9 attempts: Get "https://10.193.237.5:6443/api?timeout=10s": net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)]

Untuk mengatasi masalah ini: mulai ulang kontainer kube-vip untuk mengembalikan penyebaran ke keadaan yang baik.

  1. Untuk mendapatkan ID kontainer kube-vip:
ssh -i (Get-AksHciConfig).Moc.sshPrivateKey clouduser@<ip> "sudo crictl ls | grep 'kube-vip'"

Output harus terlihat seperti ini, dengan ID kontainer menjadi nilai 4a49a5158a5f8 pertama. Contohnya:

4a49a5158a5f8       7751a28bb5ce1       28 minutes ago      Running             kube-vip                         1                   cf9681f921a55
  1. Mulai ulang kontainer Mulai ulang:
ssh -i (Get-AksHciConfig).Moc.sshPrivateKey clouduser@<ip> "sudo crictl stop <Container ID>"

Saat menjalankan Update-AksHci, proses pembaruan macet di 'Menunggu penyebaran 'Operator Penagihan AksHci' siap'

Pesan status ini muncul saat menjalankan cmdlet Update-AksHci PowerShell.

Tinjau akar penyebab berikut untuk mengatasi masalah:

  • Alasan satu: Selama pembaruan Operator Penagihan AksHci, operator salah menandai dirinya sebagai di luar kebijakan. Untuk mengatasi masalah ini, buka jendela PowerShell baru dan jalankan Sync-AksHciBilling. Anda akan melihat operasi tagihan berlanjut dalam 20-30 menit ke depan.

  • Alasan dua: VM kluster manajemen mungkin kehabisan memori, yang menyebabkan server API tidak dapat dijangkau dan membuat semua perintah dari Get-AksHciCluster, penagihan, dan pembaruan, waktu habis. Sebagai solusinya, atur VM kluster manajemen ke 32 GB di Hyper-V, dan boot ulang.

  • Alasan ketiga: Operator Penagihan AksHci mungkin kehabisan ruang penyimpanan, yang disebabkan oleh bug di pengaturan konfigurasi Microsoft SQL. Kurangnya ruang penyimpanan dapat menyebabkan peningkatan berhenti merespons. Untuk mengatasi masalah ini, ubah ukuran pvc pod tagihan secara manual menggunakan langkah-langkah berikut.

    1. Jalankan perintah berikut untuk mengedit pengaturan pod:

      kubectl edit pvc mssql-data-claim --kubeconfig (Get-AksHciConfig).Kva.kubeconfig -n azure-arc
      
    2. Saat Notepad atau penyunting lain terbuka dengan file YAML, edit baris untuk penyimpanan dari 100Mi ke 5Gi:

      spec:
        resources:
          requests:
            **storage: 5Gi**
      
    3. Periksa status penyebaran tagihan menggunakan perintah berikut:

      kubectl get deployments/billing-manager-deployment --kubeconfig (Get-AksHciConfig).Kva.kubeconfig -n azure-arc
      

Saat meningkatkan AKS di Azure Stack HCI dari Pembaruan Februari 2022 ke Pembaruan April 2022, penyebaran CSI menghilang dan menyebabkan peningkatan ke stall

Saat Anda meningkatkan kluster dari AKS pada Pembaruan Azure Stack HCI Februari 2022 ke Pembaruan April 2022, pembaruan mungkin terjebak peningkatan untuk jangka waktu yang tidak terbatas. Mungkin ada pod yang terjebak dalam status Terminating atau CrashLoopBackoff .

Anda mungkin melihat bahwa beberapa sumber daya addon CSI AksHci hilang. Pod sumber daya ini disebarkan menggunakan csi-akshcicsi-controller atau dari csi-akshcicsi-node daemonset.

Addon CSI AksHci dalam Pembaruan Februari 2022 berisi perubahan pada spesifikasi driver CSI yang terkadang dapat meninggalkan sumber daya addon dalam keadaan tidak responsif selama peningkatan. Driver .spec.fsGroupPolicy CSI diatur ke nilai baru meskipun merupakan bidang yang tidak dapat diubah. Karena bidang tidak dapat diubah, spesifikasi driver tidak diperbarui. Konsekuensi dari ini adalah bahwa sumber daya addon CSI AksHci lainnya mungkin tidak sepenuhnya didamaikan. Semua sumber daya CSI akan dibuat ulang.

Untuk mengatasi masalah secara manual, driver CSI dapat dihapus secara manual. Setelah Anda menghapusnya, operator cloud merekonsiliasi addon CSI AksHci dalam 10 menit dan membuat ulang driver bersama dengan sumber daya addon yang hilang lainnya.

kubectl --kubeconfig $(Get-AksHciConfig).Kva.kubeconfig delete csidriver disk.csi.akshci.com`

Dasbor pembaruan Pusat Admin Windows tidak me-refresh setelah pembaruan berhasil

Setelah pemutakhiran berhasil, dasbor pembaruan Windows Admin Center masih menampilkan versi sebelumnya.

Nama bidang jaringan tidak konsisten di portal WAC.

Refresh browser untuk memperbaiki masalah ini.

Saat menggunakan PowerShell untuk meningkatkan, kelebihan jumlah rahasia konfigurasi Kubernetes dibuat pada kluster

Build 1.0.1.10628 pada Bulan Juni AKS di Azure Stack HCI menciptakan kelebihan jumlah rahasia konfigurasi Kubernetes di kluster. Jalur peningkatan dari rilis 1.0.1.10628 Juni ke rilis 1.0.2.10723 Juli ditingkatkan untuk membersihkan rahasia Kubernetes tambahan. Namun, dalam beberapa kasus selama peningkatan, rahasia masih belum dibersihkan, dan karena itu, proses peningkatan gagal.

Jika Anda mengalami masalah ini, jalankan langkah-langkah berikut:

  1. Simpan skrip di bawah ini sebagai file bernama fix_leaked_secrets.ps1:

    upgparam (
    [Parameter(Mandatory=$true)]
    [string] $ClusterName,
    [Parameter(Mandatory=$true)]
    [string] $ManagementKubeConfigPath
    )
    
    $ControlPlaneHostName = kubectl get nodes --kubeconfig $ManagementKubeConfigPath -o=jsonpath='{.items[0].metadata.name}'
    "Hostname is: $ControlPlaneHostName"
    
    $leakedSecretPath1 = "$ClusterName-template-secret-akshci-cc"
    $leakedSecretPath2 = "$ClusterName-moc-kms-plugin"
    $leakedSecretPath3 = "$ClusterName-kube-vip"
    $leakedSecretPath4 = "$ClusterName-template-secret-akshc"
    $leakedSecretPath5 = "$ClusterName-linux-template-secret-akshci-cc"
    $leakedSecretPath6 = "$ClusterName-windows-template-secret-akshci-cc"
    
    $leakedSecretNameList = New-Object -TypeName 'System.Collections.ArrayList';
    $leakedSecretNameList.Add($leakedSecretPath1) | Out-Null
    $leakedSecretNameList.Add($leakedSecretPath2) | Out-Null
    $leakedSecretNameList.Add($leakedSecretPath3) | Out-Null
    $leakedSecretNameList.Add($leakedSecretPath4) | Out-Null
    $leakedSecretNameList.Add($leakedSecretPath5) | Out-Null
    $leakedSecretNameList.Add($leakedSecretPath6) | Out-Null
    
    foreach ($leakedSecretName in $leakedSecretNameList)
    {
    "Deleting secrets with the prefix $leakedSecretName"
    $output = kubectl --kubeconfig $ManagementKubeConfigPath exec etcd-$ControlPlaneHostName -n kube-system -- sh -c "ETCDCTL_API=3 etcdctl --cacert /etc/kubernetes/pki/etcd/ca.crt --key /etc/kubernetes/pki/etcd/server.key --cert /etc/kubernetes/pki/etcd/server.crt del /registry/secrets/default/$leakedSecretName --prefix=true"
    "Deleted: $output"
    }
    
  2. Selanjutnya, jalankan perintah berikut menggunakan file fix_secret_leak.ps1 yang Anda simpan:

       .\fix_secret_leak.ps1 -ClusterName (Get-AksHciConfig).Kva.KvaName -ManagementKubeConfigPath (Get-AksHciConfig).Kva.Kubeconfig
    
  3. Terakhir, gunakan perintah PowerShell berikut untuk mengulangi proses peningkatan:

       Update-AksHci
    

Langkah berikutnya

Jika Anda terus mengalami masalah saat menggunakan AKS Arc, Anda dapat mengajukan bug melalui GitHub.