Rozwiązywanie problemów i błędów podczas instalacji usługi AKS Arc

Ten komunikat o błędzie jest wyświetlany po uruchomieniu polecenia Install-AksHci.

Jeśli nie używasz Private Link, aby rozwiązać ten problem, wykonaj następujące kroki:

1. Otwórz program PowerShell i uruchom polecenie Uninstall-AksHci.
2. Otwórz Azure Portal i przejdź do grupy zasobów użytej podczas uruchamiania polecenia Install-AksHci.
3. Sprawdź, czy wszystkie połączone zasoby klastra są wyświetlane w stanie Rozłączone i zawierają nazwę wyświetlaną jako losowo wygenerowany identyfikator GUID.
4. Usuń te zasoby klastra.
5. Zamknij sesję programu PowerShell i otwórz nową sesję przed ponownym uruchomieniem Install-AksHci .

Ten błąd może być spowodowany przez proces instalacji próbujący naruszyć zasady platformy Azure, które zostały ustawione w subskrypcji platformy Azure lub grupie zasobów udostępnionej podczas procesu dołączania usługi Azure Arc. Ten błąd może wystąpić dla użytkowników, którzy zdefiniowali zasady platformy Azure na poziomie subskrypcji lub grupy zasobów, a następnie spróbują zainstalować usługę AKS w usłudze Azure Stack HCI, co narusza Azure Policy.

Aby rozwiązać ten problem, przeczytaj komunikat o błędzie, aby zrozumieć, które Azure Policy ustawione przez administratora platformy Azure zostały naruszone, a następnie zmodyfikuj zasady platformy Azure, wprowadzając wyjątek do zasad platformy Azure. Aby dowiedzieć się więcej na temat wyjątków zasad, zobacz Azure Policy strukturę wykluczeń.

Wcześniej zainstalowana funkcja pozostaje w stanie błędu i nie została wyczyszczona. Może zostać wyświetlony następujący błąd:

Exception [An error occurred while creating resource 'MOC Cloud Agent Service' for the clustered role 'ca-3f72bdeb-xxxx-4ae9-a721-3aa902a998f0'.]
Stacktrace [at Add-FailoverClusterGenericRole, C:\Program Files\WindowsPowerShell\Modules\Moc\1.0.20\Common.psm1: line 2987
at Install-CloudAgent, C:\Program Files\WindowsPowerShell\Modules\Moc\1.0.20\Moc.psm1: line 1310
at Install-MocAgents, C:\Program Files\WindowsPowerShell\Modules\Moc\1.0.20\Moc.psm1: line 1229
at Initialize-Cloud, C:\Program Files\WindowsPowerShell\Modules\Moc\1.0.20\Moc.psm1: line 1135
at Install-MocInternal, C:\Program Files\WindowsPowerShell\Modules\Moc\1.0.20\Moc.psm1: line 1078
at Install-Moc, C:\Program Files\WindowsPowerShell\Modules\Moc\1.0.20\Moc.psm1: line 207
at Install-AksHciInternal, C:\Program Files\WindowsPowerShell\Modules\AksHci\1.1.25\AksHci.psm1: line 3867
at Install-AksHci, C:\Program Files\WindowsPowerShell\Modules\AksHci\1.1.25\AksHci.psm1: line 778
at <ScriptBlock>, <No file>: line 1]
InnerException[The object already exists]

Możesz też zobaczyć:

