Rozwiązywanie znanych problemów i błędów związanych z zabezpieczeniami i tożsamościami w usłudze AKS Arc

Ten temat ułatwia rozwiązywanie problemów z zabezpieczeniami i tożsamościami w usłudze AKS Arc.

Polecenie Get-AksHciCredential kończy się niepowodzeniem z powodu błędu "nie można odnaleźć określonej ścieżki"

Polecenie Get-AksHciCredential cmdlet programu PowerShell kończy się niepowodzeniem po wykonaniu przez innego użytkownika administratora niż to, które zostało użyte do zainstalowania usługi AksHci. Polecenie tworzy katalog .kube i umieszcza w nim plik konfiguracji. Jednak polecenie kończy się niepowodzeniem z powodu następującego błędu:

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

Aby odtworzyć

  1. Zainstaluj aplikację AksHci.
  2. Utwórz klaster docelowy.
  3. Zaloguj się na maszynie jako inny użytkownik administracyjny (funkcja wielu administratorów).
  4. Uruchom program Get-AksHciCredential -Name $clusterName.

Oczekiwane zachowanie

Get-AksHciCredential Powinien być w stanie utworzyć katalog .kube w katalogu głównym użytkownika i umieścić plik konfiguracji w tym katalogu.

Aby obejść ten problem, utwórz katalog .kube w katalogu głównym użytkownika. Użyj następującego polecenia, aby utworzyć katalog:

mkdir "$HOME/.kube"

Po wykonaniu tego kroku Get-AksHciCredential nie powinno zakończyć się niepowodzeniem.

Błąd "Certyfikat wygasł — nie można nawiązać połączenia z serwerem: x509"

Klaster docelowy jest niedostępny, gdy nie można odnowić certyfikatów płaszczyzny sterowania. Podczas próby dotarcia do klastra kubectl polecenie wyświetla następujący błąd:

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

Uwaga

Ten problem został rozwiązany w wersji z września 2022 r. i nowszej.

Aby odtworzyć

  1. Zainstaluj aplikację AksHci.
  2. Zainstaluj klaster docelowy. 3. Wyłącz klaster (maszyny wirtualne) przez ponad 4 dni.
  3. Ponownie włącz klaster.

Objawy i środki zaradcze

Klaster docelowy jest niemożliwy do osiągnięcia. Każde kubectl polecenie uruchamiane względem klastra docelowego zwraca komunikat o błędzie podobny do następującego:

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

Aby rozwiązać ten problem:

  1. Uruchom następujące polecenie, aby ręcznie odnowić wygenerowany certyfikat:

    Update-AksHciClusterCertificates  -Name my-workload -cluster -fixKubeletCredentials
    
  2. Generowanie nowych poświadczeń:

    Get-AksHciCredential -name <clustername>
    

Po kilku minutach spróbuj ponownie wykonać kubectl polecenie, aby sprawdzić, czy klaster jest teraz dostępny.

Uwaga

Istnieje znana usterka w usłudze AksHci w wersji 1.0.14.x i starszych. Jeśli maszyna wirtualna płaszczyzny sterowania ma wzorzec nazwy innej niż -control-plane-, Update-AksHciClusterCertificates polecenie może nie działać. Certyfikat należy zaktualizować, logując się do maszyny wirtualnej płaszczyzny sterowania:

  1. Znajdź adres IP docelowej maszyny wirtualnej płaszczyzny sterowania klastra.
  2. Uruchom następujące polecenie: ssh -i (get-mocconfig).sshPrivateKey clouduser@<ip>
  3. Wyświetl listę plików tatuażu certyfikatu: sudo ls /etc/kubernetes/pki/cert-tattoo-*
  4. Wygeneruj certyfikaty przy użyciu każdego pliku wymienionego w poprzednim poleceniu: sudo /usr/bin/cert-tattoo-provision CreateCertsWithAltNames <absolute-path-of-cert-tattoo-file>

Uzgadnianie uwierzytelniania nie powiodło się: x509: certyfikat podpisany przez nieznany urząd

