Typowe problemy podczas korzystania z Azure Kubernetes Service on Azure Stack HCI

W tym artykule opisano niektóre znane problemy z Azure Kubernetes Service on Azure Stack HCI. Możesz również przejrzeć znane problemy z centrum Windows administracyjnego oraz problemy z instalacją i błędy.

KontenerD nie może ściągnąć obrazu wstrzymania, ponieważ kubelet przez pomyłkę zbiera obraz

Gdy kubelet znajduje się pod nacięciem dysku, zbiera nieużywane obrazy kontenerów, które mogą zawierać obrazy wstrzymania, a w takim przypadku kontener ContainerD nie może ściągnąć obrazu.

Obecnie usługi AKS na platformie Azure Stack HCI używa Azure Container Registry (ACR) tylko z wyłączonym uwierzytelnianiem jako obejście usterki usługi ACR. W związku z tym te same poświadczenia wysłane do klientów mogą służyć do ściągania obrazów wstrzymania na węzłach, których dotyczy problem, na przykład nazwa użytkownika: 1516df5a-f1cc-4a6a-856c-03d127b02d05, hasło: 92684690-48b5-4dce-856d-ef4cccb54f22.

Aby rozwiązać ten problem, uruchom następujące kroki:

  1. Połączenie do węzła, którego dotyczy problem, przy użyciu polecenia SSH i uruchom następujące polecenie:

    sudo su
    
  2. Aby ściągnąć obraz, uruchom następujące polecenie:

    crictl pull --creds aaa:bbb ecpacr.azurecr.io/pause:3.2
    

Uruchomienie Remove-AksHciCluster powoduje błąd: Nie znaleziono klastra obciążenia o nazwie "my-workload-cluster"

Jeśli wystąpi ten błąd podczas uruchamiania remove-AksHciCluster,należy sprawdzić, czy do usunięcia klastra zostały użyte poprawne informacje.

Uruchomienie Remove-AksHciCluster powoduje błąd: Błąd: nie można usunąć grupy clustergroup-spdb:...

Podczas uruchamiania remove-AksHciCluster,następujący błąd występuje, ponieważ może wystąpić zakleszczenie:

Błąd: nie można usunąć grupy clustergroup-spdb: nie można usunąć grupy clustergroup-spdb: błąd rpc: code = DeadlineExceeded desc = przekroczono termin kontekstu

Aby rozwiązać ten problem, uruchom ponownie usługę CloudAgent.

W klastrze obciążenia ze statycznym adresem IP wszystkie zasobniki w węźle są zablokowane w stanie ContainerCreating

W klastrze obciążeń ze statycznym adresem IP Windows węzłami wszystkie zasobniki w węźle (w tym zasobniki) są zablokowane w daemonset stanie daemonset Próba nawiązania połączenia z tym węzłem przy użyciu połączenia SSH kończy się niepowodzeniem z błędem Przekierowanie połączenia.

Aby rozwiązać ten problem, użyj Menedżera funkcji Hyper-V lub Menedżer klastra trybu failover, aby wyłączyć maszynę wirtualną tego węzła. Po pięciu do dziesięciu minutach węzeł powinien zostać ponownie utworzony i wszystkie uruchomione zasobniki.

Podczas uruchamiania aplikacji jest wyświetlany błąd Nie można uzyskać Set-AksHciRegistration

Błąd Nie można uzyskać tokenu może wystąpić, jeśli masz wiele dzierżaw na koncie platformy Azure. Użyj $tenantId = (Get-AzContext).Tenant.Id , aby ustawić odpowiednią dzierżawę. Następnie dołącz tę dzierżawę jako parametr podczas uruchamiania parametru Set-AksHciRegistration.

Maszyny wirtualne Windows i Linux nie zostały skonfigurowane jako maszyny wirtualne o wysokiej dostępie podczas skalowania klastra obciążenia

Podczas skalowania klastra obciążeń odpowiednie maszyny wirtualne z systemami Linux i Windows zostały dodane jako węzły procesu roboczego, ale nie zostały skonfigurowane jako maszyny wirtualne o wysokiej dostępie. Podczas uruchamiania polecenia Get-ClusterGroup nowo utworzona maszyna wirtualna z systemem Linux nie została skonfigurowana jako grupa klastrów.

