Problemen oplossen bij het upgraden van AKS Arc

Oudere versies van PowerShell worden niet verwijderd.

U kunt dit probleem omzeilen door dit script uit te voeren om oudere PowerShell-versies te verwijderen.

Na het upgraden of omhoog schalen van het doelcluster heeft de pod voor certificaatvernieuwing nu de status crashlus. Het verwacht een certificaat tattoo yaml bestand van het pad /etc/Kubernetes/pki. Het configuratiebestand bevindt zich in de vm's van het besturingsvlakknooppunt, maar niet op vm's van werkknooppunten.

U kunt dit probleem oplossen door het certificaattoeëerbestand handmatig van het knooppunt van het besturingsvlak naar elk van de werkknooppunten te kopiëren.

1. Kopieer het bestand van de VM van het besturingsvlak naar de huidige map van uw hostcomputer.

   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. Kopieer het bestand van de hostcomputer naar de VM van het werkknooppunt.

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

3. Stel de eigenaar- en groepsinformatie voor dit bestand weer in op de hoofdmap als dit nog niet is ingesteld op de hoofdmap.

   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. Herhaal stap 2 en 3 voor elk van uw werkknooppunten.

Wanneer een cluster langer dan 60 dagen niet is bijgewerkt, kan de knooppuntagent niet worden gestart tijdens het opnieuw opstarten van een knooppuntagent vanwege het verlopen van het token. Deze fout zorgt ervoor dat de agents zich in de beginfase bevindt. Continue pogingen om lid te worden van de cloudagent kunnen de levering van poorten op de host uitputten. De status voor de volgende opdracht is starten.

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

Verwacht gedrag: de knooppuntagent moet zich in de beginfase bevinden, die voortdurend probeert deel te nemen aan de cloudagent, waardoor de poorten worden uitgeput.

U kunt het probleem oplossen door te voorkomen dat wssdagent wordt uitgevoerd. Omdat de service zich in de startfase bevindt, kan het voorkomen dat u de service stopt. Zo ja, dan moet u het proces beëindigen voordat u de service probeert te stoppen.

1. Controleer of de wssdagent zich in de beginfase bevindt.

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

2. Dood het proces.

   kill -Name wssdagent -Force
   

3. Stop de service.

   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. Herhaal stap 1, 2 en 3 op elk knooppunt van het HCI-cluster met dit probleem.

2. Nadat u hebt bevestigd dat wssdagent niet actief is, start u de cloudagent als deze niet wordt uitgevoerd.

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

1. Controleer of de cloudagent actief is.

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

2. Voer de volgende opdracht uit om de wssdagent te herstellen:

   Repair-Moc
   

3. Zodra deze opdracht is voltooid, moet de wssdagent actief zijn.

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

Wanneer AKS-HCI niet kan worden bijgewerkt van de release van mei naar de release van juni, is de verwachting dat AKS-HCI moet terugkeren naar de release van mei en blijft functioneren. Maar het laat MOC-agents in een gestopte status en handmatige pogingen om de agent te starten, activeren ze niet.

Stappen om te reproduceren

1. Installeer AKS-HCI PowerShell-module versie 1.1.36.
2. Upgrade AKS-HCI. Als de upgrade mislukt, valt AKS-HCI terug naar mei, maar MOC-agents zijn offline.

Verwacht gedrag

Als de Aks-Hci-upgrade mislukt, is de verwachting dat AksHci wordt teruggezet naar de vorige release en zonder problemen blijft functioneren.

Symptomen

Komt niet overeen tussen Aks-Hci-versie en MOC-versie

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

Komt niet overeen tussen Get-MocVersion en wssdcloudagent.exe-versie

Get-MocVersion geeft aan dat de build van juni is geïnstalleerd terwijl de wssdcloudagent.exe versie aangeeft dat de build van mei is geïnstalleerd.

Installatiekopieënpad van MOC-agentservices heeft parameter implementatie-id

Voer de volgende opdracht uit om het pad naar de installatiekopieën voor de cloudagent weer te geven:

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

Voorbeelduitvoer

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

Gebruik de volgende opdracht om het afbeeldingspad voor de knooppuntagent weer te geven: regquery 'HKLM\System\CurrentControlSet\Services\wssdagent'

Voorbeelduitvoer

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

Voer de volgende PowerShell-cmdlets uit om het probleem te verhelpen:

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'

