AKS Arc'ın yükseltilmesiyle ilgili sorunları çözme

PowerShell'in eski sürümleri kaldırılmaz.

Bu sorunu geçici olarak çözmek için bu betiği çalıştırarak eski PowerShell sürümlerini kaldırabilirsiniz.

Hedef kümeyi yükselttikten veya ölçeklendirdikten sonra sertifika yenileme podu artık kilitlenme döngüsü durumundadır. Yolundan /etc/Kubernetes/pkibir sertifika dövme yaml dosyası bekliyor. Yapılandırma dosyası denetim düzlemi düğümü VM'lerinde bulunur ancak çalışan düğümü VM'lerinde yoktur.

Bu sorunu çözmek için denetim düzlemi düğümündeki sertifika dövme dosyasını çalışan düğümlerinin her birine el ile kopyalayın.

1. Dosyayı denetim düzlemi VM'sinden konak makinenizin geçerli dizinine kopyalayın.

   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. Dosyayı konak makinesinden çalışan düğümü VM'sine kopyalayın.

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

3. Bu dosyadaki sahip ve grup bilgilerini kök olarak ayarlamadıysa kök olarak ayarlayın.

   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. Çalışan düğümlerinizin her biri için 2. ve 3. adımları yineleyin.

Bir küme 60 günden uzun bir süredir yükseltilmediğinde, belirteç süresinin dolması nedeniyle düğüm aracısı yeniden başlatma sırasında başlatılamaz. Bu hata, aracıların başlangıç aşamasında olmasını neden olur. Cloudagent'a sürekli katılma girişimleri, konak üzerindeki bağlantı noktalarının kaynağını tüketebilir. Aşağıdaki komutun durumu Başlatılıyor şeklindedir.

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

Beklenen davranış: Düğüm aracısı, bulut aracısına sürekli katılmayı deneyerek bağlantı noktalarını tüketen başlangıç aşamasında olmalıdır.

Sorunu çözmek için wssdagent'ın çalışmasını durdurun. Hizmet başlangıç aşamasında olduğundan, hizmeti durdurmanızı engelleyebilir. Bu durumda, hizmeti durdurmayı denemeden önce işlemi sonlandırın.

1. wssdagent'ın başlangıç aşamasında olduğunu onaylayın.

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

2. İşlemi sonlandırın.

   kill -Name wssdagent -Force
   

3. Hizmeti durdurun.

   Stop-Service wssdagent -Force
   

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. Bu sorunu olan Azure Yerel kümesinin her düğümünde 1, 2 ve 3. adımları yineleyin.

2. wssdagent'ın çalışmadığını onayladıktan sonra, çalışmıyorsa cloudagent'ı başlatın.

Start-ClusterGroup -Name (Get-MocConfig).clusterRoleName

1. Cloudagent'ın çalışır durumda olduğunu onaylayın.

   Get-ClusterGroup -Name (Get-MocConfig).clusterRoleName
   

2. wssdagent'ı düzeltmek için aşağıdaki komutu çalıştırın:

   Repair-Moc
   

3. Bu komut tamamlandıktan sonra wssdagent çalışır durumda olmalıdır.

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

Azure Yerel'de AKS, Mayıs sürümünden Haziran sürümüne yükseltilemezse, Azure Yerel'de AKS'nin Mayıs sürümüne geri dönüp çalışmaya devam etmesi beklenebilir. Ancak MOC aracılarını durdurulmuş durumda bırakır ve aracıyı el ile başlatma girişimleri bunları etkinleştirmez.

Yeniden oluşturma adımları

1. AKS-HCI PowerShell modülünün 1.1.36 sürümünü yükleyin.
2. Azure Yerel'de AKS'yi yükseltin. Yükseltme başarısız olursa Azure Yerel'de AKS Mayıs'a geri döner, ancak MOC aracıları devre dışı kalır.

Beklenen davranış