Jest to znany problem. Po ponownym uruchomieniu możliwość skonfigurowania maszyn wirtualnych jako maszyn wirtualnych o wysokiej dostępie jest czasami tracona. Bieżące obejście to ponowne uruchomienie wssdagent w każdym z Azure Stack HCI węzłów. Należy pamiętać, że działa to tylko w przypadku nowych maszyn wirtualnych generowanych przez tworzenie pul węzłów podczas wykonywania operacji skalowania w górę lub podczas tworzenia nowych klastrów Kubernetes po ponownym uruchomieniu klastra w wssdagent węzłach. Należy jednak ręcznie dodać istniejące maszyny wirtualne do klastra trybu failover.

Podczas skalowania klastra w dół zasoby klastra o wysokiej dostępności są w stanie awarii, gdy maszyny wirtualne są usuwane. Obejście tego problemu to ręczne usunięcie zasobów, które zakończyły się niepowodzeniem.

Próba utworzenia nowych klastrów obciążeń nie powiodła się, ponieważ host usługi AKS został wyłączony na kilka dni

Usługa AKS w klastrze Azure Stack HCI wdrożonym na maszynie wirtualnej platformy Azure wcześniej działała prawidłowo, ale po kilku dniach wyłączenia hosta usługi AKS polecenie Kubectl nie działało. Po uruchomieniu polecenia lub pojawił się ten komunikat o błędzie: Błąd z serwera Kubectl get nodesKubectl get servicesKubectl get nodesbłąd na serwerze ("") uniemożliwił powodzenie żądania .

Ten problem wystąpił, ponieważ host usługi AKS był wyłączony na dłużej niż cztery dni, co spowodowało wygaśnięcie certyfikatów. Certyfikaty są często obracane w cyklu czterodniowym. Uruchom plik Repair-AksHciClusterCerts, aby rozwiązać problem z wygaśnięciem certyfikatu.

Get-AksHCIClusterNetwork nie pokazuje bieżącej alokacji adresów IP

Uruchomienie polecenia Get-AksHciClusterNetwork zawiera listę wszystkich konfiguracji sieci wirtualnej. Jednak polecenie nie pokazuje bieżącej alokacji adresów IP. Aby dowiedzieć się, jakie adresy IP są obecnie wykorzystywane w sieci wirtualnej, należy wykonać poniższe kroki:

  1. Aby uzyskać grupę, uruchom następujące polecenie:

    Get-MocGroup -location MocLocation
    
  2. Aby uzyskać listę adresów IP, które są obecnie używane, oraz listę dostępnych lub używanych wirtualnych adresów IP, uruchom następujące polecenie:

    Get-MocNetworkInterface -Group <groupName> | ConvertTo-Json -depth 10
    
  3. Użyj następującego polecenia, aby wyświetlić listę wirtualnych adresów IP, które są obecnie w użyciu:

    Get-MocLoadBalancer -Group <groupName> | ConvertTo-Json -depth 10
    

Serwer interfejsu API nie odpowiada po kilku dniach

Podczas próby wykonania usługi AKS w Azure Stack HCI wdrożenia po kilku dniach program nie Kubectl wykonywał żadnych poleceń. Dziennik usługa zarządzania kluczami (KMS) zawiera komunikat o błędzie rpc error:code = Unauthenticated desc = Valid Token Required. Po uruchomieniu repair-AksHciCerts, aby spróbować rozwiązać ten problem, pojawił się inny błąd: nie można naprawić certyfikatów klastra.

Polecenie Repair-AksHciCerts cmdlet kończy się niepowodzeniem, jeśli serwer interfejsu API nie działa. Jeśli usługi AKS w Azure Stack HCI nie uaktualniono przez co najmniej 60 dni, próba ponownego uruchomienia wtyczki usługi KMS nie zostanie uruchomiona. Ten błąd powoduje również niepowodzenie serwera interfejsu API.

