Lösa problem vid uppgradering av AKS Arc

Äldre versioner av PowerShell tas inte bort.

Du kan lösa det här problemet genom att köra det här skriptet för att avinstallera äldre PowerShell-versioner.

När du har uppgraderat eller skalat upp målklustret är certifikatförnyelsepodden nu i ett kraschlooptillstånd. Den förväntar sig en cert-tatueringsfil yaml från sökvägen /etc/Kubernetes/pki. Konfigurationsfilen finns på de virtuella datorerna för kontrollplansnoden, men inte på virtuella datorer med arbetsnoder.

Lös problemet genom att manuellt kopiera certifikattatueringsfilen från kontrollplansnoden till var och en av arbetsnoderna.

1. Kopiera filen från den virtuella kontrollplanets virtuella dator till den aktuella katalogen för värddatorn.

   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. Kopiera filen från värddatorn till den virtuella datorn med arbetsnoden.

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

3. Ange ägar- och gruppinformationen för den här filen till roten igen om den inte redan har angetts till rot.

   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. Upprepa steg 2 och 3 för var och en av dina arbetsnoder.

När ett kluster inte har uppgraderats på mer än 60 dagar startar inte nodagenten under en omstart av nodagenten på grund av att token upphör att gälla. Det här felet gör att agenterna är i startfasen. Kontinuerliga försök att ansluta till cloudagenten kan uttömma leveransen av portar på värden. Status för följande kommando är Start.

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

Förväntat beteende: Nodagenten bör vara i startfasen, som ständigt försöker ansluta till molnagenten och uttömma portarna.

Lös problemet genom att stoppa wssdagent från att köras. Eftersom tjänsten är i startfasen kan det hindra dig från att stoppa tjänsten. I så fall avbryter du processen innan du försöker stoppa tjänsten.

1. Bekräfta att wssdagent är i startfasen.

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

2. Avsluta processen.

   kill -Name wssdagent -Force
   

3. Stoppa tjänsten.

   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. Upprepa steg 1, 2 och 3 vid varje nod i azure local-klustret som har det här problemet.

2. När du har bekräftat att wssdagent inte körs startar du cloudagenten om den inte körs.

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

1. Bekräfta att cloudagenten är igång.

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

2. Kör följande kommando för att åtgärda wssdagent:

   Repair-Moc
   

3. När det här kommandot har slutförts bör wssdagent vara i körningstillstånd.

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

När AKS på Azure Local inte kan uppgraderas från majversionen till juniversionen är förväntningarna att AKS på Azure Local ska återgå till majversionen och fortsätta att fungera. Men det lämnar MOC-agenter i ett stoppat tillstånd och manuella försök att starta agenten aktiverar dem inte.

Steg för att återskapa

1. Installera AKS-HCI PowerShell-modul version 1.1.36.
2. Uppgradera AKS på Azure Local. Om uppgraderingen misslyckas återgår AKS på Azure Local till maj, men MOC-agenter är nere.

Förväntat beteende

Om AKS på Azure Local-uppgraderingen misslyckas är förväntningarna att AKS på Azure Local återgår till den tidigare versionen och fortsätter att fungera utan problem.

Symtom

Matchningsfel mellan Aks-Hci-version och MOC-version

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

Matchningsfel mellan Get-MocVersion och wssdcloudagent.exe version

Get-MocVersion anger att juniversionen är installerad medan den wssdcloudagent.exe versionen anger att majversionen är installerad.

Avbildningssökvägen för MOC-agenttjänster har en distributions-ID-parameter

Kör följande kommando för att visa avbildningssökvägen för molnagenten:

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

Exempel på utdata

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

Använd följande kommando för att visa avbildningssökvägen för nodagenten: reg-frågan "HKLM\System\CurrentControlSet\Services\wssdagent"

Exempel på utdata

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

Du kan åtgärda problemet genom att köra följande PowerShell-cmdletar:

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'

När du uppgraderar kan du förlora alla anpassade taints, roller och etiketter som du har lagt till i dina arbetsnoder. Eftersom AKS är en hanterad tjänst stöds inte tillägg av anpassade taints, etiketter och roller när de utförs utanför de angivna PowerShell-cmdletarna eller Windows Admin Center.

Du kan undvika det här problemet genom att köra cmdleten New-AksHciNodePool för att korrekt skapa en nodpool med taints för dina arbetsnoder.

Om du har skapat ett hanteringskluster men inte har distribuerat ett arbetsbelastningskluster under de första 60 dagarna blockeras du från att skapa ett, eftersom det nu är out-of-policy. I det här fallet blockeras uppdateringsprocessen när du kör Update-AksHci med felet Väntar på att distributionen "AksHci Billing Operator" ska vara klar. Om du kör Sync-AksHciBilling returneras lyckade utdata. Men om du kör Get-AksHciBillingStatus är anslutningsstatusen OutofPolicy.

Om du inte har distribuerat ett arbetsbelastningskluster på 60 dagar går faktureringen ur principen.

Det enda sättet att åtgärda det här problemet är att distribuera om med en ren installation.