Ten błąd może wystąpić podczas wdrażania nowego klastra usługi AKS lub dodawania puli węzłów do istniejącego klastra.

  1. Sprawdź, czy użytkownik, który uruchamia polecenie, jest tym samym użytkownikiem, który zainstalował usługę AKS w usłudze Azure Stack lub Windows Server. Aby uzyskać więcej informacji na temat udzielania dostępu wielu użytkownikom, zobacz Konfigurowanie wielu administratorów.
  2. Jeśli użytkownik jest taki sam, a błąd będzie się powtarzać, wykonaj poniższe kroki, aby rozwiązać ten problem:
  • Usuń stary certyfikat urządzenia zarządzania, usuwając $env:UserProfile.wssd\kvactl\cloudconfigelement .
  • Uruchom program Repair-AksHciCerts.
  • Uruchom polecenie , Get-AksHciCluster aby sprawdzić, czy jest on naprawiony.

Dzienniki zasobników klastra docelowego są niedostępne — błąd zdalny: tls: błąd wewnętrzny

Dzienniki klastra docelowego nie są dostępne. Podczas próby uzyskania dostępu do dzienników zasobników w klastrze docelowym zostanie wyświetlony następujący błąd PROTOKOŁU TLS:

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

Uwaga

Jest to znany problem w usłudze AksHci w wersji 1.0.14.x i starszych. Jest to naprawione w ramach wersji 1.0.14.x (wersja z września i nowsze). Klastry docelowe zaktualizowane do tej wersji nie powinny napotkać tego problemu.

Aby odtworzyć

  1. Zainstaluj aplikację AksHci.
  2. Zainstaluj klaster docelowy.
  3. Nie uaktualnij klastra przez 60 dni.
  4. Uruchom ponownie klaster.

Objawy i środki zaradcze

Dzienniki zasobnika docelowego nie powinny być dostępne. Każde kubectl polecenie dziennika uruchomione względem klastra docelowego powinno zwrócić komunikat o błędzie podobny do następującego:

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

Aby rozwiązać ten problem:

  1. Uruchom następujące polecenie, aby ręcznie odnowić wygenerowany certyfikat:

    Update-AksHciClusterCertificates  -Name my-workload -fixKubeletCredentials
    
  2. Generowanie nowych poświadczeń:

    Get-AksHciCredential -name <clustername>
    

Plan sterowania klastrem — wygasł certyfikat — nie można nawiązać połączenia z serwerem: x509

Klaster docelowy jest niedostępny, gdy nie można odnowić certyfikatów płaszczyzny sterowania. Podczas próby uzyskania dostępu do klastra kubectl polecenie generuje następujący błąd:

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

Uwaga

Ten problem został rozwiązany w wersji z września 2022 r. i nowszej.

Aby odtworzyć

  1. Zainstaluj aplikację AksHci.
  2. Zainstaluj klaster docelowy.
  3. Wyłącz klaster (maszyny wirtualne) przez więcej niż 4 dni.
  4. Ponownie włącz klaster.

Objawy i środki zaradcze

Klaster docelowy powinien być niedostępny. Każde kubectl polecenie uruchamiane względem klastra docelowego powinno zwrócić komunikat o błędzie podobny do następującego:

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

Aby rozwiązać ten problem:

  1. Uruchom następujące polecenie, aby ręcznie odnowić wygenerowany certyfikat:

    Update-AksHciClusterCertificates  -Name my-workload -cluster -fixKubeletCredentials
    
  2. Generowanie nowych poświadczeń:

    Get-AksHciCredential -name <clustername>
    

Po kilku minutach spróbuj ponownie wykonać kubectl polecenie, aby sprawdzić, czy klaster jest teraz dostępny.

Zasobnik usługi KMS kończy się niepowodzeniem, a dzienniki zasobnika usługi KMS zawierają błędy

Oto niektóre możliwe objawy tego problemu:

  • kubectl get secrets kończy się niepowodzeniem z powodu błędu wewnętrznego.
  • kubectl logs <kmspod-name> -n kube-system zawiera błędy.
  • Instalowanie wpisów tajnych kończy się niepowodzeniem w woluminach podczas próby utworzenia zasobników.
  • Nie można uruchomić serwera apiserver.

Przejrzyj dzienniki zasobnika usługi KMS pod kątem błędów, uruchamiając następujące polecenie:

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

Jeśli dzienniki zwracają błąd dotyczący nieprawidłowego tokenu w zasobniku usługi KMS klastra zarządzania, uruchom następujące polecenie:

Update-AksHciCertificates

Jeśli wystąpi błąd dotyczący nieprawidłowego tokenu w zasobniku usługi KMS klastra docelowego, uruchom następujące polecenie:

UpdateAksHciClusterCertificates -name <cluster-name> -fixcloudcredential