Aby rozwiązać ten problem, należy ręcznie obrócić token, a następnie ponownie uruchomić KMS i kontener, aby utworzyć kopię zapasową serwera interfejsu API. W tym celu uruchom następujące kroki:

  1. Obróć token, uruchamiając następujące polecenie:

    $ mocctl.exe security identity rotate --name "KMSPlugin-<cluster-name>-moc-kms-plugin" --encode=false --cloudFqdn (Get-AksHciConfig).Moc.cloudfqdn > cloudlogin.yaml
    
  2. Skopiuj token na maszynę wirtualną przy użyciu następującego polecenia. Ustawienie ip w poniższym poleceniu odnosi się do adresu IP płaszczyzny sterowania hosta usługi AKS.

    $ 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. Uruchom ponownie KMS i kontener.

    Aby uzyskać identyfikator kontenera, uruchom następujące polecenie:

    $ ssh -i (Get-AksHciConfig).Moc.sshPrivateKey clouduser@<ip> "sudo docker container ls | grep 'kms'"
    

    Dane wyjściowe powinny mieć następujące pola:

    CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
    

    Dane wyjściowe powinny wyglądać podobnie do tego przykładu:

    4169c10c9712 f111078dbbe1 "/kms-plugin" 22 minutes ago Up 22 minutes k8s_kms-plugin_kms-plugin-moc-lll6bm1plaa_kube-system_d4544572743e024431874e6ba7a9203b_1
    
  4. Na koniec uruchom ponownie kontener, uruchamiając następujące polecenie:

    $ ssh -i (Get-AksHciConfig).Moc.sshPrivateKey clouduser@<ip> "sudo docker container kill <Container ID>"
    

Konfigurowanie trwałych oświadczeń woluminu powoduje błąd: Nie można zainicjować agenta. Błąd: mkdir /var/log/agent: odmowa uprawnień

Błąd odmowy uprawnień, Nie można zainicjować agenta. Błąd: mkdir /var/log/agent: odmowa uprawnień wskazuje, że domyślna klasa magazynu może nie być odpowiednia dla Twoich obciążeń i występuje w obciążeniach systemu Linux uruchomionych na platformie Kubernetes w wersji 1.19.x lub nowszej. Zgodnie z najlepszymi rozwiązaniami w zakresie zabezpieczeń wiele obciążeń systemu Linux securityContext fsGroup określa ustawienie zasobnika. Obciążenia nie mogą uruchomić się w u usługach AKS na platformie Azure Stack HCI, ponieważ domyślna klasa magazynu nie określa parametru, dlatego kubernetes nie może zmienić własności plików i trwałych woluminów na podstawie żądanego przez fstype (=ext4)fsGroup obciążenie.

Aby rozwiązać ten problem, zdefiniuj niestandardową klasę magazynu, za pomocą których można aprowizować komputery PVC.

Podczas tworzenia woluminu trwałego próba instalacji woluminu kończy się niepowodzeniem

Po usunięciu woluminu trwałego lub trwałego oświadczenia woluminu w użytce AKS w Azure Stack HCI jest tworzony nowy wolumin trwały w celu mapowania na ten sam udział. Jednak podczas próby instalacji woluminu próba instalacji kończy się niepowodzeniem, a zasobnik kończy się niepowodzeniem z powodu błędu NewSmbGlobalMapping.

Aby ominąć niepowodzenie instalacji nowego woluminu, możesz na przykład na Windows SSH uruchomić i udostępnić udział odpowiadający Remove-SMBGlobalMapping woluminowi. Po uruchomieniu tego polecenia program spróbuje zainstalować wolumin.

Pomyślne uruchomienie agenta chmury może zakończyć się niepowodzeniem w przypadku używania nazw ścieżek ze spacjami

W przypadku użycia polecenia Set-AksHciConfig do określenia parametrów , , lub z nazwą ścieżki, która zawiera znak spacji, takiej jak , uruchomienie usługi klastra agenta chmury nie powiedzie się z następującym (lub podobnym) komunikatem o -workingDir-cloudConfigLocation-nodeConfigLocationD:\Cloud Share\AKS HCI błędzie:

Failed to start the cloud agent generic cluster service in failover cluster. The cluster resource group os in the 'failed' state. Resources in 'failed' or 'pending' states: 'MOC Cloud Agent Service'

Obejście: Użyj ścieżki, która nie zawiera spacji, na przykład C:\CloudShare\AKS-HCI .

Serwer proxy sieci blokuje żądania HTTP