Om lokala Azure-noder startas om en efter en förlorar vissa av de virtuella datorerna de virtuella nätverkskort som är kopplade till dem. Den här förlusten av virtuella nätverkskort gör att de virtuella datorerna förlorar nätverksanslutningen och klustret hamnar i ett felaktigt tillstånd.

Återskapa

1. Starta om en lokal Azure-nod.
2. Vänta tills noden har slutfört omstarten. Noden måste markeras Up i redundansklustret.
3. Starta om de andra noderna.
4. Upprepa.

Förväntat beteende Klustertillståndet bör vara felfritt. Alla virtuella datorer ska ha nätverkskort kopplade till sig.

För att lösa problemet använder du MOC-kommandona för att lägga till det virtuella nätverkskortet till den virtuella datorn.

1. Hämta vNIC-namn för den virtuella datorn.

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

eller

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

2. Anslut det virtuella nätverkskortet till den virtuella datorn.

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

eller

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

3. Om kommandot vNIC connect misslyckas kan du försöka koppla från och ansluta igen. Följande är kommandot för frånkoppling av virtuellt nätverkskort.

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

eller

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

Poddar har fastnat i väntan på att statiska poddar ska ha ett klart villkor.

Om du vill släppa poddarna och lösa det här problemet bör du starta om kubelet. Om du vill visa noden NotReady med de statiska poddarna kör du följande kommando:

kubectl get nodes -o wide

Kör följande kommando för att få mer information om den felaktiga noden:

kubectl describe node <IP of the node>

Använd SSH för att logga in på noden NotReady genom att köra följande kommando:

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

Kör sedan följande kommando för att starta om kubelet:

/etc/.../kubelet restart

När du körde en uppgradering i Windows Admin Center inträffade följande fel:

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.

Det här felmeddelandet inträffar vanligtvis när AKS på Azure Local distribueras i en miljö som har en konfigurerad proxy. För närvarande har Windows Administrationscenter inte stöd för att installera moduler i en proxymiljö.

Lös det här felet genom att konfigurera AKS på Azure Local med hjälp av powershell-proxykommandot.

När du uppgraderar Kubernetes-kluster med en OPA (Open Policy Agent), till exempel OPA GateKeeper, kanske processen låser sig och inte kan slutföras. Det här problemet kan inträffa eftersom principagenten är konfigurerad för att förhindra att containeravbildningar hämtas från privata register.

Om du uppgraderar kluster som distribuerats med en OPA ska du lösa problemet genom att se till att dina principer tillåter att avbildningar hämtas från Azure Container Registry. För en AKS på lokal Azure-uppgradering bör du lägga till följande slutpunkt i din princips lista: ecpacr.azurecr.io.

Om du kör en OS-uppdatering på en värd med en AKS på Azure Local-distributionen kan distributionen gå in i ett felaktigt tillstånd och misslyckas dag två. MOC NodeAgent Services kan inte starta på uppdaterade värdar. Alla MOC-anrop till noderna misslyckas.

Återskapa: När du uppdaterar ett kluster med en befintlig AKS-distribution från HCI till HCIv2 OS kan en AKS-åtgärd som New-AksHciCluster kan misslyckas. Felmeddelandet anger att MOC-noderna är OutOfCapacity. Till exempel:

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]

Lös problemet genom att starta tjänsten wssdagent Moc NodeAgent på de berörda noderna. Detta löser problemet och gör att distributionen återgår till ett bra tillstånd. Kör följande kommando:

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

När du har kört Update-AksHciCluster stannar uppgraderingsprocessen.

Kör följande kommando för att kontrollera om det finns en dator med PHASE borttagning som kör den tidigare Kubernetes-versionen som du uppgraderar från.

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

Om det finns en dator med PHASE borttagning och VERSION matchning av den tidigare Kubernetes-versionen fortsätter du med följande steg.

För att lösa det här problemet behöver du följande information:

1. Kubernetes-version som du uppgraderar arbetsbelastningsklustret till.
2. IP-adressen för den nod som har fastnat.

Du hittar den här informationen genom att köra följande cmdlet och kommando. Som standard skriver cmdleten Get-AksHciCredential kubeconfig till ~/.kube/config. Om du anger en annan plats för arbetsbelastningsklustret kubeconfig när du anropar Get-AksHciCredentialmåste du ange platsen för kubectl som ett annat argument. Exempel: kubectl get nodes -o wide --kubeconfig <path to workload cluster kubeconfig>

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

Noden som måste åtgärdas ska visa STATUS Ready,SchedulingDisabled. Om du ser en nod med den här statusen INTERNAL-IP använder du noden som IP-adressvärde i följande kommando nedan. Använd den Kubernetes-version som du uppgraderar till som versionsvärde. detta bör matcha VERSION värdet från noden med ROLES control-plane,master. Se till att inkludera det fullständiga värdet för Kubernetes-versionen, inklusive v, till exempel v1.22.6.

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

När du har kört det här ssh-kommandot ska de återstående noderna med den gamla Kubernetes-versionen tas bort och uppgraderingen fortsätter.

