Felsöka problem med Kubernetes-hantering och arbetsbelastningskluster i AKS Arc

När du kör kommandot Remove-ClusterNode avlägsnas noden från redundansklustret, men om Remove-AksHciNode inte körs efteråt finns noden fortfarande i CloudAgent.

Eftersom noden har tagits bort från klustret, men inte från CloudAgent, visas felet "Filen hittades inte" om du använder den virtuella hårddisken för att skapa en ny nod. Det här problemet beror på att den virtuella hårddisken finns i delad lagring och att den borttagna noden inte har åtkomst till den.

Lös problemet genom att ta bort en fysisk nod från klustret och sedan följa dessa steg:

1. Kör Remove-AksHciNode för att avregistrera noden från CloudAgent.
2. Utför rutinunderhåll, till exempel att återskapa avbildningen av datorn.
3. Lägg till noden i klustret igen.
4. Kör Add-AksHciNode för att registrera noden med CloudAgent.

Med stora kluster Get-AksHciLogs kan kommandot utlösa ett undantag, misslyckas med att räkna upp noder eller generera utdatafilen c:\wssd\wssdlogs.zip.

Det beror på att PowerShell-kommandot för att zippa en fil, "Compress-Archive", har en storleksgräns för utdatafilen på 2 GB.

När du har uppgraderat eller skalat upp arbetsbelastningsklustret är certifikatförnyelsepodden nu i ett kraschlooptillstånd eftersom podden förväntar sig yaml-filen för certifikattatuering från filplatsen /etc/Kubernetes/pki.

Det här problemet kan bero på en konfigurationsfil som finns på de virtuella datorerna på kontrollplanet, men inte på de virtuella datorerna för arbetsnoden.

Lös problemet genom att kopiera YAML-filen för certifikattatuering manuellt från kontrollplansnoden till alla arbetsnoder.

