Bewerken

Delen via


Bekende problemen en fouten met beveiliging en identiteiten in AKS Arc oplossen

Gebruik dit onderwerp om u te helpen bij het oplossen van beveiligings- en identiteitsproblemen in AKS Arc.

Get-AksHciCredential mislukt met de fout 'kan het opgegeven pad niet vinden'

De Get-AksHciCredential PowerShell-cmdlet mislukt wanneer deze wordt uitgevoerd door een andere gebruiker met beheerdersrechten dan de cmdlet die wordt gebruikt voor het installeren van AksHci. Met de opdracht maakt u een .kube-map en plaatst u het configuratiebestand erin. De opdracht mislukt echter met de volgende fout:

Error: open C:\Users\<user>\.kube\config: The system cannot find the path specified.

Om te reproduceren

  1. Installeer AksHci.
  2. Maak een doelcluster.
  3. Meld u als een andere beheerder aan bij de computer (functie voor meerdere beheerders).
  4. Voer Get-AksHciCredential -Name $clusterName uit.

Verwacht gedrag

Get-AksHciCredential moet een .kube-map kunnen maken in de basismap van de gebruiker en het configuratiebestand in die map plaatsen.

Als u het probleem wilt omzeilen, maakt u een .kube-map in de basismap van de gebruiker. Gebruik de volgende opdracht om de map te maken:

mkdir "$HOME/.kube"

Na deze stap Get-AksHciCredential mag het niet mislukken.

Fout 'Certificaat verlopen - Kan geen verbinding maken met de server: x509'

Het doelcluster is niet toegankelijk wanneer certificaten van het besturingsvlak niet kunnen worden vernieuwd. Wanneer u het cluster probeert te bereiken, wordt met de kubectl opdracht de volgende fout weergegeven:

certificate expired - Unable to connect to the server: x509: certificate has expired or is not yet valid: current time 2022-07-26T12:24:15-04:00 is after 2022-07-15T15:01:07Z

Notitie

Dit probleem is opgelost in de release van september 2022 en hoger.

