Problemen met Kubernetes-beheer- en workloadclusters in AKS Arc oplossen

Wanneer u de opdracht Remove-ClusterNode uitvoert, wordt het knooppunt verwijderd uit het failovercluster, maar als Remove-AksHciNode later niet wordt uitgevoerd, bestaat het knooppunt nog steeds in CloudAgent.

Omdat het knooppunt is verwijderd uit het cluster, maar niet uit CloudAgent, wordt de fout 'Bestand niet gevonden' weergegeven als u de VHD gebruikt om een nieuw knooppunt te maken. Dit probleem treedt op omdat de VHD zich in gedeelde opslag bevindt en het verwijderde knooppunt geen toegang heeft.

U kunt dit probleem oplossen door een fysiek knooppunt uit het cluster te verwijderen en vervolgens de volgende stappen uit te voeren:

1. Voer Remove-AksHciNode uit om het knooppunt uit te schrijven vanuit CloudAgent.
2. Routineonderhoud uitvoeren, zoals het opnieuw maken van de machine.
3. Voeg het knooppunt weer toe aan het cluster.
4. Voer Add-AksHciNode uit om het knooppunt te registreren bij CloudAgent.

Met grote clusters kan de Get-AksHciLogs opdracht een uitzondering genereren, knooppunten niet inventariseren of het uitvoerbestand c:\wssd\wssdlogs.zip niet genereren.

Dit komt doordat de PowerShell-opdracht voor het zippen van een bestand, 'Compress-Archive', een maximale bestandsgrootte van 2 GB heeft.

Na het upgraden of omhoog schalen van het workloadcluster heeft de pod voor certificaatvernieuwing nu de status crashlus omdat de pod het YAML-bestand van het certificaat tattoo verwacht vanaf de bestandslocatie /etc/Kubernetes/pki.

Dit probleem kan worden veroorzaakt door een configuratiebestand dat aanwezig is in de VM's in het besturingsvlak, maar niet in de werkknooppunt-VM's.

Om dit probleem op te lossen, kopieert u handmatig het YAML-bestand van het certificaat van het knooppunt van het besturingsvlak naar alle werkknooppunten.

