Az AKS Arc frissítésével kapcsolatos problémák megoldása

A PowerShell régebbi verziói nem törlődnek.

A probléma megoldásához futtassa ezt a szkriptet a régebbi PowerShell-verziók eltávolításához.

A célfürt frissítése vagy vertikális felskálázása után a tanúsítványmegújítási pod összeomlási ciklus állapotban van. Egy cert tattoo yaml fájlt vár az útról /etc/Kubernetes/pki. A konfigurációs fájl a vezérlősík-csomópont virtuális gépeiben található, a feldolgozó csomópont virtuális gépeinél azonban nem.

A probléma megoldásához másolja manuálisan a cert tattoo fájlt a vezérlősík csomópontjáról az egyes feldolgozó csomópontokra.

1. Másolja a fájlt a vezérlősík virtuális gépéről a gazdagép aktuális könyvtárába.

   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. Másolja a fájlt a gazdagépről a feldolgozó csomópont virtuális gépére.

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

3. Ha még nincs gyökérként beállítva, állítsa vissza a fájl tulajdonosi és csoportadatait gyökérre.

   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. Ismételje meg a 2. és a 3. lépést az egyes feldolgozó csomópontok esetében.

Ha egy fürt 60 napnál hosszabb ideig nem lett frissítve, a csomópontügynök a jogkivonat lejárata miatt nem indul el a csomópontügynök újraindítása során. Ez a hiba azt eredményezi, hogy az ügynökök a kezdeti fázisban lesznek. A cloudagenthez való folyamatos csatlakozási kísérletek kimeríthetik a gazdagép portjainak kínálatát. A következő parancs állapota Indítás.

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

Várt viselkedés: A csomópontügynöknek a kezdeti fázisban kell lennie, amely folyamatosan megpróbál csatlakozni a felhőügynökhöz, és kimeríti a portokat.

A probléma megoldásához állítsa le a wssdagent futtatását. Mivel a szolgáltatás a kezdeti fázisban van, megakadályozhatja a szolgáltatás leállítását. Ha igen, a szolgáltatás leállítása előtt tiltsa le a folyamatot.

1. Ellenőrizze, hogy a wssdagent a kezdő fázisban van-e.

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

2. Öld meg a folyamatot.

   kill -Name wssdagent -Force
   

3. Állítsa le a szolgáltatást.

   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. Ismételje meg az 1., a 2. és a 3. lépést a hci-fürt minden csomópontján, amelynél ez a probléma merül fel.

2. Miután meggyőződett arról, hogy a wssdagent nem fut, indítsa el a cloudagentet, ha nem fut.

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

1. Ellenőrizze, hogy a cloudagent működik-e.

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

2. Futtassa a következő parancsot a wssdagent javításához:

   Repair-Moc
   

3. A parancs befejeződése után a wssdagentnek futó állapotban kell lennie.

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

Ha az AKS-HCI nem frissít a májusi kiadásról a júniusi kiadásra, a várakozás az, hogy az AKS-HCI-nek vissza kell térnie a májusi kiadásra, és továbbra is működnie kell. Az MOC-ügynököket azonban leállítja, és a manuális próbálkozások nem aktiválják őket.

A reprodukálás lépései

1. Telepítse az AKS-HCI PowerShell-modul 1.1.36-os verzióját.
2. Frissítse az AKS-HCI-t. Ha a frissítés sikertelen, az AKS-HCI májusra esik vissza, de az MOC-ügynökök leállnak.

Várható viselkedés

Ha az Aks-Hci frissítése sikertelen, az elvárás az, hogy az AksHci visszatér az előző kiadásra, és probléma nélkül továbbra is működni fog.

Hibajelenségek

Eltérés az Aks-Hci és az MOC-verzió között

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

Eltérés a Get-MocVersion és wssdcloudagent.exe verzió között

Get-MocVersion azt jelzi, hogy a júniusi build telepítve van, míg a wssdcloudagent.exe verzió azt jelzi, hogy a májusi build telepítve van.

Az MOC-ügynökszolgáltatás lemezképének elérési útja üzembehelyezési azonosító paraméterrel rendelkezik

Futtassa a következő parancsot a felhőügynök képútvonalának megjelenítéséhez:

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

Példakimenet

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

A csomópontügynök képelérési útvonalának megjelenítéséhez használja a következő parancsot: "HKLM\System\CurrentControlSet\Services\wssdagent" reg lekérdezés

Példakimenet

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