Podczas stosowania konfiguracji platformy serwer proxy sieci zablokował żądania HTTP pochodzące z ciągu agenta użytkownika Google Chrome 65, ponieważ ten ciąg jest aktualnym klientem agenta użytkownika.

Agent użytkownika zostanie zaktualizowany do programu Google Chrome 91 w następnej wersji.

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

Jeśli w oknie Uninstall-AksHciAdAuth jest wyświetlany błąd [Błąd z serwera (NotFound): nie znaleziono wpisów tajnych "keytab-akshci-scale-reliability"]. Na razie należy zignorować ten błąd, ponieważ ten problem zostanie rozwiązany.

Uninstall-AksHCI nie czyści zasobów klastra ( ownergroup ca-<GUID> )

Z powodu niewystarczających uprawnień w usłudze Active Directory program Uninstall-AksHci nie mógł usunąć obiektów zasobów klastra w usłudze Active Directory, co może prowadzić do błędów w kolejnych wdrożeniach. Aby rozwiązać ten problem, upewnij się, że użytkownik wykonujący instalację ma uprawnienia Pełna kontrola do tworzenia/modyfikowania/usuwania obiektów usługi Active Directory w kontenerze usługi Active Directory, w którym są tworzone obiekty serwera i usługi.

Błąd występuje, gdy Uninstall-AksHci i AKS na Azure Stack HCI nie jest zainstalowana

Jeśli po uruchomieniu programu Uninstall-AksHci usługa AKS na platformie Azure Stack HCI nie jest zainstalowana, zostanie wyświetlony komunikat o błędzie: Nie można powiązać argumentu z parametrem "Path",ponieważ ma on wartość null . Komunikat o błędzie można bezpiecznie zignorować, ponieważ nie ma żadnego wpływu na funkcjonalność.

Tworzenie klastra obciążenia z obsługą usługi Arc powoduje błąd Nie można indeksować do tablicy o wartości null

Błąd Nie można indeksować do tablicy o wartości null pojawia się podczas przechodzenia z programu PowerShell do Windows Administracyjnego w celu utworzenia klastra obciążenia z obsługą usługi Arc. Możesz bezpiecznie zignorować ten błąd, ponieważ jest on częścią kroku weryfikacji i klaster został już utworzony.

Set-AksHciConfig kończy się niepowodzeniem z błędami usługi WinRM, ale pokazuje, że usługę WinRM skonfigurowano poprawnie

Podczas uruchamiania pliku Set-AksHciConfigmoże wystąpić następujący błąd:

WinRM service is already running on this machine.
WinRM is already set up for remote management on this computer.
Powershell remoting to TK5-3WP08R0733 was not successful.
At C:\Program Files\WindowsPowerShell\Modules\Moc\0.2.23\Moc.psm1:2957 char:17
+ ...             throw "Powershell remoting to "+$env:computername+" was n ...
+                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : OperationStopped: (Powershell remo...not successful.:String) [], RuntimeException
    + FullyQualifiedErrorId : Powershell remoting to TK5-3WP08R0733 was not successful.

W większości przypadków ten błąd występuje w wyniku zmiany tokenu zabezpieczającego użytkownika (ze względu na zmianę członkostwa w grupie), zmiany hasła lub wygaśnięcia hasła. W większości przypadków problem można rozwiązać, wylogując się z komputera i logując się ponownie. Jeśli to nadal nie powiedzie się, możesz złożyć problem na stronie GitHub AKS HCI.

W przypadku usuwania węzła przy użyciu narzędzia kubectl skojarzona maszyna wirtualna może nie zostać usunięta

Ten problem zostanie wyświetlony, jeśli wykonaj następujące kroki:

  1. Utwórz klaster Kubernetes.

  2. Przeskalij klaster do więcej niż dwóch węzłów.

  3. Usuń węzeł, uruchamiając następujące polecenie:

    kubectl delete node <node-name>
    
  4. Zwróć listę węzłów, uruchamiając następujące polecenie:

    kubectl get nodes
    

    Usunięty węzeł nie jest wymieniony w danych wyjściowych.

  5. Otwórz program PowerShell z uprawnieniami administracyjnymi i uruchom następujące polecenie:

    get-vm
    

Usunięty węzeł jest nadal na liście.

