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, bevindt de pod voor certificaatvernieuwing zich nu in een crashlusstatus. Het verwacht een certificaattatoeagebestand yaml van het pad /etc/Kubernetes/pki. Het configuratiebestand is aanwezig in de VM's van het besturingsvlakknooppunt, maar niet op werkknooppunt-VM's.

U kunt dit probleem oplossen door het certificaattoetatoeagebestand handmatig te kopiëren van het besturingsvlakknooppunt naar elk van de werkknooppunten.

1. Kopieer het bestand van de besturingsvlak-VM naar de huidige map van de 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 gegevens van de eigenaar en de groep van dit bestand weer in op root als dit nog niet is ingesteld op 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. Herhaal stap 2 en 3 voor elk van uw werkknooppunten.

Wanneer een cluster meer 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 bevinden. Continue pogingen om lid te worden van de cloudagent kunnen de toevoer van poorten op de host uitgeput raken. 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 lid te worden van de cloudagent, waardoor de poorten worden uitgeput.

Als u het probleem wilt oplossen, stopt u de uitvoering van de wssdagent. Omdat de service zich in de beginfase bevindt, kan het voorkomen dat u de service stopt. Als dat het zo is, beëindigt u het proces voordat u probeert de service 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 wordt uitgevoerd, 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 op te lossen:

   Repair-Moc
   

3. Zodra deze opdracht is voltooid, moet wssdagent de status Actief hebben.

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

Wanneer AKS-HCI geen upgrade kan uitvoeren van de release van mei naar de release van juni, is de verwachting dat AKS-HCI moet terugkeren naar de release van mei en moet blijven functioneren. MoC-agents blijven echter in een gestopte status en handmatige pogingen om de agent te starten, activeren ze niet.

Stappen voor het reproduceren

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

Verwacht gedrag

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

Symptomen

Niet-overeenkomende Aks-Hci-versie en MOC-versie

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

Niet-overeenkomende 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.

Het installatiekopieënpad van moc-agentservices heeft de 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 pad naar de installatiekopieën voor de knooppuntagent weer te geven: reg query "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, gaan mogelijk alle aangepaste taints, rollen en labels verloren die u aan uw werkknooppunten hebt toegevoegd. Omdat AKS een beheerde service is, wordt het toevoegen van aangepaste taints, labels en rollen niet ondersteund wanneer deze worden uitgevoerd buiten de opgegeven PowerShell-cmdlets of Windows Admin Center.

U kunt dit probleem omzeilen door de cmdlet New-AksHciNodePool uit te voeren om een knooppuntgroep met taints voor uw werkknooppunten correct te maken.

Als u een beheercluster hebt gemaakt, maar in de eerste 60 dagen geen workloadcluster hebt geïmplementeerd, wordt u geblokkeerd om er een te maken, omdat dit buiten het beleid valt. In dit geval, wanneer u Update-AksHci uitvoert, wordt het updateproces geblokkeerd met de fout Wachten tot implementatie 'AksHci Billing Operator' gereed is. Als u Sync-AksHciBilling uitvoert, wordt een geslaagde uitvoer geretourneerd. Als u Echter Get-AksHciBillingStatus uitvoert, is de verbindingsstatus OutofPolicy.

Als u in 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 de netwerkverbinding verliezen en dat het cluster in een slechte status valt.

Om te reproduceren

1. Start één Azure Stack HCI-knooppunt opnieuw op.
2. Wacht tot 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.

Om het probleem op te lossen, gebruikt u de MOC-opdrachten om de vNIC toe te voegen aan de VM.

1. Haal de vNIC-naam op voor de VM.

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

of

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

2. Verbind de vNIC met de VM.

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

of

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

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

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

of

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

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

Als u de pods wilt vrijgeven en dit probleem wilt oplossen, moet u kubelet opnieuw starten. Voer de volgende opdracht uit om het knooppunt NotReady met de statische pods weer te geven:

kubectl get nodes -o wide

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

kubectl describe node <IP of the node>

Gebruik SSH om u aan te melden bij het knooppunt NotReady 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 op te starten:

/etc/.../kubelet restart

Bij het uitvoeren van een upgrade in Windows Admin Center 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 is geïmplementeerd in een omgeving waarin een proxy is geconfigureerd. Op dit moment biedt Windows Admin Center 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-proxyopdracht.

Bij het upgraden van Kubernetes-clusters 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, als u clusters bijwerkt die zijn geïmplementeerd met een OPA, ervoor zorgen dat uw beleid het ophalen van installatiekopieën uit Azure Container Registry toestaat. Voor een upgrade van AKS in Azure Stack HCI moet u het volgende eindpunt toevoegen aan de lijst van uw beleid: ecpacr.azurecr.io.

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

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

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 te starten op de betrokken knooppunten. Hiermee wordt het probleem opgelost en wordt de implementatie weer in een goede staat gebracht. Voer de volgende opdracht uit:

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