A probléma megoldásához futtassa a következő PowerShell-parancsmagokat:

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'

Frissítéskor elveszítheti a feldolgozó csomópontokhoz hozzáadott összes egyéni fertőzést, szerepkört és címkét. Mivel az AKS egy felügyelt szolgáltatás, az egyéni hibák, címkék és szerepkörök hozzáadása a megadott PowerShell-parancsmagokon vagy a Windows Felügyeleti központban kívül végzett műveletek esetén nem támogatott.

A probléma megoldásához futtassa a New-AksHciNodePool parancsmagot, hogy helyesen hozzon létre egy csomópontkészletet a feldolgozó csomópontok számára.

Ha létrehozott egy felügyeleti fürtöt, de az első 60 napban nem helyezett üzembe számítási feladatfürtöt, akkor a rendszer letiltja a létrehozást, mert az már szabályzaton kívüli. Ebben az esetben az Update-AksHci futtatásakor a frissítési folyamat le lesz tiltva az "AksHci Számlázási operátor" üzembe helyezésre váró hibaüzenettel. A Sync-AksHciBilling futtatása sikeres kimenetet ad vissza. Ha azonban a Get-AksHciBillingStatus parancsot futtatja, a kapcsolat állapota OutofPolicy.

Ha 60 napja nem telepített számításifeladat-fürtöt, a számlázás ki fog merülni a szabályzatból.

A probléma megoldásának egyetlen módja a tiszta telepítés újbóli üzembe helyezése.

Ha az Azure Stack HCI-csomópontok egymás után újraindulnak, a virtuális gépek némelyike elveszíti a hozzájuk csatlakoztatott virtuális hálózati adaptereket. A virtuális hálózati adapterek elvesztése miatt a virtuális gépek elveszítik a hálózati kapcsolatot, és a fürt rossz állapotba kerül.

Reprodukálás

1. Indítsa újra az Egyik Azure Stack HCI-csomópontot.
2. Várja meg, amíg a csomópont befejezi az újraindítást. A csomópontot meg kell jelölni Up a feladatátvevő fürtben.
3. Indítsa újra a többi csomópontot.
4. Ismétel.

Várt viselkedés A fürt állapotának kifogástalannak kell lennie. Minden virtuális géphez hálózati adaptereket kell csatlakoztatni.

A probléma megoldásához az MOC-parancsokkal adja hozzá a virtuális hálózati adaptert a virtuális géphez.

1. Kérje le a virtuális gép virtuális hálózati adapterének nevét.

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

vagy

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

2. Csatlakoztassa a virtuális hálózati adaptert a virtuális géphez.

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

vagy

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

3. Ha a virtuális hálózati adapter csatlakoztatási parancsa sikertelen, próbálkozzon a kapcsolat bontásával, és kapcsolódjon újra. Az alábbi parancs a virtuális hálózati adapter leválasztását ismerteti.

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

vagy

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

A podok elakadtak, amikor arra vártak, hogy a statikus podok kész állapotba lépjenek.

A podok felszabadításához és a probléma megoldásához indítsa újra a kubeletet. A NotReady csomópont statikus podokkal való megtekintéséhez futtassa a következő parancsot:

kubectl get nodes -o wide

Ha további információt szeretne kapni a hibás csomópontról, futtassa a következő parancsot:

kubectl describe node <IP of the node>

Az SSH használatával jelentkezzen be a NotReady csomópontba az alábbi parancs futtatásával:

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

Ezután a kubelet újraindításához futtassa a következő parancsot:

/etc/.../kubelet restart

Frissítés futtatásakor a Windows Felügyeleti központban a következő hiba történt:

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.

Ez a hibaüzenet általában akkor jelenik meg, ha az Azure Stack HCI-n futó AKS egy proxyval konfigurált környezetben van üzembe helyezve. A Windows Felügyeleti központ jelenleg nem támogatja a modulok proxykörnyezetben való telepítését.

A hiba megoldásához állítsa be az AKS-t az Azure Stack HCI-ben a proxy PowerShell-paranccsal.

A Kubernetes-fürtök Open Policy Agent (OPA) használatával (például OPA GateKeeper) való frissítésekor előfordulhat, hogy a folyamat lefagy, és nem fejeződik be. Ez a probléma azért fordulhat elő, mert a szabályzatügynök úgy van konfigurálva, hogy megakadályozza a tárolólemezképek magánregisztrációs adatbázisokból való lekérését.