Om du kör en OS-uppdatering på en värd med en AKS på Azure Local-distributionen kan distributionen ange ett felaktigt tillstånd, vilket gör att hanteringsklustrets API-server inte kan nås och misslyckas dag två. Podden kube-vip kan inte tillämpa VIP-konfigurationen på gränssnittet och därför går det inte att nå VIP:en.

Återskapa: Uppdatera ett kluster med en befintlig AKS HCI OS-distribution från HCI till HCIv2. Prova sedan att köra kommandon som försöker nå hanteringsklustret, till exempel Get-AksHciCluster. Alla åtgärder som försöker nå hanteringsklustret misslyckas med fel som:

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

Lös problemet: Starta om containern kube-vip för att återställa distributionen till ett bra tillstånd.

1. Hämta container-ID kube-vip :t:

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

Utdata bör se ut ungefär så här, med container-ID:t som det första värdet 4a49a5158a5f8. Till exempel:

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

1. Starta om containern:

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

Det här statusmeddelandet visas när du kör PowerShell-cmdleten Update-AksHci .

Gå igenom följande rotorsaker för att lösa problemet:

• Orsak ett: Under uppdateringen av AksHci-faktureringsoperatören markerade operatorn felaktigt sig själv som out-of-policy. Lös problemet genom att öppna ett nytt PowerShell-fönster och köra Sync-AksHciBilling. Du bör se faktureringsåtgärden fortsätta inom de närmaste 20–30 minuterna.

• Orsak två: Den virtuella datorn för hanteringsklustret kan ha slut på minne, vilket gör att API-servern inte kan nås och gör att alla kommandon från Get-AksHciCluster, fakturering och uppdatering överskrider tidsgränsen. Som en lösning ställer du in den virtuella datorn för hanteringsklustret på 32 GB i Hyper-V och startar om den.

• Orsak tre: AksHci-faktureringsoperatören kan ha slut på lagringsutrymme, vilket beror på en bugg i Konfigurationsinställningarna för Microsoft SQL. Bristen på lagringsutrymme kan orsaka att uppgraderingen slutar svara. Lös problemet genom att ändra storlek på faktureringspodden pvc manuellt med hjälp av följande steg.

  1. Kör följande kommando för att redigera poddinställningarna:

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

  2. När Anteckningar eller en annan redigerare öppnas med en YAML-fil redigerar du raden för lagring från 100Mi till 5Gi:

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

  3. Kontrollera statusen för faktureringsdistributionen med hjälp av följande kommando:

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

När du uppgraderar kluster från AKS på Azure Local February 2022 Update till april 2022-uppdateringen kan uppdateringen ha fastnat vid uppgraderingen på obestämd tid. Det kan finnas poddar som har fastnat i antingen Terminating tillståndet eller CrashLoopBackoff .

Du kan se att vissa av AksHci CSI-tilläggsresurserna saknas. Dessa resurspoddar som distribueras med hjälp av csi-akshcicsi-controller eller från csi-akshcicsi-node daemonseten.

AksHci CSI-tillägget i februari 2022-uppdateringen innehöll en ändring av CSI-drivrutinsspecifikationen som ibland kan lämna tilläggets resurser i ett tillstånd som inte svarar under uppgraderingen. CSI-drivrutinens har angetts .spec.fsGroupPolicy till ett nytt värde trots att det är ett oföränderligt fält. Eftersom fältet är oföränderligt uppdateras inte drivrutinsspecifikationen. En följd av detta är att de andra AksHci CSI-tilläggsresurserna kanske inte blir helt avstämda. Alla CSI-resurser skulle återskapas.

För att lösa problemet manuellt kan CSI-drivrutinen tas bort manuellt. När du har tagit bort det avstäms AksHci CSI-tillägget av molnoperatorn inom 10 minuter och drivrutinen återskapas tillsammans med resten av de resurser som saknas.

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

Efter en lyckad uppgradering visar windows Admin Center-uppdateringsinstrumentpanelen fortfarande den tidigare versionen.

Uppdatera webbläsaren för att åtgärda problemet.

Den 1 juni 1.0.1.10628-versionen av AKS på Azure Local skapar ett överskott av Kubernetes-konfigurationshemligheter i klustret. Uppgraderingsvägen från 1.0.1.10628-versionen till den 1 juli 2.10723-versionen förbättrades för att rensa de extra Kubernetes-hemligheterna. Men i vissa fall under uppgraderingen rensades hemligheterna fortfarande inte, och därför misslyckas uppgraderingsprocessen.

Om det här problemet uppstår kör du följande steg:

1. Spara skriptet nedan som en fil med namnet 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. Kör sedan följande kommando med hjälp av filen fix_secret_leak.ps1 som du sparade:

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

3. Använd slutligen följande PowerShell-kommando för att upprepa uppgraderingsprocessen:

      Update-AksHci
   

Nästa steg

• Felsökningsöversikt
• Installationsproblem och -fel
• Kända problem med Windows Admin Center

Om du fortsätter att stöta på problem när du använder AKS Arc kan du skicka buggar via GitHub.