Install-Moc failed.
Exception [Unable to save property changes for 'IPv4 Address xxx.168.18.0'.]
Stacktrace [at Add-FailoverClusterGenericRole, C:\Program Files\WindowsPowerShell\Modules\Moc\1.0.20\Common.psm1: line 2971
at Install-CloudAgent, C:\Program Files\WindowsPowerShell\Modules\Moc\1.0.20\Moc.psm1: line 1310
at Install-MocAgents, C:\Program Files\WindowsPowerShell\Modules\Moc\1.0.20\Moc.psm1: line 1229
at Initialize-Cloud, C:\Program Files\WindowsPowerShell\Modules\Moc\1.0.20\Moc.psm1: line 1135
at Install-MocInternal, C:\Program Files\WindowsPowerShell\Modules\Moc\1.0.20\Moc.psm1: line 1078
at Install-Moc, C:\Program Files\WindowsPowerShell\Modules\Moc\1.0.20\Moc.psm1: line 207
at Install-AksHciInternal, C:\Program Files\WindowsPowerShell\Modules\AksHci\1.1.25\AksHci.psm1: line 3867
at Install-AksHci, C:\Program Files\WindowsPowerShell\Modules\AksHci\1.1.25\AksHci.psm1: line 778
at <ScriptBlock>, <No file>: line 1]
InnerException[A matching cluster network for the specified IP address could not be found]

Aby rozwiązać ten problem, ręcznie wyczyść rolę klastra. Zasób można usunąć z menedżera klastra trybu failover, uruchamiając następujące polecenie cmdlet programu PowerShell: Remove-ClusterResource -name <resource name>.

Polecenie Install-AksHci cmdlet kończy się niepowodzeniem z komunikatem "Błąd GetRelease zwrócony przez wywołanie interfejsu API: Błąd pobierania pliku: Niezgodność skrótu".

1. Otwórz program PowerShell i uruchom polecenie Uninstall-AksHci.
2. Ponów próbę instalacji.
3. Jeśli problem będzie się powtarzać, użyj parametru -concurrentDownloadsSet-AksHciConfig i ustaw go na liczbę niższą niż domyślna 10 przed ponowieniu próby instalacji. Zmniejszenie liczby równoczesnych pobrań może pomóc w pomyślnym zakończeniu pobierania dużych plików przez poufne sieci. Ten parametr jest funkcją w wersji zapoznawczej.

Po wdrożeniu podczas ponownego uruchamiania węzłów rozwiązania Azure Stack HCI raport usługi AKS pokazał stan niepowodzenia rozliczeń.

Aby rozwiązać ten problem, postępuj zgodnie z instrukcjami , aby ręcznie obrócić token i ponownie uruchomić wtyczkę usługi KMS.

Po uruchomieniu polecenia Install-AksHci instalacja została zatrzymana i wyświetlony następujący komunikat o błędzie:

\kubectl.exe --kubeconfig=C:\AksHci\0.9.7.3\kubeconfig-clustergroup-management 
get akshciclusters -o json returned a non zero exit code 1 
[Unable to connect to the server: dial tcp 192.168.0.150:6443: 
connectex: A connection attempt failed because the connected party 
did not properly respond after a period of time, or established connection 
failed because connected host has failed to respond.]

Istnieje wiele powodów, dla których instalacja może zakończyć się niepowodzeniem z powodu błędu waiting for API server .

W poniższej sekcji opisano możliwe przyczyny i rozwiązania tego błędu.

Przyczyna 1. Nieprawidłowa konfiguracja bramy IP Jeśli używasz statycznych adresów IP i został wyświetlony następujący komunikat o błędzie, upewnij się, że konfiguracja adresu IP i bramy jest poprawna.

Install-AksHci 
C:\AksHci\kvactl.exe create --configfile C:\AksHci\yaml\appliance.yaml  --outfile C:\AksHci\kubeconfig-clustergroup-management returned a non-zero exit code 1 [ ]

Aby sprawdzić, czy masz odpowiednią konfigurację dla adresu IP i bramy, uruchom następujące polecenie:

ipconfig /all

W wyświetlonych ustawieniach konfiguracji potwierdź konfigurację. Możesz również spróbować wysłać polecenie ping do bramy IP i serwera DNS.

ping <DNS server>

Jeśli te metody nie działają, użyj polecenia New-AksHciNetworkSetting , aby zmienić konfigurację.

Przyczyna 2: Nieprawidłowy serwer DNS Jeśli używasz statycznych adresów IP, upewnij się, że serwer DNS jest poprawnie skonfigurowany. Aby sprawdzić adres serwera DNS hosta, użyj następującego polecenia:

Get-NetIPConfiguration.DNSServer | ?{ $_.AddressFamily -ne 23} ).ServerAddresses

Upewnij się, że adres serwera DNS jest taki sam jak adres używany podczas uruchamiania New-AksHciNetworkSetting , uruchamiając następujące polecenie:

Get-MocConfig

Jeśli serwer DNS został niepoprawnie skonfigurowany, zainstaluj ponownie usługę AKS w usłudze Azure Stack HCI przy użyciu poprawnego serwera DNS. Aby uzyskać więcej informacji, zobacz Ponowne uruchamianie, usuwanie lub ponowne instalowanie Azure Kubernetes Service w usłudze Azure Stack HCI.

Problem został rozwiązany po usunięciu konfiguracji i ponownym uruchomieniu maszyny wirtualnej przy użyciu nowej konfiguracji.

Install-AksHci Wystąpił błąd, ponieważ inny proces uzyskuje mocstack.cabdostęp do elementu .

Aby rozwiązać ten problem, zamknij wszystkie otwarte okna programu PowerShell, a następnie otwórz ponownie nowe okno programu PowerShell.

Nie można uzyskać dostępu do pliku, ponieważ jest on używany przez inny proces.

Ten problem można rozwiązać, uruchamiając ponownie sesję programu PowerShell. Zamknij okno programu PowerShell i spróbuj ponownie Install-AksHci.

Install-AksHci Ten błąd zakończył się niepowodzeniem, ponieważ zakresy puli adresów IP podane w konfiguracji usługi AKS w usłudze Azure Stack HCI zostały wyłączone przez 1 w ciDR i mogą spowodować awarię usługi CloudAgent. Jeśli na przykład masz podsieć 10.0.0.0/21 z zakresem adresów 10.0.0.0 – 10.0.7.255 i użyjesz adresu początkowego 10.0.0.1 lub adresu końcowego 10.0.7.254, spowoduje to awarię usługi CloudAgent.

Aby obejść ten problem, uruchom polecenie New-AksHciNetworkSetting i użyj dowolnego innego prawidłowego zakresu adresów IP dla puli adresów VIP i puli węzłów Kubernetes. Upewnij się, że używane wartości nie są wyłączone przez 1 na początku lub na końcu zakresu adresów.

Podczas uruchamiania polecenia Install-AksHci w konfiguracji z jednym węzłem instalacja działała, ale podczas konfigurowania klastra trybu failover instalacja kończy się niepowodzeniem z komunikatem o błędzie. Jednak polecenie ping agenta w chmurze wykazało, że agent CloudAgent był osiągalny.

Aby upewnić się, że wszystkie węzły mogą rozpoznać system DNS usługi CloudAgent, uruchom następujące polecenie w każdym węźle:

Resolve-DnsName <FQDN of cloudagent>

Jeśli powyższy krok zakończy się pomyślnie w węzłach, upewnij się, że węzły mogą nawiązać połączenie z portem CloudAgent, aby sprawdzić, czy serwer proxy nie próbuje zablokować tego połączenia, a port jest otwarty. Aby to zrobić, uruchom następujące polecenie w każdym węźle:

Test-NetConnection  <FQDN of cloudagent> -Port <Cloudagent port - default 65000>

Błąd wynika z błędu podczas pobierania.

Jeśli wystąpi ten błąd, użyj najnowszej wersji przeglądarki Microsoft Edge lub Google Chrome i spróbuj ponownie.

Ten błąd pojawia się po uruchomieniu polecenia Set-AksHciRegistration w usłudze AKS w instalacji rozwiązania Azure Stack HCI. Błąd wskazuje, że dostawcy zasobów Kubernetes nie są zarejestrowani dla dzierżawy, która jest obecnie zalogowana.

Aby rozwiązać ten problem, uruchom interfejs wiersza polecenia platformy Azure lub poniższe kroki programu PowerShell:

az provider register --namespace Microsoft.Kubernetes
az provider register --namespace Microsoft.KubernetesConfiguration

Register-AzResourceProvider -ProviderNamespace Microsoft.Kubernetes
Register-AzResourceProvider -ProviderNamespace Microsoft.KubernetesConfiguration

Rejestracja trwa około 10 minut. Aby monitorować proces rejestracji, użyj następujących poleceń.

az provider show -n Microsoft.Kubernetes -o table
az provider show -n Microsoft.KubernetesConfiguration -o table

Get-AzResourceProvider -ProviderNamespace Microsoft.Kubernetes
Get-AzResourceProvider -ProviderNamespace Microsoft.KubernetesConfiguration

Install-AksHci zawiesza się Waiting for azure-arc-onboarding to complete przed przekroczeniem limitu czasu, gdy:

• Jednostka usługi jest używana w usłudze AKS w usłudze Azure Stack HCI Registration (Set-AksHciRegistration).
• Zainstalowano moduły Az.Accounts programu PowerShell (2.7.x).

Az.Accounts 2.7.x wersje usuwa elementy ServicePrincipalSecret i CertificatePassword w PSAzureRmAccountsystemie , które są używane przez usługę AKS w usłudze Azure Stack HCI na potrzeby dołączania do usługi Azure Arc.

Aby odtworzyć:

1. Zainstaluj Az.Accounts wersję modułów programu PowerShell (>= 2.7.0).
2. Set-AksHciRegistration przy użyciu jednostki usługi.
3. Install-AksHci.

Oczekiwane zachowanie:

1. Instalacja usługi AKS w usłudze Azure Stack HCI zawiesza się pod adresem Waiting for azure-arc-onboarding to complete.
2. Azure-arc-onboarding zasobniki przechodzą w pętlę awarii.
3. Błąd Azure-arc-onboarding zasobników z następującym błędem:
   Starting onboarding process ERROR: variable CLIENT_SECRET is required

Aby rozwiązać ten problem:

Odinstaluj moduły Az.Accounts z wersjami 2.7.x. uruchom następujące polecenie cmdlet:

Uninstall-Module -Name Az.Accounts -RequiredVersion 2.7.0 -Force

Ten błąd występuje, jeśli usługa Azure Stack HCI jest poza zasadami. Stan połączenia w klastrze może wskazywać, że jest połączony, ale w dzienniku zdarzeń jest wyświetlany komunikat ostrzegawczy.Azure Stack HCI's subscription is expired, run Sync-AzureStackHCI to renew the subscription

Aby rozwiązać ten błąd, sprawdź, czy klaster jest zarejestrowany na platformie Azure przy użyciu Get-AzureStackHCI polecenia cmdlet programu PowerShell dostępnego na maszynie. Pulpit platformy Windows Admin Center zawiera też informacje o stanie rejestracji klastra na platformie Azure.

Jeśli klaster jest już zarejestrowany, należy wyświetlić pole LastConnected w danych wyjściowych polecenia Get-AzureStackHCI. Jeśli to pole pokazuje, że upłynęło ponad 30 dni, należy spróbować rozwiązać problem przy użyciu polecenia cmdlet Sync-AzureStackHCI.

Możesz też sprawdzić, czy każdy węzeł klastra ma wymaganą licencję, używając następującego polecenia cmdlet:

Get-ClusterNode | % { Get-AzureStackHCISubscriptionStatus -ComputerName $_ }

Computer Name Subscription Name           Status   Valid To
------------- -----------------           ------   --------
MS-HCIv2-01   Azure Stack HCI             Active   12/23/2021 12:00:14 AM
MS-HCIv2-01   Windows Server Subscription Inactive

MS-HCIv2-02   Azure Stack HCI             Active   12/23/2021 12:00:14 AM
MS-HCIv2-02   Windows Server Subscription Inactive