1. Kopieer het YAML-bestand van de VM in het besturingsvlak op het workloadcluster 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` will work)
scp -i (get-mocconfig).sshprivatekey clouduser@<comtrol-plane-vm-ip>:~/cert*.yaml .\

1. Kopieer het YAML-bestand van de hostcomputer naar de VM van het werkknooppunt. Voordat u het bestand kopieert, moet u de naam van de machine in het YAML-bestand wijzigen in de naam van het knooppunt waarnaar u kopieert (dit is de naam van het knooppunt voor het besturingsvlak van het workloadcluster).

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

3. Als de eigenaar- en groepsgegevens in het YAML-bestand nog niet zijn ingesteld op de hoofdmap, stelt u de informatie in 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 certificate file to the correct location)
sudo chown root cert-tattoo-kubelet.yaml
sudo chgrp root cert-tattoo-kubelet.yaml

4. Herhaal stap 2 en 3 voor alle werkknooppunten.

De Aks-Hci PowerShell-opdrachten valideren het beschikbare geheugen op de hostserver niet voordat u Kubernetes-knooppunten maakt. Dit probleem kan leiden tot geheugenuitputting en virtuele machines die niet worden gestart.

Deze fout wordt momenteel niet correct verwerkt en de implementatie reageert niet meer zonder duidelijk foutbericht. Als u een implementatie hebt die niet meer reageert, opent u Logboeken en controleert u op een hyper-V-gerelateerd foutbericht dat aangeeft dat er onvoldoende geheugen is om de VIRTUELE machine te starten.

Bij het uitvoeren van Get-AksHciCluster om de status van een AKS Arc-installatie in het Windows-beheercentrum te controleren, wordt in de uitvoer een fout weergegeven: 'Er is geen release met versie 1.0.3.10818 gevonden'. Bij het uitvoeren van Get-AksHciVersion werd echter dezelfde versie geïnstalleerd. Deze fout geeft aan dat de build is verlopen.

U kunt dit probleem oplossen door een nieuwe AKS Arc-build uit te voeren Uninstall-AksHcien vervolgens uit te voeren.

Wanneer u het hulpprogramma voor clusterbeheer gebruikt om een VIRTUELE machine te verplaatsen van het ene knooppunt (knooppunt A) naar een ander knooppunt (knooppunt B) in het lokale Azure-cluster, kan de VM mogelijk niet worden gestart op het nieuwe knooppunt. Nadat u de VIRTUELE machine weer naar het oorspronkelijke knooppunt hebt verplaatst, kan deze ook niet meer worden gestart.

Dit probleem treedt op omdat de logica voor het opschonen van de eerste migratie asynchroon wordt uitgevoerd. Als gevolg hiervan vindt de logica van de 'update-VM-locatie' van Azure Kubernetes Service de VIRTUELE machine op het oorspronkelijke Hyper-V-knooppunt A en verwijdert deze, in plaats van de registratie ervan ongedaan te maken.

Als u dit probleem wilt omzeilen, moet u ervoor zorgen dat de virtuele machine is gestart op het nieuwe knooppunt voordat u het terugzet naar het oorspronkelijke knooppunt.

Wanneer u PowerShell gebruikt om een cluster met statische IP-adressen te maken en vervolgens probeert het aantal werkknooppunten in het workloadcluster te verhogen, blijft de installatie hangen bij 'aantal besturingsvlakken bij 2, nog steeds op gewenste status wachten: 3'. Na een bepaalde periode wordt een ander foutbericht weergegeven: 'Fout: time-out bij wachten op de voorwaarde'.

Toen Get-AksHciCluster werd uitgevoerd, bleek dat de besturingsvlakknooppunten zijn gemaakt en ingericht en in de status Gereed waren. Wanneer kubectl get nodes de uitvoering werd uitgevoerd, bleek echter dat de besturingsvlakknooppunten zijn gemaakt, maar niet zijn ingericht en niet in de status Gereed waren.

Als u deze fout krijgt, controleert u of de IP-adressen zijn toegewezen aan de gemaakte knooppunten met Hyper-V-beheer of PowerShell:

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

Controleer vervolgens de netwerkinstellingen om ervoor te zorgen dat er voldoende IP-adressen in de groep zijn om meer VM's te maken.

Opdrachten zoals Update-AksHci, Update-AksHciCertificates, Update-AksHciClusterCertificatesen alle interacties met het beheercluster kunnen 'Fout: U moet zijn aangemeld bij de server (niet gemachtigd).'

Deze fout kan optreden wanneer het kubeconfig-bestand is verlopen. Voer het volgende script uit om te controleren of deze is verlopen:

$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

Als dit script een datum weergeeft die ouder is dan de huidige datum, is het kubeconfig-bestand verlopen.

Als u het probleem wilt verhelpen, kopieert u het bestand admin.conf , dat zich in de VM van het beheerbeheervlak bevindt, naar de lokale Azure-host:

• SSH naar de VM met het beheervlak:

  • Haal het VM-IP-adres van het beheervlak op:

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

  • SSH erin:

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

• Kopieer het bestand naar de clouduserlocatie :

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

• Toegang verlenen tot clouduser:

  sudo chown clouduser:clouduser admin.conf
  

• [Optioneel] Maak een back-up van het kubeconfig-bestand :

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

• Kopieer het bestand:

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

Wanneer u Hyper-V-beheer controleert, kunnen hoge CPU- en geheugenvereisten voor het beheercluster veilig worden genegeerd. Ze zijn gerelateerd aan pieken in het rekenresourcegebruik bij het inrichten van workloadclusters.

Het vergroten van het geheugen of de CPU-grootte voor het beheercluster heeft geen aanzienlijke verbetering aangetoond en kan veilig worden genegeerd.

U ziet dit probleem als u deze stappen uitvoert:

1. Maak een Kubernetes-cluster.
2. Schaal het cluster naar meer dan twee knooppunten.
3. Verwijder een knooppunt door de volgende opdracht uit te voeren:

kubectl delete node <node-name>

4. Retourneer een lijst met de knooppunten door de volgende opdracht uit te voeren:

kubectl get nodes

Het verwijderde knooppunt wordt niet weergegeven in de uitvoer. 5. Open een PowerShell-venster met beheerdersbevoegdheden en voer de volgende opdracht uit:

get-vm

Het verwijderde knooppunt wordt nog steeds vermeld.

Deze fout zorgt ervoor dat het systeem niet herkent dat het knooppunt ontbreekt en daarom wordt er geen nieuw knooppunt uitgevoerd.

Als u geen beheer- of workloadcluster langer dan 60 dagen gebruikt, verlopen de certificaten en moet u deze vernieuwen voordat u AKS Arc kunt upgraden. Wanneer een AKS-cluster niet binnen 60 dagen wordt bijgewerkt, verlopen het KMS-invoegtoepassingstoken en de certificaten beide binnen de 60 dagen. Het cluster is nog steeds functioneel. Omdat het echter langer is dan 60 dagen, moet u microsoft-ondersteuning bellen om een upgrade uit te voeren. Als het cluster na deze periode opnieuw wordt opgestart, blijft het in een niet-functionele status.

Voer de volgende stappen uit om dit probleem op te lossen:

1. Herstel het beheerclustercertificaat door het token handmatig te draaien en start de KMS-invoegtoepassing en -container opnieuw op.
2. Herstel de mocctl certificaten door deze uit te voeren Repair-MocLogin.
3. Herstel de werkbelastingclustercertificaten door het token handmatig te draaien en start de KMS-invoegtoepassing en -container opnieuw op.

Het workloadcluster kan niet worden gevonden als de IP-adresgroepen van twee AKS in lokale Azure-implementaties hetzelfde zijn of elkaar overlappen. Als u twee AKS-hosts implementeert en dezelfde AksHciNetworkSetting configuratie voor beide gebruikt, kunnen PowerShell en Het Windows-beheercentrum het workloadcluster niet vinden, omdat aan de API-server hetzelfde IP-adres in beide clusters wordt toegewezen, wat resulteert in een conflict.

Het foutbericht dat u ontvangt, ziet er ongeveer uit zoals in het onderstaande voorbeeld.

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.

De implementatie van een groot cluster kan na twee uur een time-out hebben. Dit is echter een statische time-out.

U kunt deze time-outbewerking negeren wanneer de bewerking op de achtergrond wordt uitgevoerd. Gebruik de kubectl get nodes opdracht om toegang te krijgen tot uw cluster en de voortgang te controleren.

Bij een poging om na een paar dagen een AKS op de lokale Azure-implementatie weer te geven, Kubectl zijn er geen opdrachten uitgevoerd. In het kms-invoegtoepassingslogboek (Key Management Service) wordt het foutbericht 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 certificatesweergegeven.

De cmdlet Repair-AksHciClusterCerts mislukt als de API-server niet beschikbaar is. Als AKS op Azure Local gedurende 60 of meer dagen niet is bijgewerkt, wordt deze niet gestart wanneer u de KMS-invoegtoepassing opnieuw start. Deze fout zorgt er ook voor dat de API-server mislukt.

U kunt dit probleem oplossen door het token handmatig te roteren en vervolgens de KMS-invoegtoepassing en -container opnieuw te starten om de BACK-up van de API-server op te halen. Voer hiervoor de volgende stappen uit:

1. Draai het token door de volgende opdracht uit te voeren:

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

2. Kopieer het token naar de virtuele machine met behulp van de volgende opdracht. De ip instelling in de onderstaande opdracht verwijst naar het IP-adres van het besturingsvlak van de AKS-host.

   $ 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. Start de KMS-invoegtoepassing en de container opnieuw op.

   Voer de volgende opdracht uit om de container-id op te halen:

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

   De uitvoer moet worden weergegeven met de volgende velden:

   CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
   

   De uitvoer moet er ongeveer uitzien als in dit voorbeeld:

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

4. Start ten slotte de container opnieuw door de volgende opdracht uit te voeren:

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

Op een lokale installatie van AKS in Azure met de Windows Admin Center-extensie versie 1.82.0 is het beheercluster ingesteld met behulp van PowerShell en is geprobeerd een workloadcluster te implementeren met behulp van Het Windows-beheercentrum. Op een van de computers is PowerShell-moduleversie 1.0.2 geïnstalleerd en op andere computers is PowerShell-module 1.1.3 geïnstalleerd. De poging om het workloadcluster te implementeren is mislukt met de fout 'Er is geen parameter gevonden die overeenkomt met de parameternaam nodePoolName'. Deze fout is mogelijk opgetreden vanwege een niet-overeenkomende versie. Vanaf PowerShell versie 1.1.0 is de -nodePoolName <String> parameter toegevoegd aan de cmdlet New-AksHciCluster . Deze parameter is nu standaard verplicht bij het gebruik van de Windows Admin Center-extensie versie 1.82.0.

Ga als volgt te werk om dit probleem op te lossen:

• Gebruik PowerShell om het workloadcluster handmatig bij te werken naar versie 1.1.0 of hoger.
• Gebruik Windows Admin Center om het cluster bij te werken naar versie 1.1.0 of naar de nieuwste PowerShell-versie.

Dit probleem treedt niet op als het beheercluster wordt geïmplementeerd met behulp van het Windows-beheercentrum, omdat de meest recente PowerShell-modules al zijn geïnstalleerd.

Wanneer u AKS implementeert in Azure Local en vervolgens uitvoert kubectl get pods, blijven pods in hetzelfde knooppunt hangen in de afsluitstatus . De machine weigert SSH-verbindingen omdat het knooppunt waarschijnlijk een hoge geheugenvraag ondervindt. Dit probleem treedt op omdat de Windows-knooppunten te veel zijn ingericht en er geen reserve is voor kernonderdelen.

Om deze situatie te voorkomen, voegt u de resourcelimieten en resourceaanvragen voor CPU en geheugen toe aan de podspecificatie om ervoor te zorgen dat de knooppunten niet te veel worden ingericht. Windows-knooppunten bieden geen ondersteuning voor verwijdering op basis van resourcelimieten, dus u moet schatten hoeveel de containers gebruiken en vervolgens controleren of de knooppunten voldoende CPU- en geheugenbedragen hebben. Meer informatie vindt u in systeemvereisten.

Automatisch schalen van clusters kan mislukken wanneer u het volgende Azure-beleid op uw AKS-hostbeheercluster gebruikt: 'Kubernetes-clusters mogen de standaardnaamruimte niet gebruiken'. Dit gebeurt omdat het beleid, wanneer dit wordt geïmplementeerd op het AKS-hostbeheercluster, het maken van profielen voor automatische schaalaanpassing in de standaardnaamruimte blokkeert. Kies een van de volgende opties om dit probleem op te lossen:

• Verwijder de Azure Policy-extensie op het AKS-hostbeheercluster. Meer informatie over het verwijderen van Azure Policy-extensies vindt u hier.
• Wijzig het bereik van het Azure-beleid om AKS-hostbeheerclusters uit te sluiten. Meer informatie over Azure Policy-bereiken vindt u hier.
• Stel de beleids afdwingingsmodus in op Uitgeschakeld voor het AKS-hostbeheercluster. Meer informatie over de afdwingingsmodus vindt u hier.

Dit is een bekend probleem met de AKS op azure Local July Update (versie 1.0.2.10723). De fout treedt op omdat er een time-out optreedt voor de CloudAgent-service tijdens de distributie van virtuele machines op meerdere gedeelde clustervolumes in het systeem.

Als u dit probleem wilt oplossen, moet u een upgrade uitvoeren naar de nieuwste AKS in de lokale versie van Azure.

Als u een AKS-cluster inricht in Azure Local met nul Linux- of Windows-knooppunten, is de uitvoer een lege tekenreeks of null-waarde wanneer u Get-AksHciCluster uitvoert.

Null is een verwachte retour voor nul knooppunten.

Wanneer u een beheer- of workloadcluster langer dan vier dagen afsluit, verlopen de certificaten en is het cluster onbereikbaar. De certificaten verlopen omdat ze om veiligheidsredenen elke 3-4 dagen worden geroteerd.

Als u het cluster opnieuw wilt starten, moet u de certificaten handmatig herstellen voordat u clusterbewerkingen kunt uitvoeren. Voer de volgende opdracht Repair-AksHciClusterCerts uit om de certificaten te herstellen:

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

Bij het uitschalen van een workloadcluster zijn de bijbehorende Linux- en Windows-VM's toegevoegd als werkknooppunten, maar niet geconfigureerd als maximaal beschikbare VM's. Bij het uitvoeren van de opdracht Get-ClusterGroup is de zojuist gemaakte Virtuele Linux-machine niet geconfigureerd als een clustergroep.

Dit is een bekend probleem. Na het opnieuw opstarten gaat de mogelijkheid om VM's te configureren als maximaal beschikbaar soms verloren. De huidige tijdelijke oplossing is om op elk van de lokale Azure-knooppunten opnieuw op te starten wssdagent . Dit werkt alleen voor nieuwe VM's die worden gegenereerd door het maken van knooppuntgroepen bij het uitvoeren van een uitschaalbewerking of bij het maken van nieuwe Kubernetes-clusters na het opnieuw opstarten van de wssdagent knooppunten. U moet de bestaande VM's echter handmatig toevoegen aan het failovercluster.

Wanneer u een cluster omlaag schaalt, hebben de clusterbronnen met hoge beschikbaarheid de status Mislukt terwijl de VM's worden verwijderd. De tijdelijke oplossing voor dit probleem is om de mislukte resources handmatig te verwijderen.

Een AKS-cluster dat is geïmplementeerd in een Azure-VM werkte eerder prima, maar nadat de AKS-host enkele dagen was uitgeschakeld, werkte de Kubectl opdracht niet. Na het uitvoeren van de Kubectl get nodes of Kubectl get services opdracht is dit foutbericht weergegeven: Error from server (InternalError): an error on the server ("") has prevented the request from succeeding.

Dit probleem is opgetreden omdat de AKS-host langer dan vier dagen is uitgeschakeld, waardoor de certificaten verlopen. Certificaten worden vaak geroteerd in een cyclus van vier dagen. Voer Repair-AksHciClusterCerts uit om het verlopen van het certificaat op te lossen.

In een workloadcluster met statische IP-adressen en Windows-knooppunten zijn alle pods in een knooppunt (inclusief de daemonset pods) vastgelopen in een ContainerCreating-status . Wanneer u probeert verbinding te maken met dat knooppunt met behulp van SSH, mislukt de verbinding met een Connection timed out fout.

U kunt dit probleem oplossen door Hyper-V-beheer of Failoverclusterbeheer te gebruiken om de VIRTUELE machine van dat knooppunt uit te schakelen. Na 5 tot 10 minuten moet het knooppunt opnieuw zijn gemaakt, waarbij alle pods worden uitgevoerd.

Wanneer kubelet onder schijfdruk staat, worden ongebruikte containerinstallatiekopieën verzameld, waaronder onderbrekingsinstallatiekopieën en wanneer dit gebeurt, kan ContainerD de installatiekopie niet ophalen.

Voer de volgende stappen uit om dit probleem op te lossen:

1. Maak verbinding met het betrokken knooppunt met behulp van SSH en voer de volgende opdracht uit:

sudo su

2. Voer de volgende opdracht uit om de installatiekopie op te halen:

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

Volgende stappen

• Overzicht van probleemoplossing
• Netwerkproblemen en -fouten
• bekende problemen met opslag