Ten błąd powoduje, że system nie rozpoznaje, że brakuje węzła, i w związku z tym nowy węzeł nie zostanie rozkręcany.

Nie znaleziono klastra obciążenia

Klaster obciążeń może nie zostać znaleziony, jeśli pule adresów IP dwóch usług AKS Azure Stack HCI wdrożeniach są takie same lub nakładają się na siebie. Jeśli wdrożysz dwa hosty usługi AKS i użyjemy tej samej konfiguracji dla obu tych hostów, program PowerShell i centrum administracyjne programu Windows potencjalnie nie znajdą klastra obciążenia, ponieważ serwer interfejsu API zostanie przypisany ten sam adres IP w obu klastrach, co spowoduje AksHciNetworkSetting konflikt.

Wyświetlony komunikat o błędzie będzie wyglądać podobnie do przedstawionego poniżej przykładu.

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.

Uwaga

Nazwa klastra będzie inna.

Menedżer funkcji Hyper-V pokazuje wysokie zapotrzebowanie na procesor CPU i/lub pamięć dla klastra zarządzania

Podczas sprawdzania menedżera funkcji Hyper-V wysokie zapotrzebowanie na procesor i pamięć dla klastra zarządzania można bezpiecznie zignorować. Są one zwykle związane ze skokami użycia zasobów obliczeniowych podczas aprowizowania klastrów obciążeń. Zwiększenie rozmiaru pamięci lub procesora CPU klastra zarządzania nie pokazuje znaczącej poprawy i można je bezpiecznie zignorować.

Specjalne uprawnienia usługi Active Directory są wymagane dla przyłączony do domeny Azure Stack HCI węzłów

Użytkownicy wdrażający i konfigurujący Azure Kubernetes Service on Azure Stack HCI muszą mieć uprawnienie "Pełna kontrola", aby tworzyć obiekty usługi AD w kontenerze usługi Active Directory, w którym są tworzone obiekty serwera i usługi.

Przenoszenie maszyn wirtualnych między Azure Stack HCI klastra szybko prowadzi do błędów uruchamiania maszyny wirtualnej

W przypadku przenoszenia maszyny wirtualnej z jednego węzła (węzła A) do innego węzła (node B) w klastrze usługi Azure Stack HCI przy użyciu narzędzia administracyjnego klastra uruchomienie maszyny wirtualnej w nowym węźle może zakończyć się niepowodzeniem. Po przeniesieniu maszyny wirtualnej z powrotem do oryginalnego węzła nie będzie można uruchomić jej również w tym miejscu.

Ten problem występuje, ponieważ logika oczyszczania pierwszej migracji jest uruchamiana asynchronicznie. W rezultacie Azure Kubernetes Service "aktualizuj lokalizację maszyny wirtualnej" znajduje maszynę wirtualną na oryginalnej funkcji Hyper-V w węźle A i usuwa ją, zamiast jej rejestrowania.

Aby ominąć ten problem, upewnij się, że maszyna wirtualna została pomyślnie uruchomiona w nowym węźle przed przeniesieniem jej z powrotem do oryginalnego węzła.

Pobieranie pakietu usługi AKS Azure Stack HCI kończy się niepowodzeniem z błędem: nie można załadować pliku msft.sme.aks

Jeśli wystąpi błąd msft.sme.aks nie można załadować, a komunikat o błędzie wskazuje również, że ładowanie fragmentów nie powiodło się, należy użyć najnowszej wersji programu Microsoft Edge lub Google Chrome i spróbować ponownie.

New-AksHciCluster podczas tworzenia klastra usługi AKS z 200 węzłami

Wdrożenie dużego klastra może przesłonić się po dwóch godzinach, jednak jest to statyczny przeskok czasu. Możesz zignorować to wystąpienie prze wychodzące, ponieważ operacja jest uruchomiona w tle. Użyj polecenia kubectl get nodes , aby uzyskać dostęp do klastra i monitorować postęp.

Moduł równoważenia obciążenia w Azure Kubernetes Service wymaga rezerwacji DHCP

