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ć
- Zainstaluj aplikację AksHci.
- Utwórz klaster docelowy.
- Zaloguj się na maszynie jako inny użytkownik administracyjny (funkcja wielu administratorów).
- 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ć
- Zainstaluj aplikację AksHci.
- Zainstaluj klaster docelowy. 3. Wyłącz klaster (maszyny wirtualne) przez ponad 4 dni.
- 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:
Uruchom następujące polecenie, aby ręcznie odnowić wygenerowany certyfikat:
Update-AksHciClusterCertificates -Name my-workload -cluster -fixKubeletCredentials
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:
- Znajdź adres IP docelowej maszyny wirtualnej płaszczyzny sterowania klastra.
- Uruchom następujące polecenie:
ssh -i (get-mocconfig).sshPrivateKey clouduser@<ip>
- Wyświetl listę plików tatuażu certyfikatu:
sudo ls /etc/kubernetes/pki/cert-tattoo-*
- 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.
- 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.
- 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\cloudconfig
element . - 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ć
- Zainstaluj aplikację AksHci.
- Zainstaluj klaster docelowy.
- Nie uaktualnij klastra przez 60 dni.
- 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:
Uruchom następujące polecenie, aby ręcznie odnowić wygenerowany certyfikat:
Update-AksHciClusterCertificates -Name my-workload -fixKubeletCredentials
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ć
- Zainstaluj aplikację AksHci.
- Zainstaluj klaster docelowy.
- Wyłącz klaster (maszyny wirtualne) przez więcej niż 4 dni.
- 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:
Uruchom następujące polecenie, aby ręcznie odnowić wygenerowany certyfikat:
Update-AksHciClusterCertificates -Name my-workload -cluster -fixKubeletCredentials
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:Pobierz adresy IP dla każdej płaszczyzny sterowania w klastrze:
kubectl get nodes -o wide
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