Błąd "System.Collections.Hashtable.generic_non_zero 1 [Błąd: certyfikat wygasł: wygasł]"

Certyfikat makiety wygasa, jeśli nie jest używany przez więcej niż 60 dni. Usługa AKS Arc używa mocctl narzędzia wiersza polecenia do komunikowania się z platformą MocStack na potrzeby wykonywania operacji związanych z mocą. Certyfikat używany mocclt przez polecenie do komunikowania się z agentem cloudagent wygasa w ciągu 60 dni. Polecenie mocctl odnawia certyfikat automatycznie, gdy jest używany w pobliżu jego wygaśnięcia (po ok. 42 dniach). Jeśli polecenie nie jest często używane, certyfikat wygasa.

Aby odtworzyć zachowanie, zainstaluj usługę AKS Arc i nie wykonano żadnej operacji obejmującej mocctl polecenie przez 60 dni.

Aby rozwiązać ten problem, zaloguj się ponownie po wygaśnięciu certyfikatu. Wykonaj następujące polecenie programu PowerShell, aby się zalogować:

Repair-MocLogin

Usuwanie certyfikatu KVA, jeśli wygasł po upływie 60 dni

Certyfikat KVA wygasa po upływie 60 dni, jeśli nie wykonano uaktualnienia.

Update-AksHci i każde polecenie z udziałem kvactl spowoduje zgłoszenie następującego błędu.

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

Aby rozwiązać ten błąd, usuń wygasły plik certyfikatu pod \kvactl\cloudconfig adresem i spróbuj Update-AksHci ponownie w węźle, widząc problem z wygaśnięciem certyfikatu. Możesz użyć następującego polecenia:

$env:UserProfile.wssd\kvactl\cloudconfig

Dyskusję na temat problemu można znaleźć na stronie Certyfikat KVA należy usunąć, jeśli certyfikat KVA wygasł po upływie 60 dni

Specjalne uprawnienia usługi Active Directory są wymagane w przypadku przyłączonych do domeny węzłów lokalnych platformy Azure

Użytkownicy wdrażający i konfigurujący usługę Azure Kubernetes Service na platformie Azure lokalnie muszą mieć uprawnienie Pełna kontrola do tworzenia obiektów usługi AD w kontenerze usługi Active Directory, w których są tworzone obiekty serwera i usługi.

Podnieś poziom uprawnień użytkownika.

Uninstall-AksHciAdAuth kończy się niepowodzeniem z powodu błędu "[Błąd z serwera (NotFound): wpisy tajne "keytab-akshci-scale-reliability" nie znaleziono]"

Jeśli uwierzytelnianie Uninstall-AksHciAdAuth wyświetla ten błąd, należy go zignorować na razie, ponieważ ten problem zostanie rozwiązany.

This issue will be fixed.

Dzienniki kubectl zwracają komunikat "błąd: musisz zalogować się na serwerze (serwer poprosił klienta o podanie poświadczeń)"

Wystąpił problem z usługą AKS Arc, w której klaster może przestać zwracać dzienniki. W takim przypadku uruchomienie kubectl logs <pod_name> zwraca komunikat "błąd: musisz zalogować się na serwerze (serwer poprosił klienta o podanie poświadczeń)". Usługa AKS Arc obraca podstawowe certyfikaty Kubernetes co 4 dni, ale czasami serwer interfejsu API Kubernetes nie natychmiast ponownie ładuje certyfikatu klienta na potrzeby komunikacji z rozwiązaniem kubelet podczas aktualizacji certyfikatów.

Aby rozwiązać ten problem, istnieje kilka opcji:

  • Uruchom ponownie polecenie kubectl logs. Na przykład uruchom następujące polecenie programu PowerShell:

    while (1) {kubectl logs <POD_NAME>; sleep 1}
    
  • kube-apiserver Uruchom ponownie kontener na każdej płaszczyźnie sterowania dla klastra. Ponowne uruchomienie serwera interfejsu API nie ma wpływu na uruchomione obciążenia. Aby ponownie uruchomić serwer interfejsu API, wykonaj następujące kroki:

    1. Pobierz adresy IP dla każdej płaszczyzny sterowania w klastrze:

      kubectl get nodes -o wide
      
    2. Uruchom następujące polecenie:

      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)'
      
  • Opcjonalnie, ale nie jest to zalecane w przypadku obciążeń produkcyjnych, możesz poprosić o kube-apiserver nie zweryfikowanie certyfikatu serwera narzędzia kubelet:

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