Rozwiązanie równoważenia obciążenia w usłudze Azure Kubernetes Service on Azure Stack HCI dhcp do przypisywania adresów IP do punktów końcowych usługi. Jeśli adres IP zmieni się dla punktu końcowego usługi z powodu ponownego uruchomienia usługi, dzierżawa DHCP wygaśnie z powodu krótkiego czasu wygaśnięcia. W związku z tym usługa staje się niedostępna, ponieważ adres IP w konfiguracji rozwiązania Kubernetes różni się od adresu w punkcie końcowym. Może to prowadzić do niedostępności klastra Kubernetes. Aby rozwiązać ten problem, użyj puli adresów MAC dla punktów końcowych usługi ze zrównoważonym obciążeniem i zarezerwuj określone adresy IP dla każdego adresu MAC w puli.

W przypadku korzystania z dużych klastrów Get-AksHciLogs polecenie może się nie powieść z wyjątkiem

W przypadku dużych klastrów polecenie może zgłosić wyjątek, nie może wyliczyć węzłów lub nie wygeneruje Get-AksHciLogs c:\wssd\wssdlogs.zip wyjściowego. Wynika to z tego, że polecenie programu PowerShell służące do zipowania pliku Compress-Archive ma limit rozmiaru pliku wyjściowego 2 GB.

Tworzenie sieci wirtualnych o podobnej konfiguracji powoduje nakładanie się problemów

Podczas tworzenia nakładających się obiektów sieciowych przy użyciu new-akshcinetworksetting poleceń new-akshciclusternetwork cmdlet programu i programu PowerShell mogą wystąpić problemy. Na przykład może się to zdarzyć w scenariuszach, w których dwie konfiguracje sieci wirtualnej są prawie takie same.

Liczba Windows węzła systemu Linux nie jest widoczny po Get-AksHciCluster uruchomieniu

Jeśli aprowizujesz klaster usługi AKS na platformie Azure Stack HCI z zerem węzłów systemu Linux lub Windows, po uruchomieniu get-AksHciClusterjako dane wyjściowe otrzymasz pusty ciąg lub wartość null.

Próba zwiększenia liczby węzłów procesu roboczego kończy się niepowodzeniem

W przypadku tworzenia klastra ze statycznym adresem IP przy użyciu programu PowerShell, a następnie próby zwiększenia liczby węzłów procesu roboczego w klastrze obciążenia, instalacja została zablokowana przy liczbie płaszczyzn sterowania na poziomie 2, nadal czekając na żądany stan: 3. Po upływie tego czasu zostanie wyświetlony inny komunikat o błędzie: Błąd: uchylił czas oczekiwania na warunek.

Uruchomienie get-AksHciCluster pokazuje, że węzły płaszczyzny sterowania zostały utworzone i zaaprowizowane oraz były w stanie Gotowe. Jednak po uruchomieniu okazało się, że węzły płaszczyzny sterowania zostały utworzone, ale nie aprowizowane i nie kubectl get nodes były w kubectl get nodes Gotowe.

Jeśli wystąpi ten błąd, sprawdź, czy adresy IP zostały przypisane do utworzonych węzłów przy użyciu Menedżera funkcji Hyper-V lub programu PowerShell:

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

Następnie sprawdź ustawienia sieci, aby upewnić się, że w puli pozostało wystarczająco dużo adresów IP, aby utworzyć więcej maszyn wirtualnych.

Użycie Pulpit zdalny do nawiązania połączenia z klastrem zarządzania powoduje błąd połączenia

W przypadku używania protokołu Pulpit zdalny (RDP) do nawiązywania połączenia z jednym z węzłów w klastrze usługi Azure Stack HCI, a następnie uruchamiania get-AksHciCluster,jest wyświetlany błąd z komunikatem o tym, że połączenie nie powiodło się z powodu nieudanej odpowiedzi hosta.

Przyczyną niepowodzenia połączenia jest to, że niektóre polecenia programu PowerShell, które używają polecenia , nie powiodą się z kubeconfig-mgmt błędem podobnym do następującego:

Unable to connect to the server: d ial tcp 172.168.10.0:6443, where 172.168.10.0 is the IP of the control plane.

Zasobnik kube-vip może zostać zamknięty z dwóch powodów:

  • Użycie pamięci w systemie może spowalniać etcd , co wpływa na etcd
  • Serwer kube-apiserver nie jest dostępny.