A probléma megoldásához, ha OPA-val telepített fürtöket frissít, győződjön meg arról, hogy a szabályzatok lehetővé teszik lemezképek lekérését az Azure Container Registryből. Az Azure Stack HCI-n futó AKS-frissítéshez a következő végpontot kell hozzáadnia a szabályzat listájához: ecpacr.azurecr.io.

Ha egy operációsrendszer-frissítést futtat egy gazdagépen egy AKS-sel az Azure Stack HCI-n, az azt okozhatja, hogy az üzembe helyezés rossz állapotba kerül, és a második nap sikertelen lesz. Előfordulhat, hogy az MOC NodeAgent-szolgáltatások nem indulnak el a frissített gazdagépeken. A csomópontokra irányuló MOC-hívások sikertelenek.

Reprodukálás: Ha egy fürtöt egy meglévő AKS-telepítéssel frissít HCI-ről HCIv2-re, egy AKS-művelet, például New-AksHciCluster sikertelen lehet. A hibaüzenet azt jelzi, hogy az MOC-csomópontok OutOfCapacity-csomópontok. Példa:

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]

A probléma megoldásához indítsa el a wssdagent Moc NodeAgent szolgáltatást az érintett csomópontokon. Ez megoldja a problémát, és jó állapotba hozza az üzembe helyezést. Futtassa az alábbi parancsot:

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

Az Update-AksHciCluster futtatása után a frissítési folyamat leáll.

Futtassa a következő parancsot annak ellenőrzéséhez, hogy van-e olyan gép, amely törléssel PHASE rendelkezik, amely az előző Kubernetes-verziót futtatja, amelyről frissít.

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

Ha van olyan gép, amely PHASE törli és VERSION megfelel az előző Kubernetes-verziónak, kövesse az alábbi lépéseket.

A probléma megoldásához a következő információkra van szüksége:

1. Kubernetes-verzió, amelyre frissíti a számítási feladatfürtöt.
2. A elakadt csomópont IP-címe.

Az információk megkereséséhez futtassa a következő parancsmagot és parancsot. Alapértelmezés szerint a parancsmag Get-AksHciCredential a kubeconfigot ~/.kube/configa következőbe írja: . Ha híváskor Get-AksHciCredentialmás helyet ad meg a számítási feladatfürt kubeconfigjához, ezt a helyet meg kell adnia egy másik argumentumként a kubectl számára. Például: kubectl get nodes -o wide --kubeconfig <path to workload cluster kubeconfig>.

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

A javítandó csomópontnak meg kell jelennie STATUS Ready,SchedulingDisabled. Ha egy ilyen állapotú csomópontot lát, használja ennek a csomópontnak az INTERNAL-IP IP-cím értékét az alábbi parancsban. Használja a verzióértékként frissített Kubernetes-verziót; ennek meg kell egyeznie a VERSION csomópont értékével ROLES control-plane,master. Mindenképpen adja meg a Kubernetes-verzió teljes értékét, beleértve például v1.22.6a v.

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

Az ssh-parancs futtatása után a régi Kubernetes-verzióval rendelkező többi csomópontot törölni kell, és a frissítés folytatódik.

Ha operációsrendszer-frissítést futtat egy gazdagépen egy AKS-sel az Azure Stack HCI üzemelő példányán, az az üzembe helyezés rossz állapotba kerül, ami elérhetetlenné teszi a felügyeleti fürt API-kiszolgálóját, és a második napon meghiúsul. A kube-vip pod nem tudja alkalmazni a VIP-konfigurációt az interfészre, ezért a VIP nem érhető el.

Reprodukálás: Fürt frissítése meglévő AKS HCI-telepítéssel HCI-ről HCIv2-re. Ezután próbálkozzon olyan parancsok futtatásával, amelyek megpróbálják elérni a felügyeleti fürtöt, például Get-AksHciCluster. A felügyeleti fürt elérésére tett minden művelet meghiúsul a következő hibákkal:

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

A probléma megoldásához indítsa újra a tárolót kube-vip , hogy az üzembe helyezés jó állapotba kerüljön.

1. A tárolóazonosító lekérése kube-vip :

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

A kimenetnek így kell kinéznie, és a tárolóazonosító az első érték 4a49a5158a5f8. Példa:

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

1. Indítsa újra a tárolót:

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

Ez az állapotüzenet az Update-AksHci PowerShell-parancsmag futtatásakor jelenik meg.

Tekintse át a probléma megoldásának következő kiváltó okait:

• Első ok: Az AksHci számlázási operátor frissítése során az operátor helytelenül jelölte meg magát a szabályzaton kívülre. A probléma megoldásához nyisson meg egy új PowerShell-ablakot, és futtassa a Sync-AksHciBilling parancsot. Látnia kell, hogy a számlázási művelet a következő 20–30 percen belül folytatódik.

• Második ok: Előfordulhat, hogy a felügyeleti fürt virtuális gépe nem rendelkezik memóriával, ami miatt az API-kiszolgáló elérhetetlenné válik, és időtúllépést okoz a Get-AksHciClustertől, a számlázástól és a frissítéstől. Áthidaló megoldásként állítsa a felügyeleti fürt virtuális gépét 32 GB-ra a Hyper-V-ben, majd indítsa újra.

• 3. ok: Előfordulhat, hogy az AksHci számlázási operátor nem rendelkezik tárterülettel, ami a Microsoft SQL konfigurációs beállításainak hibája miatt lehetséges. Előfordulhat, hogy a tárhely hiánya miatt a frissítés nem válaszol. A probléma megoldásához az alábbi lépések végrehajtásával manuálisan méretezze át a számlázási podot pvc .

  1. Futtassa a következő parancsot a podbeállítások szerkesztéséhez:

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

  2. Amikor a Jegyzettömb vagy egy másik szerkesztő yaML-fájllal nyílik meg, szerkessze a tárterület sorát 100Mi-ről 5Gi-ra:

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

  3. Ellenőrizze a számlázási telepítés állapotát az alábbi paranccsal:

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

Ha fürtöket frissít az Azure Stack HCI 2022. februári frissítéséről a 2022. áprilisi frissítésre, előfordulhat, hogy a frissítés határozatlan ideig nem frissül. Előfordulhat, hogy a podok elakadtak az állapotban vagy CrashLoopBackoff az Terminating állapotban.

Előfordulhat, hogy az AksHci CSI-bővítmény egyes erőforrásai hiányoznak. Ezek az erőforrás-podok a csi-akshcicsi-controller démonkészlet vagy a csi-akshcicsi-node démonkészlet használatával vannak üzembe helyezve.

Az AksHci CSI-bővítmény a 2022. februári frissítésben a CSI illesztőprogram-specifikációjának módosítását tartalmazta, amely néha a frissítés során nem válaszoló állapotban hagyhatja a bővítmény erőforrásait. A CSI-illesztő .spec.fsGroupPolicy új értékre lett beállítva, annak ellenére, hogy nem módosítható mező. Mivel a mező nem módosítható, az illesztő specifikációja nem frissül. Ennek az a következménye, hogy a többi AksHci CSI-bővítmény erőforrásai nem lesznek teljesen összeegyeztetve. Az összes CSI-erőforrás újra létre lesz hozva.

A probléma manuális megoldásához a CSI-illesztő manuálisan törölhető. Miután eltávolította, a felhőszolgáltató 10 percen belül egyezteti az AksHci CSI-bővítményt, és újra létrehozza az illesztőprogramot a hiányzó bővítményerőforrásokkal együtt.

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

A sikeres frissítés után a Windows Felügyeleti központ frissítési irányítópultja továbbra is az előző verziót jeleníti meg.

Frissítse a böngészőt a probléma megoldásához.

Az Azure Stack HCI-n futó AKS június 1.0.1.10628 buildje túl sok Kubernetes-konfigurációs titkos kulcsot hoz létre a fürtben. A június 1.0.1.10628-os kiadástól a július 1.0.2.10723-ig szóló frissítési útvonal továbbfejlesztve lett, hogy megtisztítsa az extra Kubernetes-titkos kódokat. Bizonyos esetekben azonban a frissítés során a titkos kulcsok még mindig nem lettek megtisztítva, ezért a frissítési folyamat meghiúsul.

Ha ezt a problémát tapasztalja, futtassa a következő lépéseket:

1. Mentse az alábbi szkriptet fix_leaked_secrets.ps1 nevű fájlként:

   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. Ezután futtassa a következő parancsot a mentett fix_secret_leak.ps1 fájl használatával:

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

3. Végül a következő PowerShell-paranccsal ismételje meg a frissítési folyamatot:

      Update-AksHci
   

Következő lépések

• Hibaelhárítási áttekintés
• Telepítési problémák és hibák
• A Windows Felügyeleti központ ismert problémái

Ha továbbra is problémákba ütközik az AKS Arc használatakor, a GitHubon keresztül is fájlba helyezheti a hibákat.