Azure Yerel'de AKS yükseltmesi başarısız olursa, Azure Yerel'de AKS'nin önceki sürüme geri dönmeleri ve herhangi bir sorun yaşamadan çalışmaya devam etmesi beklenmiştir.

Belirtiler

Aks-Hci sürümü ile MOC sürümü arasındaki uyuşmazlık

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

Get-MocVersion ile wssdcloudagent.exe sürümü arasındaki uyuşmazlık

Get-MocVersion Haziran derlemesinin yüklü olduğunu, wssdcloudagent.exe sürümü ise Mayıs derlemesinin yüklü olduğunu gösterir.

MOC aracı hizmetleri görüntü yolunda dağıtım kimliği parametresi var

Bulut aracısının görüntü yolunu göstermek için aşağıdaki komutu çalıştırın:

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

Örnek çıkış

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

Düğüm aracısının görüntü yolunu göstermek için aşağıdaki komutu kullanın: "HKLM\System\CurrentControlSet\Services\wssdagent" reg sorgusu

Örnek çıkış

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

Sorunu azaltmak için aşağıdaki PowerShell cmdlet'lerini çalıştırın:

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'

Yükseltme sırasında, çalışan düğümlerinize eklediğiniz tüm özel renk tonlarını, rolleri ve etiketleri kaybedebilirsiniz. AKS yönetilen bir hizmet olduğundan, sağlanan PowerShell cmdlet'leri veya Windows Yönetim Merkezi dışında gerçekleştirildiğinde özel renk tonları, etiketler ve roller eklenmesi desteklenmez.

Bu sorunu geçici olarak çözmek için New-AksHciNodePool cmdlet'ini çalıştırarak çalışan düğümleriniz için taint'lerle doğru bir düğüm havuzu oluşturun.

Bir yönetim kümesi oluşturduysanız ancak ilk 60 gün içinde bir iş yükü kümesi dağıtmadıysanız, artık ilke dışı olduğundan bu kümeyi oluşturmanız engellenir. Bu durumda, Update-AksHci'yi çalıştırdığınızda güncelleştirme işlemi 'AksHci Faturalama İşleci' dağıtımının hazır olması bekleniyor hatasıyla engellenir. Sync-AksHciBilling çalıştırırsanız, başarılı bir çıkış döndürür. Ancak Get-AksHciBillingStatus çalıştırırsanız bağlantı durumu OutofPolicy olur.

60 gündür bir iş yükü kümesi dağıtmadıysanız faturalama ilke dışı bırakılır.

Bu sorunu düzeltmenin tek yolu temiz bir yüklemeyle yeniden dağıtmaktır.

Azure Yerel düğümleri birbiri ardına yeniden başlatılırsa, bazı sanal makineler bunlara bağlı vNIC'leri kaybeder. Bu vNIC kaybı VM'lerin ağ bağlantısını kaybetmesine ve kümenin kötü bir duruma düşmesine neden olur.

Yeniden Oluşturmak için

1. Bir Azure Yerel düğümünü yeniden başlatın.
2. Düğümün yeniden başlatmayı tamamlanmasını bekleyin. Düğümün yük devretme kümesinde işaretlenmesi Up gerekir.
3. Diğer düğümleri yeniden başlatın.
4. Tekrarlayın.

Beklenen davranış Küme durumunun iyi durumda olması gerekir. Tüm VM'lerde NIC'ler eklenmelidir.

Sorunu çözmek için vm'ye vNIC eklemek için MOC komutlarını kullanın.

1. VM için vNIC adını alın.

(Get-MocVirtualMachine -group <group> -name <vmname>).virtualmachineproperties.networkprofile.networkinterfaces

veya

mocctl.exe compute vm get --name <vmname> --group <group>

2. vNIC'yi VM'ye bağlayın.

Connect-MocNetworkInterface -name <vnicname> -group <group> -virtualMachineName <vmname>

veya

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

3. vNIC connect komutu başarısız olursa bağlantıyı kesmeyi ve yeniden bağlanmayı deneyin. vNIC bağlantısını kesme komutu aşağıdadır.