MS-HCIv2-03   Azure Stack HCI             Active   12/23/2021 12:00:14 AM
MS-HCIv2-03   Windows Server Subscription Inactive

Jeśli problem nie został rozwiązany po uruchomieniu Sync-AzureStackHCI polecenia cmdlet, skontaktuj się z pomocą techniczną firmy Microsoft.

Ten problem występuje, ponieważ instalacja nie powiodła się, może spowodować wyciek zasobów, które muszą zostać wyczyszczone przed ponownym zainstalowaniem.

Jeśli instalacja nie powiedzie się przy użyciu polecenia Install-AksHci, przed ponownym uruchomieniem Install-AksHci należy uruchomić polecenie Uninstall-AksHci.

Te błędy można wyzwolić podczas uruchamiania bez wcześniejszego uruchomienia Install-AksHci polecenia Set-AksHciConfig .

Aby rozwiązać ten problem, uruchom uninstall-akshci i zamknij wszystkie okna programu PowerShell. Otwórz nową sesję programu PowerShell i uruchom ponownie proces instalacji rozwiązania AKS-HCI, instalując usługę AKS-HCI przy użyciu programu PowerShell.

Polecenie Set-AksHciConfig cmdlet programu PowerShell kończy się niepowodzeniem z powodu błędu:

GetCatalog error returned by API call: ... proxyconnect tcp: tls: first record does not look like a TLS Handshake

Jeśli używasz usługi AKS z serwerem proxy, być może użyto nieprawidłowego adresu URL podczas ustawiania wymaganej wartości adresu URL serwera proxy HTTPS. Wartości adresu URL serwera proxy HTTP i adresu URL serwera proxy HTTPS są wymagane podczas konfigurowania usługi AKS przy użyciu serwera proxy, ale często obie wartości muszą współdzielić ten sam adres URL poprzedzony prefiksem HTTP.

Jeśli tak może być w twoim środowisku, spróbuj wykonać następujące kroki zaradcze:

1. Zamknij okno programu PowerShell i otwórz nowe.
2. New-AksHciNetworkSetting Uruchom ponownie polecenia cmdlet i New-AksHciProxySetting . Podczas uruchamiania New-AksHciProxySetting-https ustaw parametr z tą samą wartością adresu URL poprzedzoną prefiksem HTTP, która została ustawiona dla parametru -http.
3. Uruchom Set-AksHciConfig polecenie i kontynuuj.

Podczas wdrażania usługi AKS w usłudze Azure Stack HCI wdrożenie może upłynął limit czasu w różnych punktach procesu w zależności od tego, gdzie wystąpiła nieprawidłowa konfiguracja. Należy przejrzeć komunikat o błędzie, aby określić przyczynę i miejsce jego wystąpienia.

Na przykład w poniższym błędzie punkt, w którym wystąpiła nieprawidłowa konfiguracja, znajduje się w pliku Get-DownloadSdkRelease -Name "mocstack-stable":

$vnet = New-AksHciNetworkSettingSet-AksHciConfig -vnet $vnetInstall-AksHciVERBOSE: 
Initializing environmentVERBOSE: [AksHci] Importing ConfigurationVERBOSE: 
[AksHci] Importing Configuration Completedpowershell : 
GetRelease - error returned by API call: 
Post "https://msk8s.api.cdp.microsoft.com/api/v1.1/contents/default/namespaces/default/names/mocstack-stable/versions/0.9.7.0/files?action=generateDownloadInfo&ForegroundPriority=True": 
dial tcp 52.184.220.11:443: connectex: 
A connection attempt failed because the connected party did not properly
respond after a period of time, or established connection failed because
connected host has failed to respond.At line:1 char:1+ powershell -command
{ Get-DownloadSdkRelease -Name "mocstack-stable"}

Oznacza to, że fizyczny węzeł Azure Stack HCI może rozpoznać nazwę adresu URL pobierania, msk8s.api.cdp.microsoft.comale węzeł nie może nawiązać połączenia z serwerem docelowym.