1. Kopiera YAML-filen från den virtuella kontrollplansdatorn i arbetsbelastningsklustret till den aktuella katalogen på 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` will work)
scp -i (get-mocconfig).sshprivatekey clouduser@<comtrol-plane-vm-ip>:~/cert*.yaml .\

1. Kopiera YAML-filen från värddatorn till den virtuella datorn med arbetsnoden. Innan du kopierar filen måste du ändra namnet på datorn i YAML-filen till det nodnamn som du kopierar till (det här är nodnamnet för kontrollplanet för arbetsbelastningsklustret).

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

3. Om ägar- och gruppinformationen i YAML-filen inte redan har angetts till rot anger du informationen till roten:

ssh clouduser@<workernode-vm-ip> -i (get-mocconfig).sshprivatekey
sudo cp ~/cert-tattoo-kubelet.yaml /etc/kubernetes/pki/cert-tattoo-kubelet.yaml (copies the certificate file to the correct location)
sudo chown root cert-tattoo-kubelet.yaml
sudo chgrp root cert-tattoo-kubelet.yaml

4. Upprepa steg 2 och 3 för alla arbetsnoder.

Aks-Hci PowerShell-kommandona validerar inte det tillgängliga minnet på värdservern innan kubernetes-noder skapas. Det här problemet kan leda till minnesöverbelastning och virtuella datorer som inte startas.

Det här felet hanteras för närvarande inte korrekt och distributionen slutar svara utan något tydligt felmeddelande. Om du har en distribution som slutar svara öppnar du Loggboken och söker efter ett Hyper-V-relaterat felmeddelande som anger att det inte finns tillräckligt med minne för att starta den virtuella datorn.

När du kör Get-AksHciCluster för att verifiera statusen för en AKS Arc-installation i Windows Admin Center visas ett fel: "En version med version 1.0.3.10818 hittades inte." Men när du körde Get-AksHciVersion visade den att samma version installerades. Det här felet anger att bygget har upphört att gälla.

Lös problemet genom att köra Uninstall-AksHcioch sedan köra en ny AKS Arc-version.

När du använder klusteradministrationsverktyget för att flytta en virtuell dator från en nod (Nod A) till en annan nod (Nod B) i Det lokala Azure-klustret kan den virtuella datorn inte starta på den nya noden. När du har flyttat tillbaka den virtuella datorn till den ursprungliga noden kan den inte heller starta där.

Det här problemet beror på att logiken för att rensa den första migreringen körs asynkront. Därför hittar Azure Kubernetes Service-logiken "uppdatera vm-plats" den virtuella datorn på den ursprungliga Hyper-V på noden A och tar bort den i stället för att avregistrera den.

Du kan undvika det här problemet genom att se till att den virtuella datorn har startats på den nya noden innan du flyttar tillbaka den till den ursprungliga noden.

När du använder PowerShell för att skapa ett kluster med statiska IP-adresser och sedan försöker öka antalet arbetsnoder i arbetsbelastningsklustret fastnar installationen vid "kontrollplansantalet vid 2, väntar fortfarande på önskat tillstånd: 3." Efter en viss tidsperiod visas ett annat felmeddelande: "Fel: tidsgränsen för att vänta på villkoret" visas.

När Get-AksHciCluster kördes visade den att kontrollplansnoderna skapades och etablerades och var i tillståndet Klar . När den kördes visade den dock kubectl get nodes att kontrollplanets noder hade skapats men inte etablerats och inte var i tillståndet Redo .

Om du får det här felet kontrollerar du att IP-adresserna har tilldelats till de skapade noderna med hjälp av antingen Hyper-V Manager eller PowerShell:

(Get-VM |Get-VMNetworkAdapter).IPAddresses |fl

Kontrollera sedan nätverksinställningarna för att se till att det finns tillräckligt med IP-adresser kvar i poolen för att skapa fler virtuella datorer.

Kommandon som Update-AksHci, Update-AksHciCertificates, Update-AksHciClusterCertificatesoch alla interaktioner med hanteringsklustret kan returnera "Error: You must be logged in to the server (Unauthorized)."

Det här felet kan inträffa när kubeconfig-filen har upphört att gälla. Kontrollera om det har upphört att gälla genom att köra följande skript:

$kubeconfig= $(get-kvaconfig).kubeconfig
$certDataRegex = '(?ms).*client-certificate-data:\s*(?<CertData>[^\n\r]+)'
$certDataMatch = Select-String -Path $kubeconfig -Pattern $certDataRegex
$certData = $certDataMatch.Matches[0].Groups['CertData'].Value
$certObject = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2
$certObject.Import([System.Convert]::FromBase64String($certData))
$expiryDate = $certObject.GetExpirationDateString()
$expiryDate

Om det här skriptet visar ett datum som är tidigare än det aktuella datumet har kubeconfig-filen upphört att gälla.

Du kan åtgärda problemet genom att kopiera filen admin.conf , som finns i den virtuella datorn för hanteringskontrollplanet, till den lokala Azure-värden:

• SSH till den virtuella datorn för hanteringskontrollplanet:

  • Hämta vm-IP-adressen för hanteringskontrollplanet:

    get-clusternode | % {Get-vm -computerName $_ } | get-vmnetworkadapter | select Name, IPAddresses
    

  • SSH i den:

    ssh -o StrictHostKeyChecking=no -i (Get-MocConfig).sshPrivateKey clouduser@<mgmt-control-plane-ip>
    

• Kopiera filen till clouduser-platsen:

  cp /etc/kubernetes/admin.conf /home/clouduser/admin.conf
  

• Ge åtkomst till clouduser:

  sudo chown clouduser:clouduser admin.conf
  

• [Valfritt] Skapa en säkerhetskopia av kubeconfig-filen :

  mv $(Get-KvaConfig).kubeconfig "$((Get-KvaConfig).kubeconfig).backup"
  

• Kopiera filen:

  scp -i (get-mocconfig).sshPrivateKey clouduser@10.64.92.14:~/admin.conf $(Get-KvaConfig).kubeconfig
  

När du kontrollerar Hyper-V-hanteraren kan höga processor- och minnesbehov för hanteringsklustret ignoreras på ett säkert sätt. De är relaterade till toppar i användningen av beräkningsresurser vid etablering av arbetsbelastningskluster.

Att öka minnes- eller CPU-storleken för hanteringsklustret har inte visat någon betydande förbättring och kan ignoreras på ett säkert sätt.

Du ser det här problemet om du följer dessa steg:

1. Skapa ett Kubernetes-kluster.
2. Skala klustret till fler än två noder.
3. Ta bort en nod genom att köra följande kommando:

kubectl delete node <node-name>

4. Returnera en lista över noderna genom att köra följande kommando:

kubectl get nodes

Den borttagna noden visas inte i utdata. 5. Öppna ett PowerShell-fönster med administratörsbehörighet och kör följande kommando:

get-vm

Den borttagna noden visas fortfarande.

Det här felet gör att systemet inte känner igen att noden saknas och därför startar inte en ny nod.

Om du inte använder ett hanterings- eller arbetsbelastningskluster längre än 60 dagar upphör certifikaten att gälla och du måste förnya dem innan du kan uppgradera AKS Arc. När ett AKS-kluster inte uppgraderas inom 60 dagar upphör KMS-plugin-token och certifikaten att gälla inom 60 dagar. Klustret fungerar fortfarande. Men eftersom det är längre än 60 dagar måste du anropa Microsofts support för att uppgradera. Om klustret startas om efter den här perioden förblir det i ett icke-funktionellt tillstånd.

Lös problemet genom att köra följande steg:

1. Reparera certifikatet för hanteringsklustret genom att rotera token manuellt och starta sedan om KMS-plugin-programmet och containern.
2. Reparera certifikaten mocctl genom att köra Repair-MocLogin.
3. Reparera arbetsbelastningsklustercertifikaten genom att rotera token manuellt och starta sedan om KMS-plugin-programmet och containern.

Det går inte att hitta arbetsbelastningsklustret om IP-adresspoolerna för två AKS på Azure Local-distributioner är desamma eller överlappar varandra. Om du distribuerar två AKS-värdar och använder samma AksHciNetworkSetting konfiguration för båda, kommer PowerShell och Windows Admin Center eventuellt inte att hitta arbetsbelastningsklustret eftersom API-servern tilldelas samma IP-adress i båda klusteren, vilket resulterar i en konflikt.

Felmeddelandet du får ser ut ungefär som exemplet nedan.

A workload cluster with the name 'clustergroup-management' was not found.
At C:\Program Files\WindowsPowerShell\Modules\Kva\0.2.23\Common.psm1:3083 char:9
+         throw $("A workload cluster with the name '$Name' was not fou ...
+         ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : OperationStopped: (A workload clus... was not found.:String) [], RuntimeException
    + FullyQualifiedErrorId : A workload cluster with the name 'clustergroup-management' was not found.

Distributionen av ett stort kluster kan överskrida tidsgränsen efter två timmar. Detta är dock en statisk timeout.

Du kan ignorera den här timeout-förekomsten eftersom åtgärden körs i bakgrunden. kubectl get nodes Använd kommandot för att komma åt klustret och övervaka förloppet.

När du försökte ta upp en AKS på Azure Local-distributionen efter några dagar, Kubectl utförde du inte något av dess kommandon. Plugin-loggen nyckelhanteringstjänst (KMS) (KMS) visade felmeddelandet rpc error:code = Unauthenticated desc = Valid Token Required_. After running [Repair-AksHciCerts](./reference/ps/repair-akshcicerts.md) to try to fix the issue, a different error appeared: _failed to repair cluster certificates.

Cmdleten Repair-AksHciClusterCerts misslyckas om API-servern är nere. Om AKS på Azure Local inte har uppgraderats på 60 dagar eller mer startar det inte när du försöker starta om KMS-plugin-programmet. Det här felet gör också att API-servern misslyckas.

För att åtgärda det här problemet måste du rotera token manuellt och sedan starta om KMS-plugin-programmet och containern för att hämta API-serversäkerhetskopian. Det gör du genom att köra följande steg:

1. Rotera token genom att köra följande kommando:

   $ mocctl.exe security identity rotate --name "KMSPlugin-<cluster-name>-moc-kms-plugin" --encode=false --cloudFqdn (Get-AksHciConfig).Moc.cloudfqdn > cloudlogin.yaml
   

2. Kopiera token till den virtuella datorn med hjälp av följande kommando. Inställningen ip i kommandot nedan refererar till IP-adressen för AKS-värdens kontrollplan.

   $ scp -i (Get-AksHciConfig).Moc.sshPrivateKey .\cloudlogin.yaml clouduser@<ip>:~/cloudlogin.yaml $ ssh -i (Get-AksHciConfig).Moc.sshPrivateKey clouduser@<ip> sudo mv cloudlogin.yaml /opt/wssd/k8s/cloudlogin.yaml
   

3. Starta om KMS-plugin-programmet och containern.

   Kör följande kommando för att hämta container-ID:t:

   $ ssh -i (Get-AksHciConfig).Moc.sshPrivateKey clouduser@<ip> "sudo docker container ls | grep 'kms'"
   

   Utdata bör visas med följande fält:

   CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
   

   Utdata bör se ut ungefär som i det här exemplet:

   4169c10c9712 f111078dbbe1 "/kms-plugin" 22 minutes ago Up 22 minutes k8s_kms-plugin_kms-plugin-moc-lll6bm1plaa_kube-system_d4544572743e024431874e6ba7a9203b_1
   

4. Starta slutligen om containern genom att köra följande kommando:

   $ ssh -i (Get-AksHciConfig).Moc.sshPrivateKey clouduser@<ip> "sudo docker container kill <Container ID>"
   

På en lokal AKS-installation i Azure med Windows Admin Center-tillägget version 1.82.0 konfigurerades hanteringsklustret med PowerShell och ett försök gjordes att distribuera ett arbetsbelastningskluster med hjälp av Windows Admin Center. En av datorerna hade PowerShell-modul version 1.0.2 installerad och andra datorer hade PowerShell-modulen 1.1.3 installerad. Försöket att distribuera arbetsbelastningsklustret misslyckades med felet "Det går inte att hitta en parameter som matchar parameternamnet "nodePoolName". Det här felet kan ha uppstått på grund av ett versionsfel. Från och med PowerShell version 1.1.0 lades parametern -nodePoolName <String> till i cmdleten New-AksHciCluster . Den här parametern är nu obligatorisk när du använder Windows Admin Center-tillägget version 1.82.0.

Lös problemet genom att göra något av följande:

• Använd PowerShell för att manuellt uppdatera arbetsbelastningsklustret till version 1.1.0 eller senare.
• Använd Windows Admin Center för att uppdatera klustret till version 1.1.0 eller till den senaste PowerShell-versionen.

Det här problemet uppstår inte om hanteringsklustret distribueras med Windows Admin Center eftersom det redan har de senaste PowerShell-modulerna installerade.

När du distribuerar AKS på Azure Local och sedan kör kubectl get pods, fastnar poddar i samma nod i tillståndet Avsluta . Datorn avvisar SSH-anslutningar eftersom noden sannolikt har hög minnesefterfrågan. Det här problemet beror på att Windows-noderna är överetablerade och det inte finns någon reserv för kärnkomponenter.

Undvik den här situationen genom att lägga till resursgränser och resursbegäranden för CPU och minne i poddspecifikationen för att säkerställa att noderna inte överetableras. Windows-noder stöder inte borttagning baserat på resursgränser, så du bör uppskatta hur mycket containrarna kommer att använda och sedan se till att noderna har tillräckligt med processor- och minnesmängder. Mer information finns i systemkraven.

Automatisk skalning av kluster kan misslyckas när du använder följande Azure-princip i AKS-värdhanteringsklustret: "Kubernetes-kluster bör inte använda standardnamnområdet." Detta beror på att principen, när den implementeras på AKS-värdhanteringsklustret, blockerar skapandet av autoskalningsprofiler i standardnamnområdet. Lös problemet genom att välja något av följande alternativ:

• Avinstallera Azure Policy-tillägget i AKS-värdhanteringsklustret. Läs mer om att avinstallera Azure Policy-tillägg här.
• Ändra omfånget för Azure-principen för att exkludera AKS-värdhanteringskluster. Läs mer om Azure Policy-omfång här.
• Ange principtillämpningsläget till "Inaktiverat" för AKS-värdhanteringsklustret. Läs mer om tvingande läge här.

Det här är ett känt problem med AKS på Azure Local July Update (version 1.0.2.10723). Felet uppstår eftersom CloudAgent-tjänsten överskrider tidsgränsen vid distributionen av virtuella datorer över flera klusterdelade volymer i systemet.

För att lösa det här problemet bör du uppgradera till den senaste versionen av AKS på Azure Local.

Om du etablerar ett AKS-kluster på Azure Local utan Linux- eller Windows-noder blir utdata ett tomt sträng- eller null-värde när du kör Get-AksHciCluster.

Null är en förväntad retur för noll noder.

När du stänger av ett hanterings- eller arbetsbelastningskluster i mer än fyra dagar upphör certifikaten att gälla och klustret kan inte nås. Certifikaten upphör att gälla eftersom de roteras var 3–4:e dag av säkerhetsskäl.

Om du vill starta om klustret måste du reparera certifikaten manuellt innan du kan utföra några klusteråtgärder. Om du vill reparera certifikaten kör du följande Repair-AksHciClusterCerts-kommando :

Repair-AksHciClusterCerts -Name <cluster-name> -fixKubeletCredentials

När du skalar ut ett arbetsbelastningskluster lades motsvarande virtuella Linux- och Windows-datorer till som arbetsnoder, men de konfigurerades inte som virtuella datorer med hög tillgänglighet. När kommandot Get-ClusterGroup kördes konfigurerades inte den nyligen skapade virtuella Linux-datorn som en klustergrupp.

Detta är ett känt problem. Efter en omstart går det ibland förlorat att konfigurera virtuella datorer som högtillgängliga. Den aktuella lösningen är att starta om wssdagent på var och en av de lokala Azure-noderna. Detta fungerar bara för nya virtuella datorer som genereras genom att skapa nodpooler när du utför en utskalningsåtgärd eller när du skapar nya Kubernetes-kluster efter omstart av wssdagent på noderna. Du måste dock lägga till befintliga virtuella datorer manuellt i redundansklustret.

När du skalar ned ett kluster är klusterresurserna med hög tillgänglighet i ett misslyckat tillstånd medan de virtuella datorerna tas bort. Lösningen på det här problemet är att ta bort de misslyckade resurserna manuellt.

Ett AKS-kluster som distribuerats på en virtuell Azure-dator fungerade tidigare bra, men när AKS-värden stängdes av i flera dagar Kubectl fungerade inte kommandot. När du har kört kommandot Kubectl get nodes eller Kubectl get services visas det här felmeddelandet: Error from server (InternalError): an error on the server ("") has prevented the request from succeeding.

Det här problemet uppstod eftersom AKS-värden var avstängd i mer än fyra dagar, vilket gjorde att certifikaten upphör att gälla. Certifikat roteras ofta i en fyradagarscykel. Kör Repair-AksHciClusterCerts för att åtgärda problemet med certifikatets giltighetstid.

I ett arbetsbelastningskluster med statiska IP-adresser och Windows-noder har alla poddar i en nod (inklusive daemonset poddarna) fastnat i ett ContainerCreating-tillstånd . När du försöker ansluta till noden med hjälp av SSH misslyckas anslutningen med ett Connection timed out fel.

Lös problemet genom att använda Hyper-V Manager eller Klusterhanteraren för växling vid fel för att inaktivera den virtuella datorn för noden. Efter 5 till 10 minuter ska noden ha återskapats, där alla poddar körs.

När kubelet är under disktryck samlar den in oanvända containeravbildningar, som kan innehålla pausbilder, och när detta händer kan ContainerD inte hämta avbildningen.

Lös problemet genom att köra följande steg:

1. Anslut till den berörda noden med hjälp av SSH och kör följande kommando:

sudo su

2. Kör följande kommando för att hämta avbildningen:

crictl pull ecpacr.azurecr.io/kube-proxy:<Kubernetes version>

Nästa steg

• Felsökningsöversikt
• Nätverksproblem och -fel
• kända problem med lagring