Disconnect-MocNetworkInterface -name <vnicname> -group <group> -virtualMachineName <vmname>

veya

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

Podlar, statik podların hazır bir koşula sahip olmasını beklerken takıldı.

Podları serbest bırakmak ve bu sorunu çözmek için kubelet'i yeniden başlatmanız gerekir. Statik podlarla NotReady düğümünü görüntülemek için aşağıdaki komutu çalıştırın:

kubectl get nodes -o wide

Hatalı düğüm hakkında daha fazla bilgi edinmek için aşağıdaki komutu çalıştırın:

kubectl describe node <IP of the node>

Aşağıdaki komutu çalıştırarak NotReady düğümünde oturum açmak için SSH kullanın:

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

Ardından kubelet'i yeniden başlatmak için aşağıdaki komutu çalıştırın:

/etc/.../kubelet restart

Windows Yönetim Merkezi'nde yükseltme çalıştırılırken aşağıdaki hata oluştu:

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.

Bu hata iletisi genellikle Azure Yerel'de AKS, ara sunucusunun yapılandırıldığı bir ortama dağıtıldığında oluşur. Şu anda, Windows Yönetim Merkezi'nin bir ara sunucu ortamına modül yükleme desteği yoktur.

Bu hatayı çözmek için proxy PowerShell komutunu kullanarak Azure Yerel'de AKS'yi ayarlayın.

OPA GateKeeper gibi bir Açık İlke Aracısı (OPA) ile Kubernetes kümelerini yükseltirken işlem kilitlenebilir ve tamamlanamayabilir. Bu sorun, ilke aracısı özel kayıt defterlerinden kapsayıcı görüntülerinin çekilmesini engelleyecek şekilde yapılandırıldığından oluşabilir.

Bu sorunu çözmek için, OPA ile dağıtılan kümeleri yükseltiyorsanız, ilkelerinizin Azure Container Registry'den görüntü çekmeye izin verin. Azure Yerel yükseltmesinde AKS için ilkenizin listesine şu uç noktayı eklemeniz gerekir: ecpacr.azurecr.io.

Azure Yerel dağıtımında AKS ile bir konakta işletim sistemi güncelleştirmesi çalıştırmak, dağıtımın hatalı duruma girmesine ve ikinci gün işlemlerinin başarısız olmasına neden olabilir. MOC NodeAgent Services güncelleştirilmiş konaklarda başlatılamıyor olabilir. Düğümlere yapılan tüm MOC çağrıları başarısız olur.

Yeniden oluşturmak için: Bir kümeyi HCI'den HCIv2 işletim sistemine var olan bir AKS dağıtımıyla güncelleştirdiğinizde, gibi New-AksHciCluster bir AKS işlemi başarısız olabilir. Hata iletisi, MOC düğümlerinin OutOfCapacity olduğunu belirtir. Örneğin:

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]

Bu sorunu çözmek için etkilenen düğümlerde wssdagent Moc NodeAgent Hizmetini başlatın. Bu işlem sorunu çözer ve dağıtımı yeniden iyi bir duruma getirir. Şu komutu çalıştırın:

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

Update-AksHciCluster çalıştırıldıktan sonra yükseltme işlemi durur.

Yükseltme yaptığınız önceki Kubernetes sürümünü çalıştıran, Silme özelliğine sahip PHASE bir makine olup olmadığını denetlemek için aşağıdaki komutu çalıştırın.

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

Silme ve VERSION önceki Kubernetes sürümüyle PHASE eşleşen bir makine varsa aşağıdaki adımlarla devam edin.

Bu sorunu gidermek için aşağıdaki bilgi parçalarına ihtiyacınız vardır:

1. İş yükü kümenizi yükselttiğiniz Kubernetes sürümü.
2. Takılan düğümün IP adresi.