Aby rozwiązać ten problem, należy określić, gdzie wystąpił podział w przepływie połączenia. Poniżej przedstawiono kilka kroków, które należy wykonać, aby spróbować rozwiązać problem z węzła klastra fizycznego:

1. Wyślij polecenie ping do docelowej nazwy DNS: ping msk8s.api.cdp.microsoft.com.
2. Jeśli otrzymasz odpowiedź z powrotem i nie upłynął limit czasu, podstawowa ścieżka sieciowa działa.
3. Jeśli upłynął limit czasu połączenia, może dojść do przerwy w ścieżce danych. Aby uzyskać więcej informacji, zobacz sprawdzanie ustawień serwera proxy. Może też wystąpić przerwa w ścieżce powrotnej, więc należy sprawdzić reguły zapory.

Podczas uruchamiania polecenia Set-AksHciConfig moż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.

Ten błąd zwykle występuje z powodu zmiany tokenu zabezpieczającego użytkownika (ze względu na zmianę członkostwa w grupie), zmiany hasła lub wygasłego hasła. W większości przypadków problem można rozwiązać, wylogowując się z komputera i logując się ponownie. Jeśli problem nadal nie powiedzie się, możesz zgłosić problem w usłudze GitHub AKS HCI.

Oczekuje się, że agenci moc zachowają tylko ostatnie 100 dzienników agentów. Powinny one usuwać starsze dzienniki. Jednak rotacja dziennika nie odbywa się i dzienniki ciągle gromadzą się zużywające miejsce na dysku.

Aby odtworzyć: Install AksHci i mieć uruchomiony klaster do momentu przekroczenia liczby dzienników agenta 100. W momencie utworzenia n-tego dziennika agenci mają usunąć dziennik n-100, jeśli istnieją.

W celu rozwiązania tego problemu:

1. Zmodyfikuj pliki logconf agenta w chmurze i agentów węzła. Konfiguracja dziennika agenta w chmurze znajduje się w:
   (Get-MocConfig).cloudConfigLocation+"\log\logconf".
   Konfiguracja dziennika agenta węzła znajduje się w:
   (Get-MocConfig).cloudConfigLocation+"\log\logconf".

2. Zmień wartość limitu na 100, a miejsca na 100 i zapisz pliki konfiguracji.

3. Uruchom ponownie agenta w chmurze i agentów węzła, aby zarejestrować te zmiany.

Te kroki rozpoczynają rotację dziennika dopiero po wygenerowaniu 100 nowych dzienników po ponownym uruchomieniu agenta. Jeśli w momencie ponownego uruchomienia nie ma już dzienników agenta, rotacja dzienników zostanie uruchomiona dopiero po wygenerowaniu dzienników n+100.

W przypadku używania polecenia Set-AksHciConfig do określenia -imageDirparametrów , -workingDirlub -cloudConfigLocation-nodeConfigLocation o nazwie ścieżki zawierającej znak spacji, na przykład D:\Cloud Share\AKS HCI, uruchomienie usługi klastra agenta w chmurze zakończy się niepowodzeniem z następującym (lub podobnym) komunikatem o 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'

Aby obejść ten problem, użyj ścieżki, która nie zawiera spacji, na przykład C:\CloudShare\AKS-HCI.

Ten błąd może wystąpić w przypadku błędnej konfiguracji infrastruktury.

Aby usunąć ten błąd, wykonaj następujące kroki:

1. Sprawdź konfigurację i ustawienia bramy serwera DNS hosta:

   1. Upewnij się, że serwer DNS jest skonfigurowany poprawnie. Aby sprawdzić adres serwera DNS hosta, uruchom następujące polecenie:

      ((Get-NetIPConfiguration).DNSServer | ?{ $_.AddressFamily -ne 23}).ServerAddresses
      

   2. Aby sprawdzić, czy twój adres IP i konfiguracja bramy są poprawne, uruchom polecenie ipconfig/all.
   3. Spróbuj wysłać polecenie ping do bramy IP i serwera DNS.