Na het uitvoeren van Update-AksHciCluster, loopt het upgradeproces vast.

Voer de volgende opdracht uit om te controleren of er een computer met PHASE Verwijderen is waarop de vorige Kubernetes-versie wordt uitgevoerd van waaruit u een upgrade uitvoert.

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

Als er een computer 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 vastgelopen knooppunt.

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 voor uw workloadcluster kubeconfig opgeeft bij het aanroepen Get-AksHciCredentialvan , 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 STATUSReady,SchedulingDisabled. Als u een knooppunt met deze status ziet, gebruikt u de INTERNAL-IP van dit knooppunt als ip-adreswaarde in de volgende opdracht hieronder. Gebruik de Kubernetes-versie waarnaar u een upgrade uitvoert als versiewaarde; dit moet overeenkomen met ROLEScontrol-plane,masterde VERSION waarde van het knooppunt. Zorg ervoor dat u de volledige waarde voor de Kubernetes-versie opneemt, inclusief , vbijvoorbeeld v1.22.6.

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

Na het uitvoeren van deze ssh-opdracht 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 bewerkingen op dag twee mislukken. De kube-vip pod kan de VIP-configuratie niet toepassen op de interface, waardoor het VIP onbereikbaar is.

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 kube-vip container-id op:

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

De uitvoer moet er ongeveer als volgt uitzien, waarbij de container-id de eerste waarde 4a49a5158a5f8is. Bijvoorbeeld:

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 wanneer u de PowerShell-cmdlet Update-AksHci uitvoert.

Bekijk de volgende hoofdoorzaken om het probleem op te lossen:

• Reden 1: Tijdens de update van de AksHci Billing Operator heeft de operator zichzelf ten onrechte gemarkeerd als buiten het 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 20-30 minuten wordt voortgezet.

• Reden twee: de BEHEERcluster-VM heeft mogelijk onvoldoende geheugen, waardoor de API-server onbereikbaar is en er een time-out optreedt voor alle opdrachten van Get-AksHciCluster, facturering en update. Als tijdelijke oplossing stelt u de beheercluster-VM in Op 32 GB in Hyper-V en start u deze opnieuw op.

• Reden drie: de AksHci-factureringsoperator heeft mogelijk geen opslagruimte meer, wat wordt veroorzaakt door een fout in de Microsoft SQL-configuratie-instellingen. Het gebrek aan opslagruimte kan ertoe leiden dat de upgrade niet meer reageert. U kunt dit probleem omzeilen door de grootte van de factureringspod pvc handmatig te wijzigen met behulp van de volgende stappen.

  1. Voer de volgende opdracht uit om de pod-instellingen 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-update op Azure Stack HCI van februari 2022 naar de update van april 2022, kan het upgraden van de update voor onbepaalde tijd vastlopen. Er zijn mogelijk pods vastgelopen in de Terminating status of CrashLoopBackoff .

Mogelijk ziet u dat sommige AksHci CSI-invoegtoepassingsresources ontbreken. Deze resources-pods die zijn geïmplementeerd met behulp van de csi-akshcicsi-controller of van de csi-akshcicsi-node daemonset.

De AksHci CSI-invoegtoepassing in de update van februari 2022 bevatte een wijziging in de CSI-stuurprogrammaspecificatie waardoor de resources van de invoegtoepassing soms niet reageren tijdens de upgrade. Het CSI-stuurprogramma is .spec.fsGroupPolicy 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-addon-resources mogelijk niet volledig worden afgestemd. Alle CSI-resources worden opnieuw gemaakt.

Als u het probleem handmatig wilt oplossen, kan het CSI-stuurprogramma handmatig worden verwijderd. Nadat u deze hebt verwijderd, stemt de cloudoperator de AksHci CSI-invoegtoepassing binnen tien minuten af en maakt het stuurprogramma opnieuw, samen met de rest van de ontbrekende invoegtoepassingsresources.

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

Na een geslaagde upgrade wordt in het Windows Admin Center updatedashboard nog steeds de vorige versie weergegeven.

Vernieuw de browser om dit probleem op te lossen.

De 1.0.1.10628-build van AKS op Azure Stack HCI maakt een te groot aantal Kubernetes-configuratiegeheimen in het cluster. Het upgradepad van de release van juni 1.0.1.10628 naar de release van juli 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 behulp van het fix_secret_leak.ps1 bestand 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 Windows Admin Center

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