Bu bilgileri bulmak için aşağıdaki cmdlet'i ve komutu çalıştırın. Varsayılan olarak, cmdlet Get-AksHciCredential kubeconfig öğesini öğesine ~/.kube/configyazar. çağrısı Get-AksHciCredentialyaparken iş yükü kümeniz kubeconfig için farklı bir konum belirtirseniz, bu konumu kubectl'ye başka bir bağımsız değişken olarak sağlamanız gerekir. Örneğin, kubectl get nodes -o wide --kubeconfig <path to workload cluster kubeconfig>.

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

Düzeltilmesi gereken düğümde gösterilmelidir STATUS Ready,SchedulingDisabled. Bu duruma sahip bir düğüm görürseniz aşağıdaki komutta INTERNAL-IP BU düğümün IP adresi değerini kullanın. Sürüm değeri olarak yükselttiğiniz Kubernetes sürümünü kullanın; bu, ile düğümdeki değerle ROLES control-plane,mastereşleşmelidirVERSION. Kubernetes sürümünün tam değerini eklediğinizden vemin olun; örneğin v1.22.6, .

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

Bu ssh komutu çalıştırıldıktan sonra, eski Kubernetes sürümüne sahip kalan düğümler silinmelidir ve yükseltme devam edecektir.

Azure Yerel dağıtımında AKS ile bir konakta işletim sistemi güncelleştirmesi çalıştırmak, dağıtımın hatalı bir duruma girmesine neden olabilir ve bu da yönetim kümesinin API sunucusuna ulaşılamaz hale gelir ve iki. gün işlemlerinde başarısız olur. Pod kube-vip , arabirime VIP yapılandırmasını uygulayamaz ve sonuç olarak VIP'ye ulaşılamaz.

Yeniden oluşturmak için: Bir kümeyi HCI'den HCIv2'ye var olan bir AKS HCI işletim sistemi dağıtımıyla güncelleştirin. Ardından gibi Get-AksHciClusteryönetim kümesine erişmeye çalışan komutları çalıştırmayı deneyin. Yönetim kümesine erişmeye çalışan tüm işlemler aşağıdaki gibi hatalarla başarısız olur:

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)]

Bu sorunu çözmek için: dağıtımı yeniden iyi duruma getirmek için kapsayıcıyı yeniden başlatın kube-vip .

1. kube-vip Kapsayıcı kimliğini alın:

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

Çıkış, kapsayıcı kimliği ilk değer 4a49a5158a5f8olacak şekilde şuna benzer görünmelidir. Örneğin:

4a49a5158a5f8       7751a28bb5ce1       28 minutes ago      Running             kube-vip                         1                   cf9681f921a55

1. Kapsayıcıyı yeniden başlatın:

ssh -i (Get-AksHciConfig).Moc.sshPrivateKey clouduser@<ip> "sudo crictl stop <Container ID>"

Update-AksHci PowerShell cmdlet'i çalıştırılırken bu durum iletisi görüntülenir.

Sorunu çözmek için aşağıdaki kök nedenleri gözden geçirin:

• Birinci neden: AksHci Faturalama İşleci'nin güncelleştirildiği sırada, işleç kendisini hatalı bir şekilde ilke dışı olarak işaretledi. Bu sorunu çözmek için yeni bir PowerShell penceresi açın ve Sync-AksHciBilling komutunu çalıştırın. Faturalama işleminin sonraki 20-30 dakika içinde devam etmesi gerekir.

• İkinci neden: Yönetim kümesi VM'sinin belleği yetersiz olabilir; bu da API sunucusuna ulaşılamayabilir ve Get-AksHciCluster, faturalama ve güncelleştirme, zaman aşımı gibi tüm komutları yapar. Geçici bir çözüm olarak, Hyper-V'de yönetim kümesi VM'sini 32 GB olarak ayarlayın ve yeniden başlatın.