2. Sprawdź usługę CloudAgent, aby upewnić się, że jest uruchomiona:

   1. Wyślij polecenie ping do usługi CloudAgent, aby upewnić się, że jest ona osiągalna.
   2. Upewnij się, że wszystkie węzły mogą rozpoznać system DNS usługi CloudAgent, uruchamiając następujące polecenie w każdym węźle:

      Resolve-DnsName <FQDN of cloudagent>
      

   3. Jeśli będzie można pomyślnie wykonać poprzedni krok w węzłach, upewnij się, że węzły mogą uzyskać dostęp do portu usługi CloudAgent. W ten sposób sprawdzisz, czy serwer proxy nie próbuje zablokować tego połączenia i czy port jest otwarty. Aby to zrobić, uruchom następujące polecenie w każdym węźle:

      Test-NetConnection <FQDN of cloudagent> -Port <Cloudagent port - default 65000>
      

   4. Aby sprawdzić, czy usługa klastrowania jest uruchomiona dla klastra trybu failover, możesz też uruchomić następujące polecenie:

      Get-ClusterGroup -Name (Get-AksHciConfig).Moc['clusterRoleName']
      

Zazwyczaj oznacza to, że obiekt nazwy klastra (CNO) reprezentujący bazowy klaster trybu failover w usłudze Active Directory Domain Services (AD DS) nie ma uprawnień do tworzenia obiektu komputera wirtualnego (VCO) w jednostce organizacyjnej (OU) lub w kontenerze, w którym znajduje się klaster.

Jeśli nie jesteś administratorem domeny, możesz poprosić o udzielenie uprawnień obiektu CNO do jednostki organizacyjnej lub wstępne przygotowanie obiektu wirtualnego dla ogólnej usługi klastra agenta w chmurze.

Jeśli jesteś administratorem domeny, nadal istnieje możliwość, że jednostki organizacyjnej lub kontenera nie mają wymaganych uprawnień. Na przykład tryb wymuszania wprowadzony w KB5008383 może być włączony w usłudze Active Directory. Spróbuj wykonać następujące czynności przed podjęciem próby ponownej instalacji.

1. Przejdź do Użytkownicy i komputery usługi Active Directory.
2. Kliknij prawym przyciskiem myszy jednostki organizacyjnej lub kontener, w którym znajduje się klaster.
3. Wybierz pozycję Deleguj kontrolę... , aby otworzyć Kreatora delegowania kontrolek.
4. Kliknij przycisk Dalej> kliknij przycisk Dodaj..., aby otworzyć okno Wybieranie użytkowników, komputerów lub grup .
5. Wybierz wybraną grupę lub użytkowników, którym chcesz delegować kontrolę > , kliknij przycisk OK.
6. Wybierz pozycję Utwórz zadanie niestandardowe, aby delegować> kliknij przycisk Dalej , aby przejść do strony Typ obiektu usługi Active Directory .
7. Zaznacz tylko następujące obiekty w folderze> Select Computer objects Select Create selected objects> in this folder and Delete selected objects in this folder (Usuń wybrane obiekty w tym folderze> Kliknij dalej), aby przejść do strony Uprawnienia.
8. Wybierz pozycję Utwórz wszystkie obiekty podrzędne i usuń wszystkie obiekty podrzędne z listy uprawnień > Kliknijprzycisk Zakończ dalej>

Jeśli ponowna instalacja nie powiedzie się, spróbuj ponownie wykonać powyższe czynności, wykonując następujące zmiany w krokach 7 i 8:

• Krok 7. Wybierz ten folder, istniejące obiekty w tym folderze i utwórz nowe obiekty w tym folderze> Kliknij dalej.
• Krok 8. Wybierz pozycję Odczyt, Zapis, Utwórz wszystkie obiekty podrzędne i Usuń wszystkie obiekty podrzędne z listy uprawnień > Kliknij przycisk Dalej> kliknij przycisk Zakończ.

