Åtgärda kända problem och fel med säkerhet och identitet i AKS Arc

PowerShell-cmdleten Get-AksHciCredential misslyckas när den körs av en annan administratörsanvändare än den som används för att installera AksHci. Kommandot skapar en .kube-katalog och placerar konfigurationsfilen i den. Kommandot misslyckas dock med följande fel:

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

Återskapa

1. Installera AksHci.
2. Skapa ett målkluster.
3. Logga in på datorn som en annan administratörsanvändare (funktion för flera administratörer).
4. Kör Get-AksHciCredential -Name $clusterName.

Förväntat beteende

Get-AksHciCredential ska kunna skapa en .kube-katalog i användarens hemkatalog och placera konfigurationsfilen i katalogen.

Du kan undvika problemet genom att skapa en .kube-katalog i användarens hemkatalog. Använd följande kommando för att skapa katalogen:

mkdir "$HOME/.kube"

Efter det här steget Get-AksHciCredential bör inte misslyckas.

Målklustret är inte tillgängligt när kontrollplanscertifikaten inte kan förnyas. När du försöker nå klustret kubectl visar kommandot följande fel:

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

Återskapa

1. Installera AksHci.
2. Installera målkluster. 3. Inaktivera klustret (virtuella datorer) i mer än 4 dagar.
3. Aktivera klustret igen.

Symtom och lindring

Målklustret kan inte nås. Alla kubectl kommandon som körs mot målklustret returnerar ett felmeddelande som liknar följande:

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

Så här åtgärdar du problemet:

1. Kör följande kommando för att förnya det genererade certifikatet manuellt:

   Update-AksHciClusterCertificates  -Name my-workload -cluster -fixKubeletCredentials
   

2. Generera nya autentiseringsuppgifter:

   Get-AksHciCredential -name <clustername>
   

Efter några minuter kan du prova kommandot kubectl igen för att se om klustret nu är tillgängligt.

Du kan se det här felet när du distribuerar ett nytt AKS-kluster eller lägger till en nodpool i ett befintligt kluster.

1. Kontrollera att användaren som har kört kommandot är samma användare som installerade AKS på Azure Stack eller Windows Server. Mer information om hur du beviljar åtkomst till flera användare finns i Konfigurera flera administratörer.
2. Om användaren är densamma och felet kvarstår följer du stegen nedan för att lösa problemet:

• Ta bort det gamla certifikatet för hanteringsinstallationen genom att ta bort $env:UserProfile.wssd\kvactl\cloudconfig.
• Kör Repair-AksHciCerts.
• Kör Get-AksHciCluster för att kontrollera att den är fast.

Målklusterloggarna är inte tillgängliga. När du försöker komma åt poddloggar i målklustret visas följande TLS-fel:

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

Återskapa

1. Installera AksHci.
2. Installera målklustret.
3. Uppgradera inte klustret på 60 dagar.
4. Starta om klustret.

Symtom och lindring

Målpoddloggarna bör inte vara tillgängliga. Alla kubectl loggkommandon som körs mot målklustret bör returneras med ett felmeddelande som liknar följande:

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

Så här åtgärdar du problemet:

1. Kör följande kommando för att förnya det genererade certifikatet manuellt:

   Update-AksHciClusterCertificates  -Name my-workload -fixKubeletCredentials
   

2. Generera nya autentiseringsuppgifter:

   Get-AksHciCredential -name <clustername>
   

Målklustret är inte tillgängligt när kontrollplanscertifikaten inte kan förnyas. När du försöker nå klustret kubectl genererar kommandot följande fel:

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

Återskapa

1. Installera AksHci.
2. Installera målklustret.
3. Inaktivera kluster (vms) i mer än 4 dagar.
4. Aktivera klustret igen.

Symtom och lindring

Målklustret ska inte kunna nås. Alla kubectl kommandon som körs mot målklustret bör returneras med ett felmeddelande som liknar följande:

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

Så här åtgärdar du problemet:

1. Kör följande kommando för att förnya det genererade certifikatet manuellt:

   Update-AksHciClusterCertificates  -Name my-workload -cluster -fixKubeletCredentials
   

2. Generera nya autentiseringsuppgifter:

   Get-AksHciCredential -name <clustername>
   

Efter några minuter kan du prova kommandot kubectl igen för att se om klustret nu är tillgängligt.

Några möjliga symptom på det här problemet är:

• kubectl get secrets misslyckas med ett internt fel.
• kubectl logs <kmspod-name> -n kube-system innehåller fel.
• Det går inte att montera hemligheter i volymer när du försöker skapa poddar.
• Det går inte att starta apiservern.

Leta efter fel i KMS-poddloggarna genom att köra följande kommando:

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

Om loggarna returnerar ett fel om en ogiltig token i hanteringsklustrets KMS-podd kör du följande kommando:

Update-AksHciCertificates

Om det finns ett fel om en ogiltig token i KMS-målklustrets podd kör du följande kommando:

UpdateAksHciClusterCertificates -name <cluster-name> -fixcloudcredential

Mocctl-certifikatet upphör att gälla om det inte används på mer än 60 dagar. AKS Arc använder mocctl kommandoradsverktyget för att kommunicera med MocStack för att utföra Moc-relaterade åtgärder. Certifikatet som mocclt kommandot använder för att kommunicera med cloudagent upphör att gälla om 60 dagar. Kommandot mocctl förnyar certifikatet automatiskt när det används nära förfallodatumet (efter ~42 dagar). Om kommandot inte används ofta upphör certifikatet att gälla.

Om du vill återskapa beteendet installerar du AKS Arc och ingen åtgärd som involverar mocctl kommandot utförs i 60 dagar.

Du kan åtgärda problemet genom att logga in igen när certifikatet upphör att gälla. Kör följande PowerShell-kommando för att logga in:

Repair-MocLogin

KVA-certifikatet upphör att gälla efter 60 dagar om ingen uppgradering utförs.

Update-AksHci och alla kommandon som involverar kvactl utlöser följande fel.

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

Lös det här felet genom att ta bort certifikatfilen som har upphört att gälla vid \kvactl\cloudconfig och försök Update-AksHci igen på noden som ser problemet med certifikatets förfallodatum. Du kan använda följande kommando:

$env:UserProfile.wssd\kvactl\cloudconfig

Du hittar en diskussion om problemet på KVA-certifikatet måste tas bort om KVA-certifikatet upphör att gälla efter 60 dagar

Användare som distribuerar och konfigurerar Azure Kubernetes Service på Azure Local måste ha fullständig behörighet att skapa AD-objekt i Active Directory-containern som servern och tjänstobjekten skapas i.

Öka användarens behörigheter.

Om Uninstall-AksHciAdAuth visar det här felet bör du ignorera det för tillfället eftersom det här problemet kommer att åtgärdas.

This issue will be fixed.

Det finns ett problem med AKS Arc där ett kluster kan sluta returnera loggar. När detta inträffar returnerar körningen kubectl logs <pod_name> "error: You must be logged in to the server (the server has asked for the client to provide credentials)". AKS Arc roterar kubernetes-kärncertifikat var fjärde dag, men ibland läser Kubernetes API-servern inte omedelbart in sitt klientcertifikat för kommunikation med kubelet när certifikaten uppdateras.

Det finns flera alternativ för att åtgärda problemet:

• kubectl logsKör om . Kör till exempel följande PowerShell-kommando:

  while (1) {kubectl logs <POD_NAME>; sleep 1}
  

• Starta om containern kube-apiserver på vart och ett av kontrollplanerna för ett kluster. Omstart av API-servern påverkar inte körning av arbetsbelastningar. Så här startar du om API-servern:

  1. Hämta IP-adresserna för varje kontrollplan i klustret:

     kubectl get nodes -o wide
     

  2. Kör följande kommando:

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

• Alternativt, men rekommenderas inte för produktionsarbetsbelastningar, kan du be att kube-apiserver inte verifiera servercertifikatet för kubelet:

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

Nästa steg

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