Aby rozwiązać ten problem, spróbuj ponownie uruchomić maszynę. Problem z spowolnieniem pamięci może jednak powrócić.

Podczas uruchamiania rozwiązania kubectl get zasobnikizostały zablokowane w stanie Zakończenie

Podczas wdrażania usługi AKS na Azure Stack HCI, a następnie uruchamiania zasobników w tym samym węźle są zablokowane kubectl get pods w kubectl get pods Maszyna odrzuca połączenia SSH, ponieważ w węźle prawdopodobnie występuje duże zapotrzebowanie na pamięć. Ten problem występuje, ponieważ Windows są zbyt aprowizowane i nie ma żadnych rezerw dla podstawowych składników.

Aby uniknąć tej sytuacji, dodaj limity zasobów i żądania zasobów dla procesora CPU i pamięci do specyfikacji zasobnika, aby upewnić się, że węzły nie są zbyt aprowizowane. Windows nie obsługują eksmisji na podstawie limitów zasobów, dlatego należy oszacować, ile kontenerów będzie używać, a następnie upewnić się, że węzły mają wystarczającą ilość procesora CPU i pamięci. Więcej informacji można znaleźć w wymaganiach systemowych.

Uruchomienie Remove-ClusterNode eksmisji węzła z klastra trybu failover, ale węzeł nadal istnieje

Podczas uruchamiania polecenia Remove-ClusterNode węzeł jest eksmitowany z klastra trybu failover, ale jeśli polecenie Remove-AksHciNode nie zostanie później uruchomione, węzeł nadal będzie istniał w usłudze CloudAgent.

Ponieważ węzeł został usunięty z klastra, ale nie z usługi CloudAgent, jeśli używasz wirtualnego dysku twardego do utworzenia nowego węzła, zostanie wyświetlony błąd Nie znaleziono pliku. Ten problem występuje, ponieważ wirtualny dysk twardy znajduje się w magazynie udostępnionym, a eksmitowany węzeł nie ma do niego dostępu.

Aby rozwiązać ten problem, usuń węzeł fizyczny z klastra, a następnie wykonaj poniższe kroki:

  1. Uruchom Remove-AksHciNode , aby wyrejestrować węzeł z usługi CloudAgent.
  2. Wykonywanie rutynowej konserwacji, takiej jak ponowne obrazowanie maszyny.
  3. Dodaj węzeł z powrotem do klastra.
  4. Uruchom Add-AksHciNode , aby zarejestrować węzeł w usłudze CloudAgent.

Zasobnik interfejsu magazynu kontenerów zablokowany w stanie ContainerCreating

Nowy klaster obciążenia Kubernetes został utworzony za pomocą usługi Kubernetes w wersji 1.16.10, a następnie zaktualizowany do wersji 1.16.15. Po aktualizacji zasobnik został zablokowany w stanie ContainerCreating, a zasobnik został zablokowany w stanie Zakończenie, jak pokazano w csi-msk8scsi-node-9x47m poniższych danych csi-msk8scsi-node-9x47mkube-proxy-qqnkr wyjściowych: kube-proxy-qqnkr

Error: kubectl.exe get nodes  
NAME              STATUS     ROLES    AGE     VERSION 
moc-lf22jcmu045   Ready      <none>   5h40m   v1.16.15 
moc-lqjzhhsuo42   Ready      <none>   5h38m   v1.16.15 
moc-lwan4ro72he   NotReady   master   5h44m   v1.16.15

\kubectl.exe get pods -A 

NAMESPACE     NAME                        READY   STATUS              RESTARTS   AGE 
    5h38m 
kube-system   csi-msk8scsi-node-9x47m     0/3     ContainerCreating   0          5h44m 
kube-system   kube-proxy-qqnkr            1/1     Terminating         0          5h44m  

Ponieważ rozwiązanie kubelet zakończyło się w złym stanie i nie może już sgadać z serwerem interfejsu API, jedynym rozwiązaniem jest ponowne uruchomienie usługi kubelet. Po ponownym uruchomieniu klaster przechodzi w stan uruchomienia.

Następne kroki

Jeśli nadal występują problemy podczas korzystania z usługi Azure Kubernetes Service on Azure Stack HCI, możesz zgłaszanie usterek za pośrednictwem GitHub.