Om te reproduceren

  1. Installeer AksHci.
  2. Doelcluster installeren. 3. Schakel het cluster (VM's) langer dan 4 dagen uit.
  3. Schakel het cluster opnieuw in.

Symptomen en risicobeperking

Het doelcluster is onbereikbaar. Elke kubectl opdracht die wordt uitgevoerd op het doelcluster, retourneert een foutbericht dat vergelijkbaar is met de volgende:

certificate expired - Unable to connect to the server: x509: certificate has expired or is not yet valid: current time 2022-07-26T12:24:15-04:00 is after 2022-07-15T15:01:07Z

Het probleem oplossen:

  1. Voer de volgende opdracht uit om het gegenereerde certificaat handmatig te vernieuwen:

    Update-AksHciClusterCertificates  -Name my-workload -cluster -fixKubeletCredentials
    
  2. Nieuwe referenties genereren:

    Get-AksHciCredential -name <clustername>
    

Probeer na enkele minuten de kubectl opdracht opnieuw om te zien of het cluster nu beschikbaar is.

Notitie

Er is een bekende fout in AksHci versie 1.0.14.x en eerder. Als de VM van het besturingsvlak een ander naampatroon heeft dan -control-plane-, werkt de Update-AksHciClusterCertificates opdracht mogelijk niet. U moet het certificaat bijwerken door u aan te melden bij de VM van het besturingsvlak:

  1. Zoek het IP-adres van de doelclusterbesturingsvlak-VM.
  2. Voer de volgende opdracht uit: ssh -i (get-mocconfig).sshPrivateKey clouduser@<ip>
  3. Vermeld de certificaat tattoo bestanden: sudo ls /etc/kubernetes/pki/cert-tattoo-*
  4. Genereer certificaten met elk bestand dat wordt vermeld met de vorige opdracht: sudo /usr/bin/cert-tattoo-provision CreateCertsWithAltNames <absolute-path-of-cert-tattoo-file>

Verificatiehanddruk is mislukt: x509: certificaat ondertekend door onbekende instantie

Deze fout kan optreden bij het implementeren van een nieuw AKS-cluster of het toevoegen van een knooppuntgroep aan een bestaand cluster.

  1. Controleer of de gebruiker die de opdracht heeft uitgevoerd, dezelfde gebruiker is die AKS op Azure Stack of Windows Server heeft geïnstalleerd. Zie Meerdere beheerders instellen voor meer informatie over het verlenen van toegang tot meerdere gebruikers.
  2. Als de gebruiker hetzelfde is en de fout zich blijft voordoen, volgt u de onderstaande stappen om het probleem op te lossen:
  • Verwijder het oude beheerapparaatcertificaat door te verwijderen $env:UserProfile.wssd\kvactl\cloudconfig.
  • Voer Repair-AksHciCerts uit.
  • Voer Get-AksHciCluster uit om te controleren of deze is opgelost.

Doelclusterpodlogboeken zijn niet toegankelijk - externe fout: tls: interne fout

De doelclusterlogboeken zijn niet toegankelijk. Wanneer u podlogboeken in het doelcluster probeert te openen, wordt de volgende TLS-fout weergegeven:

Error from server: Get "[https://10.0.0.0:10250/containerLogs/kube-system/kube-apiserver-moc-l9iv8xjn3av/kube-apiserver":](https://10.0.0.0:10250/containerLogs/kube-system/kube-apiserver-moc-l9iv8xjn3av/kube-apiserver%22:) remote error: tls: internal error

Notitie

Dit is een bekend probleem in AksHci versie 1.0.14.x en eerder. Deze is opgelost als onderdeel van de release 1.0.14.x (release van september en hoger). Doelclusters die zijn bijgewerkt naar deze versie, mogen dit probleem niet ondervinden.

Om te reproduceren

  1. Installeer AksHci.
  2. Installeer het doelcluster.
  3. Werk het cluster 60 dagen niet bij.
  4. Start het cluster opnieuw op.

Symptomen en risicobeperking

De doelpodlogboeken mogen niet toegankelijk zijn. Elke kubectl logboekopdracht die wordt uitgevoerd op het doelcluster, moet worden geretourneerd met een foutbericht dat er ongeveer als volgt uitziet:

Error from server: Get "[https://10.0.0.0:10250/containerLogs/kube-system/kube-apiserver-moc-l9iv8xjn3av/kube-apiserver":](https://10.0.0.0:10250/containerLogs/kube-system/kube-apiserver-moc-l9iv8xjn3av/kube-apiserver%22:) remote error: tls: internal error

Het probleem oplossen:

  1. Voer de volgende opdracht uit om het gegenereerde certificaat handmatig te vernieuwen:

    Update-AksHciClusterCertificates  -Name my-workload -fixKubeletCredentials
    
  2. Nieuwe referenties genereren:

    Get-AksHciCredential -name <clustername>
    

Clusterbesturingsvlak - certificaat verlopen - Kan geen verbinding maken met de server: x509

Het doelcluster is niet toegankelijk wanneer certificaten van het besturingsvlak niet kunnen worden vernieuwd. Wanneer u het cluster probeert te bereiken, genereert de kubectl opdracht de volgende fout:

certificate expired - Unable to connect to the server: x509: certificate has expired or is not yet valid: current time 2022-07-26T12:24:15-04:00 is after 2022-07-15T15:01:07Z

Notitie

Dit probleem is opgelost in de release van september 2022 en hoger.

Om te reproduceren

  1. Installeer AksHci.
  2. Installeer het doelcluster.
  3. Schakel cluster(vm's) langer dan 4 dagen uit.
  4. Schakel het cluster opnieuw in.

Symptomen en risicobeperking

Het doelcluster moet onbereikbaar zijn. Elke kubectl opdracht die wordt uitgevoerd op het doelcluster, moet worden geretourneerd met een foutbericht dat er ongeveer als volgt uitziet:

certificate expired - Unable to connect to the server: x509: certificate has expired or is not yet valid: current time 2022-07-26T12:24:15-04:00 is after 2022-07-15T15:01:07Z

Het probleem oplossen:

  1. Voer de volgende opdracht uit om het gegenereerde certificaat handmatig te vernieuwen:

    Update-AksHciClusterCertificates  -Name my-workload -cluster -fixKubeletCredentials
    
  2. Nieuwe referenties genereren:

    Get-AksHciCredential -name <clustername>
    

Probeer na enkele minuten de kubectl opdracht opnieuw om te zien of het cluster nu beschikbaar is.

KMS-pod mislukt en de KMS-podlogboeken bevatten fouten

Enkele mogelijke symptomen van dit probleem zijn:

  • kubectl get secrets mislukt met een interne fout.
  • kubectl logs <kmspod-name> -n kube-system bevat fouten.
  • Het koppelen van geheimen mislukt in volumes wanneer u pods probeert te maken.
  • De apiserver kan niet worden gestart.

Zoek in de KMS-podlogboeken op fouten door de volgende opdracht uit te voeren:

kubectl logs <kmspod-name> -n kube-system

Als de logboeken een fout retourneren met betrekking tot een ongeldig token in de KMS-pod van het beheercluster, voert u de volgende opdracht uit:

Update-AksHciCertificates

Als er een fout optreedt met betrekking tot een ongeldig token in de KMS-pod van het doelcluster, voert u de volgende opdracht uit:

UpdateAksHciClusterCertificates -name <cluster-name> -fixcloudcredential

Fout 'System.Collections.Hashtable.generic_non_zero 1 [Fout: Certificaat is verlopen: Verlopen]'

Het mocctl-certificaat verloopt als het gedurende meer dan 60 dagen niet wordt gebruikt. AKS Arc maakt gebruik van het mocctl opdrachtregelprogramma om te communiceren met MocStack voor het uitvoeren van moc-gerelateerde bewerkingen. Het certificaat dat door de mocclt opdracht wordt gebruikt om te communiceren met cloudagent verloopt over 60 dagen. Met mocctl de opdracht wordt het certificaat automatisch vernieuwd wanneer het wordt gebruikt dicht bij de vervaldatum (na ongeveer 42 dagen). Als de opdracht niet vaak wordt gebruikt, verloopt het certificaat.

Als u het gedrag wilt reproduceren, installeert u AKS Arc en wordt er gedurende 60 dagen geen bewerking uitgevoerd waarbij de mocctl opdracht wordt uitgevoerd.

Meld u opnieuw aan zodra het certificaat is verlopen om het probleem op te lossen. Voer de volgende PowerShell-opdracht uit om u aan te melden:

Repair-MocLogin

KVA-certificaat verwijderen als het na 60 dagen is verlopen

KVA-certificaat verloopt na 60 dagen als er geen upgrade wordt uitgevoerd.

Update-AksHci en elke opdracht die betrokken kvactl is, genereert de volgende fout.

Error: failed to get new provider: failed to create azurestackhci session: Certificate has expired: Expired

Als u deze fout wilt oplossen, verwijdert u het verlopen certificaatbestand op \kvactl\cloudconfig het knooppunt en probeert Update-AksHci u het opnieuw op het knooppunt met het verlopen van het certificaat. U kunt de volgende opdracht gebruiken:

$env:UserProfile.wssd\kvactl\cloudconfig

U vindt een discussie over het probleem bij KVA-certificaat moet worden verwijderd als het KVA-certificaat na 60 dagen is verlopen

Er zijn speciale Active Directory-machtigingen nodig voor lokale Azure-knooppunten die lid zijn van een domein

Gebruikers die Azure Kubernetes Service op Azure Local implementeren en configureren, moeten over de machtiging Volledig beheer beschikken om AD-objecten te maken in de Active Directory-container waarin de server- en serviceobjecten worden gemaakt.

De machtigingen van de gebruiker verhogen.

Uninstall-AksHciAdAuth mislukt met de fout [Error from server (NotFound): secrets "keytab-akshci-scale-reliability" niet gevonden]'

Als Uninstall-AksHciAdAuth deze fout weergeeft, moet u deze voorlopig negeren, omdat dit probleem wordt opgelost.

This issue will be fixed.

Kubectl-logboeken retourneren 'fout: u moet zijn aangemeld bij de server (de server heeft gevraagd om referenties op te geven)'

Er is een probleem met AKS Arc waarin een cluster kan stoppen met het retourneren van logboeken. Als dit gebeurt, retourneert de uitvoering kubectl logs <pod_name> 'fout: U moet zijn aangemeld bij de server (de server heeft de client gevraagd referenties op te geven)'. AKS Arc draait elke 4 dagen kerncertificaten van Kubernetes, maar soms laadt de Kubernetes-API-server het clientcertificaat niet onmiddellijk opnieuw voor communicatie met kubelet wanneer de certificaten worden bijgewerkt.

Er zijn verschillende opties om het probleem te verhelpen:

  • Opnieuw uitvoeren kubectl logs. Voer bijvoorbeeld de volgende PowerShell-opdracht uit:

    while (1) {kubectl logs <POD_NAME>; sleep 1}
    
  • Start de kube-apiserver container opnieuw op elk van de besturingsvlakken voor een cluster. Het opnieuw opstarten van de API-server heeft geen invloed op actieve workloads. Voer de volgende stappen uit om de API-server opnieuw op te starten:

    1. Haal de IP-adressen op voor elk besturingsvlak in uw cluster:

      kubectl get nodes -o wide
      
    2. Voer de volgende opdracht uit:

      ssh -i (get-akshciconfig).Moc.sshPrivateKey clouduser@<CONTROL_PLANE_IP> 'sudo crictl stop $(sudo crictl ps --name kube-apiserver -o json | jq -r .containers[0].id)'
      
  • Optioneel, maar niet aanbevolen voor productieworkloads, kunt u vragen kube-apiserver om het servercertificaat van de kubelet niet te verifiëren:

    kubectl logs <POD_NAME> --insecure-skip-tls-verify-backend=true