Wanneer u een upgrade uitvoert, verliest u mogelijk alle aangepaste taints, rollen en labels die u aan uw werkknooppunten hebt toegevoegd. Omdat AKS een beheerde service is, worden aangepaste taints, labels en rollen toegevoegd wanneer deze buiten de opgegeven PowerShell-cmdlets of het Windows-beheercentrum worden uitgevoerd, niet ondersteund.

Als u dit probleem wilt omzeilen, voert u de cmdlet New-AksHciNodePool uit om een knooppuntgroep correct te maken met taints voor uw werkknooppunten .

Als u een beheercluster hebt gemaakt, maar in de eerste 60 dagen nog geen workloadcluster hebt geïmplementeerd, kunt u er geen maken, omdat het nu niet meer beleid heeft. In deze situatie, wanneer u Update-AksHci uitvoert, wordt het updateproces geblokkeerd met de fout Wachten op implementatie 'AksHci Billing Operator' om gereed te zijn. Als u Sync-AksHciBilling uitvoert, wordt de uitvoer geretourneerd. Als u Echter Get-AksHciBillingStatus uitvoert, is de verbindingsstatus OutofPolicy.

Als u binnen 60 dagen geen workloadcluster hebt geïmplementeerd, valt de facturering buiten het beleid.

De enige manier om dit probleem op te lossen, is door opnieuw te implementeren met een schone installatie.

Als Azure Stack HCI-knooppunten na elkaar opnieuw worden opgestart, verliezen sommige virtuele machines de vNIC's die eraan zijn gekoppeld. Dit verlies van vNIC's zorgt ervoor dat de VM's netwerkconnectiviteit verliezen en dat het cluster een slechte status heeft.

Om te reproduceren

1. Start één Azure Stack HCI-knooppunt opnieuw op.
2. Wacht totdat het knooppunt opnieuw is opgestart. Het knooppunt moet worden gemarkeerd Up in het failovercluster.
3. Start de andere knooppunten opnieuw op.
4. Herhaal.

Verwacht gedrag De clusterstatus moet in orde zijn. Aan alle VM's moeten NIC's zijn gekoppeld.

Gebruik de MOC-opdrachten om de vNIC toe te voegen aan de virtuele machine om het probleem op te lossen.

1. Haal de naam van de vNIC op voor de virtuele machine.

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

or

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

2. Verbind de vNIC met de virtuele machine.

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

or

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

3. Als de vNIC-verbindingsopdracht mislukt, probeert u de verbinding te verbreken en opnieuw verbinding te maken. Hieronder volgt de opdracht voor de verbinding met vNIC.

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

or

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

Pods blijven hangen bij het wachten tot statische pods een gereede voorwaarde hebben.

Als u de pods wilt vrijgeven en dit probleem wilt oplossen, moet u kubelet opnieuw starten. Als u het NotReady-knooppunt wilt weergeven met de statische pods, voert u de volgende opdracht uit:

kubectl get nodes -o wide

Voer de volgende opdracht uit voor meer informatie over het foutieve knooppunt:

kubectl describe node <IP of the node>

Gebruik SSH om u aan te melden bij het NotReady-knooppunt door de volgende opdracht uit te voeren:

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

Voer vervolgens de volgende opdracht uit om kubelet opnieuw te starten:

/etc/.../kubelet restart

Bij het uitvoeren van een upgrade in het Windows-beheercentrum is de volgende fout opgetreden:

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.

Dit foutbericht treedt meestal op wanneer AKS in Azure Stack HCI wordt geïmplementeerd in een omgeving waarvoor een proxy is geconfigureerd. Op dit moment biedt Het Windows-beheercentrum geen ondersteuning voor het installeren van modules in een proxyomgeving.

U kunt deze fout oplossen door AKS in Azure Stack HCI in te stellen met behulp van de powershell-opdracht van de proxy.

Wanneer u Kubernetes-clusters bijwerkt met een OPEN Policy Agent (OPA), zoals OPA GateKeeper, kan het proces vastlopen en kan het niet worden voltooid. Dit probleem kan optreden omdat de beleidsagent is geconfigureerd om te voorkomen dat containerinstallatiekopieën uit privéregisters worden opgehaald.

