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 daarna niet wordt uitgevoerd, bestaat het knooppunt nog steeds in CloudAgent.

Omdat het knooppunt uit het cluster is verwijderd, 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 de gedeelde opslag bevindt en het verwijderde knooppunt er geen toegang toe heeft.

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

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

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

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

Na het upgraden of omhoog schalen van het workloadcluster, bevindt de pod voor certificaatvernieuwing zich nu in een crashlusstatus omdat de pod het YAML-bestand voor certificaattatoeage verwacht van de bestandslocatie /etc/Kubernetes/pki.

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

U kunt dit probleem oplossen door het YAML-bestand van de certificaattatoeage handmatig te kopiëren van het besturingsvlakknooppunt naar alle werkknooppunten.

1. Kopieer het YAML-bestand van de besturingsvlak-VM 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 computer in het YAML-bestand wijzigen in de naam van het knooppunt waarnaar u kopieert (dit is de knooppuntnaam 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 gegevens van de eigenaar en de groep in het YAML-bestand nog niet zijn ingesteld op root, 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 Kubernetes-knooppunten worden gemaakt. 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 een 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 Windows Admin Center te controleren, wordt in de uitvoer een fout weergegeven: 'A release with version 1.0.3.10818 was NOT FOUND'. Bij het uitvoeren van Get-AksHciVersion bleek echter dat dezelfde versie is geïnstalleerd. Deze fout geeft aan dat de build is verlopen.

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

Wanneer u het hulpprogramma voor clusterbeheer gebruikt om een VM van het ene knooppunt (knooppunt A) naar een ander knooppunt (knooppunt B) in het Azure Stack HCI-cluster te verplaatsen, kan de VM mogelijk niet worden gestart op het nieuwe knooppunt. Nadat u de VM terug naar het oorspronkelijke knooppunt hebt verplaatst, kan deze daar ook niet 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 Azure Kubernetes Service 'VM-locatie bijwerken' de VM op de oorspronkelijke Hyper-V op knooppunt A en verwijdert deze in plaats van de registratie ongedaan te maken.

U kunt dit probleem omzeilen door ervoor te zorgen dat de VM is gestart op het nieuwe knooppunt voordat u deze 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 wachtend op de gewenste status: 3'. Na een bepaalde periode wordt een ander foutbericht weergegeven: 'Fout: time-out in afwachting van de voorwaarde'.

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

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

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

Controleer vervolgens de netwerkinstellingen om te controleren of 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') retourneren.

Deze fout kan optreden wanneer het kubeconfig-bestand is verlopen. Voer het volgende script uit om te controleren of het 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 in dit script een datum wordt weergegeven die eerder is dan de huidige datum, is het kubeconfig-bestand verlopen.

Om het probleem te verhelpen, kopieert u het bestand admin.conf , dat zich in de beheerbesturingsvlak-VM bevindt, naar de HCI-host:

• SSH naar de beheerbesturingsvlak-VM:

  • Haal het VM-IP-adres van het beheerbesturingsvlak 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 gebruik van rekenresources 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 volgt:

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 vermeld in de uitvoer. 5. Open een PowerShell-venster met beheerdersbevoegdheden en voer de volgende opdracht uit:

get-vm

Het verwijderde knooppunt wordt nog steeds weergegeven.

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

Als u een beheer- of workloadcluster langer dan 60 dagen niet gebruikt, verlopen de certificaten en moet u deze vernieuwen voordat u AKS Arc kunt upgraden. Wanneer een AKS-cluster niet binnen 60 dagen wordt geüpgraded, verlopen het token van de KMS-invoegtoepassing en de certificaten beide binnen de 60 dagen. Het cluster is nog steeds functioneel. Omdat het echter langer is dan 60 dagen, moet u contact opnemen met microsoft-ondersteuning 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 roteren en vervolgens de KMS-invoegtoepassing en -container opnieuw te starten.
2. Herstel de mocctl certificaten door uit te voeren Repair-MocLogin.
3. Herstel de workloadclustercertificaten door het token handmatig te roteren en start vervolgens de KMS-invoegtoepassing en -container opnieuw op.

Het workloadcluster wordt mogelijk niet gevonden als de IP-adresgroepen van twee AKS op Azure Stack HCI-implementaties hetzelfde zijn of overlappen. Als u twee AKS-hosts implementeert en dezelfde AksHciNetworkSetting configuratie voor beide gebruikt, kunnen PowerShell en Windows Admin Center het workloadcluster mogelijk 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 als volgt uit.

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-out negeren omdat 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 in Azure Stack HCI-implementatie te maken, Kubectl heeft de bijbehorende opdrachten niet uitgevoerd. Het logboek van de KMS-invoegtoepassing (Key Management Service) heeft 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 in Azure Stack HCI gedurende 60 dagen of langer niet is bijgewerkt, wordt deze niet gestart wanneer u de KMS-invoegtoepassing opnieuw probeert op te starten. Deze fout zorgt er ook voor dat de API-server uitvalt.

U kunt dit probleem oplossen door het token handmatig te draaien en vervolgens de KMS-invoegtoepassing en -container opnieuw te starten om de BACK-up van de API-server te verkrijgen. 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 VM 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>"
   

Bij een installatie van AKS in Azure Stack HCI 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 Windows Admin Center. Op een van de computers was PowerShell-moduleversie 1.0.2 geïnstalleerd en op andere computers was 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 verplicht bij het gebruik van de Windows Admin Center extensieversie 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 is geïmplementeerd met behulp van Windows Admin Center omdat de meest recente PowerShell-modules al zijn geïnstalleerd.

Wanneer u AKS implementeert in Azure Stack HCI 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 geheugenbehoefte 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 gaan gebruiken en ervoor zorgen dat de knooppunten voldoende CPU- en geheugenhoeveelheden hebben. Meer informatie vindt u in Systeemvereisten.

Automatisch schalen van clusters kan mislukken wanneer u het volgende Azure-beleid gebruikt op uw AKS-hostbeheercluster: 'Kubernetes-clusters mogen niet de standaardnaamruimte gebruiken'. Dit gebeurt omdat het beleid, wanneer het is 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 extensie Azure Policy op het beheercluster van de AKS-host. 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 beleidshandhavingsmodus in op Uitgeschakeld voor het beheercluster van de AKS-host. Meer informatie over de afdwingingsmodus vindt u hier.

Dit is een bekend probleem met de juli-update voor AKS in Azure Stack HCI (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 over meerdere gedeelde clustervolumes in het systeem.

U kunt dit probleem oplossen door een upgrade uit te voeren naar de nieuwste AKS op Azure Stack HCI-release.

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

Null is een verwachte return 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 Virtuele Linux- en Windows-machines toegevoegd als werkknooppunten, maar zijn ze niet geconfigureerd als maximaal beschikbare VM's. Bij het uitvoeren van de opdracht Get-ClusterGroup is de zojuist gemaakte Linux-VM 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 het opnieuw opstarten wssdagent op elk van de Azure Stack HCI-knooppunten. 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 op de knooppunten. U moet de bestaande VM's echter handmatig toevoegen aan het failovercluster.

Wanneer u een cluster omlaag schaalt, hebben de clusterresources 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 goed, maar nadat de AKS-host enkele dagen was uitgeschakeld, werkte de Kubectl opdracht niet. Nadat u de Kubectl get nodes opdracht of Kubectl get services hebt uitgevoerd, wordt 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 probleem met 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 de status ContainerCreating . 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 VM 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 pauze-installatiekopieën. Als 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