• Üçüncü neden: AksHci Faturalama İşleci depolama alanı dışında olabilir ve bunun nedeni Microsoft SQL yapılandırma ayarlarındaki bir hatadır. Depolama alanı olmaması yükseltmenin yanıt vermeyi durdurmasına neden olabilir. Bu sorunu geçici olarak çözmek için aşağıdaki adımları kullanarak faturalama podunu pvc el ile yeniden boyutlandırın.

  1. Pod ayarlarını düzenlemek için aşağıdaki komutu çalıştırın:

     kubectl edit pvc mssql-data-claim --kubeconfig (Get-AksHciConfig).Kva.kubeconfig -n azure-arc
     

  2. YaML dosyasıyla Birlikte Not Defteri veya başka bir düzenleyici açıldığında, depolama satırını 100Mi ile 5Gi arasını düzenleyin:

     spec:
       resources:
         requests:
           **storage: 5Gi**
     

  3. Aşağıdaki komutu kullanarak faturalama dağıtımının durumunu denetleyin:

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

Azure Yerel Şubat 2022 Güncelleştirmesi'ndeki AKS'den Nisan 2022 Güncelleştirmesi'ne kümeleri yükselttiğinizde, güncelleştirme süresiz bir süre için yükseltme sırasında takılmış olabilir. veya CrashLoopBackoff durumunda takılmış Terminating podlar olabilir.

AksHci CSI eklenti kaynaklarından bazılarının eksik olduğunu görebilirsiniz. Daemonset'ten csi-akshcicsi-node veya kullanılarak csi-akshcicsi-controller dağıtılan bu kaynaklar podları.

Şubat 2022 Güncelleştirmesi'ndeki AksHci CSI eklentisi, yükseltme sırasında eklentinin kaynaklarını bazen yanıt vermeyen bir durumda bırakabilen CSI sürücü belirtiminde bir değişiklik içeriyordu. Sabit bir alan olmasına rağmen CSI sürücüsünün .spec.fsGroupPolicy değeri yeni bir değere ayarlanmıştır. Alan sabit olduğundan, sürücü belirtimi güncelleştirilmez. Bunun bir sonucu, diğer AksHci CSI eklenti kaynaklarının tam olarak uzlaştırılmamasıdır. Tüm CSI kaynakları yeniden oluşturulur.

Sorunu el ile çözmek için CSI sürücüsü el ile silinebilir. Bunu kaldırdıktan sonra, bulut operatörü 10 dakika içinde AksHci CSI eklentisini mutabık tutar ve eksik eklenti kaynaklarının geri kalanıyla birlikte sürücüyü yeniden oluşturur.

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

Başarılı bir yükseltmeden sonra, Windows Admin Center güncelleştirme panosu hala önceki sürümü gösterir.

Bu sorunu düzeltmek için tarayıcıyı yenileyin.

Azure Local üzerinde AKS'nin 1.0.1.10628 Haziran sürümü, kümede fazla sayıda Kubernetes yapılandırma gizli dizisini oluşturur. Ek Kubernetes gizli dizilerini temizlemek için Haziran 1.0.1.10628 sürümünden Temmuz 1.0.2.10723 sürümüne yükseltme yolu geliştirildi. Ancak, yükseltme sırasında bazı durumlarda gizli diziler hala temizlenmedi ve bu nedenle yükseltme işlemi başarısız oldu.

Bu sorunla karşılaşırsanız aşağıdaki adımları çalıştırın:

1. Aşağıdaki betiği fix_leaked_secrets.ps1 adlı bir dosya olarak kaydedin:

   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. Ardından, kaydettiğiniz fix_secret_leak.ps1 dosyasını kullanarak aşağıdaki komutu çalıştırın:

      .\fix_secret_leak.ps1 -ClusterName (Get-AksHciConfig).Kva.KvaName -ManagementKubeConfigPath (Get-AksHciConfig).Kva.Kubeconfig
   

3. Son olarak, yükseltme işlemini yinelemek için aşağıdaki PowerShell komutunu kullanın:

      Update-AksHci
   

Sonraki adımlar

• Sorun Giderme seçenekleri
• Yükleme sorunları ve hataları
• Windows Yönetim Merkezi bilinen sorunlar

AKS Arc kullanırken sorunlarla karşılaşırsanız GitHub aracılığıyla hata oluşturabilirsiniz.