Als u dit probleem wilt oplossen, moet u ervoor zorgen dat uw beleid het ophalen van installatiekopieën uit Azure Container Registry toestaat als u clusters bijwerkt die zijn geïmplementeerd met een OPA. Voor een AKS-upgrade in Azure Stack HCI moet u het volgende eindpunt toevoegen aan de lijst met beleidsregels: ecpacr.azurecr.io.

Het uitvoeren van een update van het besturingssysteem op een host met een AKS in Azure Stack HCI-implementatie kan ertoe leiden dat de implementatie een slechte status krijgt en twee bewerkingen mislukt. De MOC NodeAgent Services kunnen niet worden gestart op bijgewerkte hosts. Alle MOC-aanroepen naar de knooppunten mislukken.

Om te reproduceren: wanneer u een cluster bijwerkt met een bestaande AKS-implementatie van HCI naar HCIv2, kan een AKS-bewerking mislukken New-AksHciCluster . Het foutbericht geeft aan dat de MOC-knooppunten OutOfCapacity zijn. Voorbeeld:

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]

U kunt dit probleem oplossen door de wssdagent Moc NodeAgent-service op de betrokken knooppunten te starten. Dit lost het probleem op en brengt de implementatie terug naar een goede status. Voer de volgende opdracht uit:

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

Nadat Update-AksHciCluster is uitgevoerd, loopt het upgradeproces vast.

Voer de volgende opdracht uit om te controleren of er een computer is met PHASE verwijderen die de vorige Kubernetes-versie uitvoert waaruit u een upgrade uitvoert.

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

Als er een machine is met PHASE verwijderen en VERSION overeenkomen met de vorige Kubernetes-versie, gaat u verder met de volgende stappen.

U hebt de volgende informatie nodig om dit probleem op te lossen:

1. Kubernetes-versie waarnaar u uw workloadcluster bijwerkt.
2. IP-adres van het knooppunt dat is vastgelopen.

Voer de volgende cmdlet en opdracht uit om deze informatie te vinden. Standaard schrijft de cmdlet Get-AksHciCredential de kubeconfig naar ~/.kube/config. Als u een andere locatie opgeeft voor uw workloadcluster-kubeconfig bij het aanroepen Get-AksHciCredential, moet u die locatie opgeven voor kubectl als een ander argument. Bijvoorbeeld: kubectl get nodes -o wide --kubeconfig <path to workload cluster kubeconfig>.

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

Het knooppunt dat moet worden hersteld, moet worden weergegeven STATUS Ready,SchedulingDisabled. Als u een knooppunt met deze status ziet, gebruikt u het INTERNAL-IP van dit knooppunt als de IP-adreswaarde in de volgende opdracht hieronder. Gebruik de Kubernetes-versie waarnaar u een upgrade uitvoert als versiewaarde; dit moet overeenkomen met de VERSION waarde van het knooppunt met ROLES control-plane,master. Zorg ervoor dat u de volledige waarde voor de Kubernetes-versie opneemt, inclusief de v, bijvoorbeeld v1.22.6.

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

Nadat u deze ssh-opdracht hebt uitgevoerd, moeten de resterende knooppunten met de oude Kubernetes-versie worden verwijderd en wordt de upgrade voortgezet.

Het uitvoeren van een update van het besturingssysteem op een host met een AKS in Azure Stack HCI-implementatie kan ertoe leiden dat de implementatie een slechte status krijgt, waardoor de API-server van het beheercluster onbereikbaar wordt en mislukt op de twee dagen. De kube-vip pod kan de VIP-configuratie niet toepassen op de interface en daardoor is het VIP niet bereikbaar.

Om te reproduceren: Werk een cluster bij met een bestaande AKS HCI-implementatie van HCI naar HCIv2. Voer vervolgens opdrachten uit die proberen het beheercluster te bereiken, zoals Get-AksHciCluster. Bewerkingen die proberen het beheercluster te bereiken, mislukken met fouten zoals:

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

U kunt dit probleem oplossen door de kube-vip container opnieuw te starten om de implementatie weer in goede staat te brengen.

1. Haal de container-id kube-vip op:

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

De uitvoer ziet er ongeveer als volgt uit, waarbij de container-id de eerste waarde 4a49a5158a5f8is. Voorbeeld:

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

1. Start de container opnieuw op:

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

Dit statusbericht wordt weergegeven bij het uitvoeren van de PowerShell-cmdlet Update-AksHci .

Bekijk de volgende hoofdoorzaken om het probleem op te lossen:

• Reden 1: tijdens de update van de AksHci Billing Operator heeft de operator zichzelf onjuist gemarkeerd als niet-beleid. U kunt dit probleem oplossen door een nieuw PowerShell-venster te openen en Sync-AksHciBilling uit te voeren. U ziet dat de factureringsbewerking binnen de komende 20-30 minuten wordt voortgezet.

• Reden twee: de VM van het beheercluster is mogelijk niet meer geheugen beschikbaar, waardoor de API-server onbereikbaar is en alle opdrachten maakt van Get-AksHciCluster, facturering en update, time-out. Als tijdelijke oplossing stelt u de vm van het beheercluster in op 32 GB in Hyper-V en start u deze opnieuw op.

• Reden drie: de AksHci-factureringsoperator is mogelijk niet meer in de opslagruimte. Dit komt door een fout in de Microsoft SQL-configuratie-instellingen. Het ontbreken van opslagruimte kan ertoe leiden dat de upgrade niet meer reageert. U kunt dit probleem omzeilen door het formaat van de factureringspod pvc handmatig te wijzigen met behulp van de volgende stappen.

  1. Voer de volgende opdracht uit om de podinstellingen te bewerken:

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

  2. Wanneer Kladblok of een andere editor wordt geopend met een YAML-bestand, bewerkt u de regel voor opslag van 100Mi naar 5Gi:

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

  3. Controleer de status van de factureringsimplementatie met behulp van de volgende opdracht:

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

Wanneer u clusters bijwerkt van de AKS op Azure Stack HCI-update van februari 2022 naar de update van april 2022, kan de update gedurende onbepaalde tijd vastlopen. Er zijn mogelijk pods vastgelopen in de Terminating of CrashLoopBackoff status.

U ziet mogelijk dat sommige AksHci CSI-invoegtoepassingsbronnen ontbreken. Deze resourcespods die zijn geïmplementeerd met behulp van of csi-akshcicsi-controller vanuit de csi-akshcicsi-node daemonset.

De AksHci CSI-invoegtoepassing in de update van februari 2022 bevatte een wijziging in de CSI-stuurprogrammaspecificatie die de resources van de invoegtoepassing soms niet reageert tijdens de upgrade. Het CSI-stuurprogramma .spec.fsGroupPolicy is ingesteld op een nieuwe waarde, ook al is het een onveranderbaar veld. Omdat het veld onveranderbaar is, wordt de stuurprogrammaspecificatie niet bijgewerkt. Een gevolg hiervan is dat de andere AksHci CSI-invoegtoepassingsbronnen mogelijk niet volledig worden afgestemd. Alle CSI-resources worden opnieuw gemaakt.

Om het probleem handmatig op te lossen, kan het CSI-stuurprogramma handmatig worden verwijderd. Nadat u deze hebt verwijderd, wordt de AksHci CSI-invoegtoepassing binnen de tien minuten met elkaar afgestemd en wordt het stuurprogramma opnieuw gemaakt, samen met de rest van de ontbrekende addon-resources.

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

Na een geslaagde upgrade wordt in het updatedashboard van het Windows-beheercentrum nog steeds de vorige versie weergegeven.

Vernieuw de browser om dit probleem op te lossen.

De build van 1.0.1.10628 van AKS op Azure Stack HCI maakt een overschot aan Kubernetes-configuratiegeheimen in het cluster. Het upgradepad van de release van 1.0.1.10628 naar de release van 1.0.2.10723 is verbeterd om de extra Kubernetes-geheimen op te schonen. In sommige gevallen tijdens het upgraden zijn de geheimen echter nog steeds niet opgeschoond en daarom mislukt het upgradeproces.

Als u dit probleem ondervindt, voert u de volgende stappen uit:

1. Sla het onderstaande script op als een bestand met de naam 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. Voer vervolgens de volgende opdracht uit met het bestand fix_secret_leak.ps1 dat u hebt opgeslagen:

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

3. Gebruik ten slotte de volgende PowerShell-opdracht om het upgradeproces te herhalen:

      Update-AksHci
   

Volgende stappen

• Overzicht van probleemoplossing
• Installatieproblemen en -fouten
• Bekende problemen in het Windows-beheercentrum

Als u problemen blijft ondervinden wanneer u AKS Arc gebruikt, kunt u fouten indienen via GitHub.