Ten błąd może wystąpić podczas uruchamiania polecenia Install-AksHci.

Aby uzyskać więcej informacji, uruchom polecenie $error = Install-AksHci , a następnie $error[0].Exception.InnerException.

Polecenia programu PowerShell usługi Aks-Hci nie weryfikują dostępnej pamięci na serwerze hosta przed utworzeniem węzłów kubernetes. Ten problem może prowadzić do wyczerpania pamięci i maszyn wirtualnych, które nie są uruchamiane. Ten błąd nie jest obecnie obsługiwany bezpiecznie, a wdrożenie przestanie odpowiadać bez wyraźnego komunikatu o błędzie.

Jeśli masz wdrożenie, które przestaje odpowiadać, otwórz Podgląd zdarzeń i sprawdź komunikat o błędzie związany z funkcją Hyper-V wskazujący, że nie ma wystarczającej ilości pamięci, aby uruchomić maszynę wirtualną.

Ten błąd może wystąpić, gdy masz wiele dzierżaw na koncie platformy Azure.

Użyj $tenantId = (Get-AzContext).Tenant.Id polecenia , aby ustawić odpowiednią dzierżawę. Następnie dołącz tę dzierżawę jako parametr podczas uruchamiania polecenia Set-AksHciRegistration.

Podczas próby wdrożenia klastra usługi AKS na maszynie wirtualnej platformy Azure instalacja została zablokowana w Waiting for pod 'Cloud Operator' to be ready...lokalizacji , a następnie zakończyła się niepowodzeniem i upłynął limit czasu po dwóch godzinach. Próby rozwiązania problemu przez sprawdzenie bramy i serwera DNS wykazały, że działają prawidłowo. Sprawdza, czy nie znaleziono konfliktów adresów IP lub MAC. Dzienniki nie wykazały puli adresów VIP. Wystąpiło ograniczenie dotyczące ściągania obrazu kontenera przy użyciu sudo docker pull ecpacr.azurecr.io/kube-vip:0.3.4 funkcji , która zwróciła limit czasu protokołu Transport Layer Security (TLS) zamiast nieautoryzowanego.

Aby rozwiązać ten problem, wykonaj następujące czynności:

1. Rozpocznij wdrażanie klastra.
2. Po wdrożeniu klastra połącz się z maszyną wirtualną klastra zarządzania za pośrednictwem protokołu SSH, jak pokazano poniżej:

ssh -i (Get-MocConfig)['sshPrivateKey'] clouduser@<IP Address>

3. Zmień ustawienie maksymalnej jednostki transmisji (MTU). Nie wahaj się wprowadzić zmianę; Jeśli wprowadzisz zmianę za późno, wdrożenie zakończy się niepowodzeniem. Modyfikowanie ustawienia jednostki MTU pomaga odblokować ściąganie obrazu kontenera.

sudo ifconfig eth0 mtu 1300

4. Aby wyświetlić stan kontenerów, uruchom następujące polecenie:

sudo docker ps -a

Po wykonaniu tych kroków ściąganie obrazu kontenera powinno zostać odblokowane.

Ten błąd wskazuje, że adres IP usługi w chmurze nie jest częścią sieci klastra i nie jest zgodny z żadną z sieci klastra, które mają włączoną client and cluster communication rolę.

Aby rozwiązać ten problem, uruchom polecenie Get-ClusterNetwork , gdzie Role równa ClusterAndClientsię . Następnie w jednym z węzłów klastra wybierz maskę nazwy, adresu i adresu, aby sprawdzić, czy adres IP podany dla -cloudServiceIP parametru New-AksHciNetworkSetting jest zgodny z jedną z wyświetlanych sieci.

Następne kroki

• Omówienie rozwiązywania problemów
• Windows Admin Center znanych problemów
• Rozwiązywanie problemów z klastrami Kubernetes

Jeśli nadal występują problemy podczas korzystania z usługi AKS Arc, możesz zgłosić błędy za pośrednictwem usługi GitHub.