Dotyczy: usługa AKS w usłudze Azure Stack HCI, usługa AKS w systemie Windows Server W tym artykule opisano znane problemy i błędy, które mogą wystąpić podczas instalowania usługi AKS Arc. Możesz również zapoznać się ze znanymi problemami dotyczącymi uaktualniania usługi AKS Arc i korzystania z Centrum administracyjnego systemu Windows.
Błąd "Nie można zaczekać na dołączanie do dodatku"
Ten komunikat o błędzie jest wyświetlany po uruchomieniu polecenia Install-AksHci.
Uwaga
Przyczyną błędu może być włączenie usługi Private Link podczas instalacji. Obecnie nie istnieje obejście tego scenariusza. Usługa AKS w rozwiązaniu HCI nie działa z usługą Private Link.
Jeśli nie używasz usługi Private Link, aby rozwiązać ten problem, wykonaj następujące kroki:
- Otwórz program PowerShell i uruchom polecenie Uninstall-AksHci.
- Otwórz witrynę Azure Portal i przejdź do grupy zasobów użytej podczas uruchamiania polecenia
Install-AksHci
. - Sprawdź, czy wszystkie połączone zasoby klastra są wyświetlane w stanie Rozłączone i zawierają nazwę wyświetlaną jako losowo wygenerowany identyfikator GUID.
- Usuń te zasoby klastra.
- Zamknij sesję programu PowerShell i otwórz nową sesję przed ponownym uruchomieniem
Install-AksHci
.
Błąd: "Instalacja-AksHci nie powiodła się, usługa zwróciła błąd. Status=403 Code="RequestDisallowedByPolicy" podczas instalowania usługi AKS-HCI
Ten błąd może być spowodowany przez proces instalacji próbujący naruszyć zasady platformy Azure 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 usługę Azure Policy.
Aby rozwiązać ten problem, przeczytaj komunikat o błędzie, aby zrozumieć, które zasady platformy Azure ustawione przez administratora platformy Azure zostały naruszone, a następnie zmodyfikuj zasady platformy Azure, wprowadzając wyjątek od zasad platformy Azure. Aby dowiedzieć się więcej na temat wyjątków zasad, zobacz Struktura wykluczania usługi Azure Policy.
Błąd: Instalacja-AksHci nie powiodła się z powodu błędu — [Obiekt już istnieje] Wystąpił błąd podczas tworzenia zasobu "IPv4 Address xxx.xx.xx.xx" dla roli klastrowanej "xx-xxxxxxxx-xxxx-xxxx-xxxx-xxxx-xxxxxxxxx"
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>
.
Błąd: "Błąd getRelease zwrócony przez wywołanie interfejsu API: Błąd pobierania pliku: Niezgodność skrótu"
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".
- Otwórz program PowerShell i uruchom polecenie
Uninstall-AksHci
. - Ponów próbę instalacji.
- Jeśli problem będzie się powtarzać, użyj parametru
-concurrentDownloads
Set-AksHciConfig i ustaw go na liczbę niższą niż domyślna 10 przed ponowną próbą instalacji. Zmniejszenie liczby równoczesnych pobrań może pomóc w pomyślnym zakończeniu pobierania dużych plików w poufnych sieciach. Ten parametr jest funkcją w wersji zapoznawczej.
Po wdrożeniu usługi AKS w usłudze Azure Stack HCI 21H2 ponowne uruchomienie węzłów wykazało stan niepowodzenia rozliczeń
Po wdrożeniu podczas ponownego uruchamiania węzłów rozwiązania Azure Stack HCI raport usługi AKS wyświetlił stan niepowodzenia rozliczeń.
Aby rozwiązać ten problem, postępuj zgodnie z instrukcjami, aby ręcznie obrócić token i ponownie uruchomić wtyczkę KMS.
Upłynął limit czasu install-AksHci z powodu błędu ""
Po uruchomieniu polecenia Install-AksHci instalacja została zatrzymana i wyświetlona 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 odpowiedniego serwera DNS. Aby uzyskać więcej informacji, zobacz Ponowne uruchamianie, usuwanie lub ponowne instalowanie usługi 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.
Błąd: "Proces nie może uzyskać dostępu do pliku "mocstack.cab", ponieważ jest używany przez inny proces"
Install-AksHci
Ten błąd zakończył się niepowodzeniem, ponieważ inny proces uzyskuje mocstack.cab
dostęp do elementu .
Aby rozwiązać ten problem, zamknij wszystkie otwarte okna programu PowerShell, a następnie otwórz ponownie nowe okno programu PowerShell.
Błąd: Instalacja-AksHci kończy się niepowodzeniem z powodu błędu "Install-MOC failed with the error - proces nie może uzyskać dostępu do pliku \<path> ponieważ jest używany przez inny proces.
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 zainstalować-AksHci.
Błąd: "Istniejące połączenie zostało wymuszone przez hosta zdalnego"
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 był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 do 1 na początku lub na końcu zakresu adresów.
Instalacja-AksHci nie powiodła się w instalacji z wieloma węzłami z powodu błędu "Węzły nie osiągnęły aktywnego stanu"
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 pingowanie 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ę powodzeniem 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. W tym celu uruchom następujące polecenie w każdym węźle:
Test-NetConnection <FQDN of cloudagent> -Port <Cloudagent port - default 65000>
Pakiet pobierania usługi AKS w usłudze Azure Stack HCI kończy się niepowodzeniem z powodu błędu: "msft.sme.aks nie można załadować"
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.
Podczas uruchamiania polecenia Set-AksHciRegistration zostanie wyświetlony błąd "Nie można sprawdzić zarejestrowanych dostawców zasobów"
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ę na etapie "Oczekiwanie na ukończenie dołączania azure-arc-onboarding" przed upływem limitu czasu
Uwaga
Ten problem został rozwiązany w wersji z maja 2022 r. i nowszej.
Install-AksHci zawiesza się przed Waiting for azure-arc-onboarding to complete
upływem 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 w wersji (2.7.x).
Az.Accounts 2.7.x
wersje ServicePrincipalSecret
usuwa elementy i CertificatePassword
w PSAzureRmAccount
systemie , 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ć:
- Zainstaluj
Az.Accounts
wersję modułów programu PowerShell (>= 2.7.0). Set-AksHciRegistration
przy użyciu jednostki usługi.Install-AksHci
.
Oczekiwane zachowanie:
- Instalacja usługi AKS w usłudze Azure Stack HCI zawiesza się pod adresem
Waiting for azure-arc-onboarding to complete
. Azure-arc-onboarding
zasobniki przechodzą w pętlę awarii.- 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
Podczas instalacji ten błąd pojawia się: "Nie można utworzyć maszyny wirtualnej urządzenia: nie można utworzyć maszyny wirtualnej: błąd rpc = nieznany desc = Wystąpił wyjątek. (Błąd ogólny)]"
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 również 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.
Po nieudanej instalacji uruchomienie polecenia Install-AksHci nie działa
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 zakończy się niepowodzeniem przy użyciu polecenia Install-AksHci, przed ponownym uruchomieniem Install-AksHci
należy uruchomić polecenie Uninstall-AksHci.
Błąd: "Nie można uzgodnić sieci wirtualnej" lub "Błąd: Instalacja-moc nie powiodła się z powodu błędu — wyjątek [[Moc] Ta maszyna nie wydaje się być skonfigurowana do wdrożenia]"
Te błędy można wyzwolić po uruchomieniu Install-AksHci
bez wcześniejszego uruchomienia 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 usługi AKS-HCI, instalując usługę AKS-HCI przy użyciu programu PowerShell.
Polecenie Set-AksHciConfig kończy się niepowodzeniem z powodu błędu "GetCatalog zwrócony przez wywołanie interfejsu API: ... proxyconnect tcp: tls: pierwszy rekord nie wygląda jak uzgadnianie protokołu TLS"
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 z serwerem proxy, ale często potrzebne są obie wartości do współużytkowania tego samego adresu URL prefiksu HTTP.
Jeśli tak może być w twoim środowisku, spróbuj wykonać następujące kroki zaradcze:
- Zamknij okno programu PowerShell i otwórz nowe.
New-AksHciNetworkSetting
Uruchom ponownie polecenia cmdlet iNew-AksHciProxySetting
. Podczas uruchamianiaNew-AksHciProxySetting
-https
programu ustaw parametr z tą samą wartością adresu URL poprzedzoną prefiksem HTTP, która została ustawiona na wartość-http
.- Uruchom
Set-AksHciConfig
i kontynuuj.
W przypadku wdrażania usługi AKS w usłudze Azure Stack HCI z błędnie skonfigurowaną siecią wdrażanie jest limit czasu wdrożenia w różnych punktach
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 błędna 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 błędna 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.com
ale 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:
- Wyślij polecenie ping do docelowej nazwy DNS: ping
msk8s.api.cdp.microsoft.com
. - Jeśli otrzymasz odpowiedź z powrotem i nie upłynął limit czasu, podstawowa ścieżka sieciowa działa.
- Jeśli upłynął limit czasu połączenia, może wystąpić przerwa 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.
Polecenie Set-AksHciConfig kończy się niepowodzeniem z błędami usługi WinRM, ale pokazuje, że usługa WinRM jest poprawnie skonfigurowana
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.
Rotacja dziennika agenta moc kończy się niepowodzeniem
Oczekuje się, że agenci moc zachowają tylko ostatnie 100 dzienników agentów. Powinny one usuwać starsze dzienniki. Jednak rotacja dziennika nie odbywa się, a dzienniki ciągle gromadzą się zużywające miejsce na dysku.
Aby odtworzyć: Install AksHci
i mieć uruchomiony klaster do czasu przekroczenia liczby dzienników agenta 100. W momencie utworzenia nth dziennika agenci powinni usunąć n-100-ty dziennik, jeśli istnieją.
W celu rozwiązania tego problemu:
Zmodyfikuj pliki logconf agenta w chmurze i agentów węzłów. Konfiguracja dziennika agenta w chmurze znajduje się w:
(Get-MocConfig).cloudConfigLocation+"\log\logconf"
.
Konfiguracja dziennika agenta węzła znajduje się w lokalizacji:
(Get-MocConfig).cloudConfigLocation+"\log\logconf"
.Zmień wartość wartości Limit na 100 i Slots na 100 i zapisz pliki konfiguracji.
Uruchom ponownie agenta w chmurze i agentów węzłów, aby zarejestrować te zmiany.
Te kroki rozpoczynają rotację dziennika dopiero po wygenerowaniu 100 nowych dzienników na podstawie ponownego uruchomienia 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.
Agent chmury może zakończyć się niepowodzeniem podczas używania nazw ścieżek z spacjami w nich
W przypadku używania polecenia Set-AksHciConfig do określenia -imageDir
parametrów , -workingDir
, -cloudConfigLocation
lub -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
.
Błąd: "Instalacja-moc nie powiodła się z powodu błędu — wyjątek [CloudAgent jest niemożliwy do osiągnięcia. Moc CloudAgent może być niedostępny z następujących powodów]"
Ten błąd może wystąpić w przypadku błędnej konfiguracji infrastruktury.
Aby usunąć ten błąd, wykonaj następujące kroki:
Sprawdź konfigurację i ustawienia bramy serwera DNS hosta:
- 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
- Aby sprawdzić, czy twój adres IP i konfiguracja bramy są poprawne, uruchom polecenie
ipconfig/all
. - Spróbuj wysłać polecenie ping do bramy IP i serwera DNS.
- Upewnij się, że serwer DNS jest skonfigurowany poprawnie. Aby sprawdzić adres serwera DNS hosta, uruchom następujące polecenie:
Sprawdź usługę CloudAgent, aby upewnić się, że jest uruchomiona:
- Wyślij polecenie ping do usługi CloudAgent, aby upewnić się, że jest ona osiągalna.
- 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>
- 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>
- Aby sprawdzić, czy usługa klastra jest uruchomiona dla klastra trybu failover, możesz również uruchomić następujące polecenie:
Get-ClusterGroup -Name (Get-AksHciConfig).Moc['clusterRoleName']
Błąd: "Instalacja-Moc nie powiodła się. Wyjątek [Zazwyczaj wskazuje to, że wystąpił problem podczas rejestrowania nazwy zasobu jako obiektu komputera z kontrolerem domeny i/lub serwerem DNS. Sprawdź, czy obiekt komputera klastra ma uprawnienia do tworzenia obiektu komputera na kontrolerze domeny. Sprawdź kontroler domeny i dzienniki DNS pod kątem powiązanych komunikatów o błędach.
Zazwyczaj oznacza to, że obiekt nazwy klastra (CNO) reprezentujący podstawowy klaster trybu failover w usługach domena usługi Active Directory (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ć go o przyznanie uprawnień obiektu CNO do jednostki organizacyjnej lub wstępne przygotowanie VCO dla ogólnej usługi klastra agenta w chmurze.
Jeśli jesteś administratorem domeny, nadal istnieje możliwość, że jednostka organizacyjna lub kontener 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.
- Przejdź do Użytkownicy i komputery usługi Active Directory.
- Kliknij prawym przyciskiem myszy jednostki organizacyjnej lub kontener, w którym znajduje się klaster.
- Wybierz pozycję Deleguj kontrolkę... , aby otworzyć Kreatora delegowania kontrolek.
- Kliknij przycisk Dalej> kliknij przycisk Dodaj..., aby otworzyć okno Wybieranie użytkowników, komputerów lub grup.
- Wybierz wybraną grupę lub użytkowników, którym chcesz delegować kontrolę > , kliknij przycisk OK.
- Wybierz pozycję Utwórz zadanie niestandardowe, aby delegować> pozycję Kliknij dalej , aby przejść do strony Typ obiektu usługi Active Directory.
- Wybierz tylko następujące obiekty w folderze> Select Computer objects Select Select Computer objects Select Create selected objects> in this folder and Delete selected objects in this folder (Usuń wybrane obiekty w tym folderze> Kliknij przycisk Dalej), aby przejść do strony Uprawnienia.
- Wybierz pozycję Utwórz wszystkie obiekty podrzędne i usuń wszystkie obiekty podrzędne z listy uprawnień > Kliknij przycisk Zakończ dalej>
Jeśli ponowna instalacja zakończy się niepowodzeniem, 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 przycisk 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.
Błąd: Instalacja-AksHci kończy się niepowodzeniem z błędem "Install-Moc nie powiodło się. Dzienniki są dostępne C:\Users\xxx\AppData\Local\Temp\v0eoltcc.a10'
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
.
Wdrożenie programu PowerShell nie sprawdza dostępnej pamięci przed utworzeniem nowego klastra obciążenia
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. Ta awaria nie jest obecnie obsługiwana pomyślnie, 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ą.
Podczas uruchamiania polecenia Set-AksHciRegistration pojawia się błąd "Nie można uzyskać tokenu"
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.
Błąd: "Oczekiwanie na gotowość zasobnika "Operator chmury"
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, sprawdzając bramę i serwer DNS wykazały, że działają prawidłowo. Nie znaleziono żadnych konfliktów adresów IP lub MAC. Dzienniki nie pokazały puli adresów VIP. Wystąpiło ograniczenie ściągnięcia obrazu kontenera przy użyciu sudo docker pull ecpacr.azurecr.io/kube-vip:0.3.4
tego, które zwróciło limit czasu protokołu Transport Layer Security (TLS) zamiast nieautoryzowanego.
Aby rozwiązać ten problem, wykonaj następujące czynności:
- Rozpocznij wdrażanie klastra.
- 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>
- Zmień ustawienie maksymalnej jednostki transmisji (MTU). Nie wahaj się wprowadzać zmiany; 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
- 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.
Błąd: "Instalacja-Moc nie powiodła się z powodu błędu — wyjątek [Nie można utworzyć roli ogólnej klastra trybu failover]."
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 ClusterAndClient
się . 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.
Polecenie cmdlet Enable-AksHciArcConnection generuje ostrzeżenie wskazujące, że polecenie GetServicePrincipals ma niewystarczające uprawnienia do włączania lokalizacji niestandardowych
Enable-AksHciArcConnection
program może połączyć klaster usługi AKS z platformą Azure, ale wyświetla następujące ostrzeżenie, gdy klient używa jednostki usługi do uwierzytelniania:
WARNING: Error occurred while executing GetServicePrincipals
Code: Authorization_RequestDenied
Message: Insufficient privileges to complete the operation.
RequestId: <removed>
DateTimeStamp: <removed>
HttpStatusCode: Forbidden
HttpStatusDescription: Forbidden
HttpResponseStatus: Completed
WARNING: Custom locations has not been enabled on the AKS-HCI cluster. To enable custom locations manually, visit aka.ms/enable-custom-location
Bieżące zachowanie dołączania w usłudze Arc polega na domyślnym włączeniu lokalizacji niestandardowych. Aby włączyć lokalizacje niestandardowe, akcja GetServicePrincipals jest wykonywana w kontekście zalogowanego użytkownika platformy Azure. Jeśli użytkownik (lub nazwa SPN) nie ma wystarczających uprawnień, aby można było to zrobić, polecenie wyświetli ostrzeżenie, że te uprawnienia nie istnieją, a w związku z tym funkcja Lokalizacje niestandardowe nie zostanie włączona.
Jeśli nie chcesz, aby lokalizacje niestandardowe były włączone, możesz bezpiecznie zignorować to ostrzeżenie, ponieważ nie ma to wpływu na dołączanie klastra do usługi Arc. Z drugiej strony, jeśli chcesz włączyć lokalizacje niestandardowe, musisz przyznać niezbędne uprawnienia użytkownikowi (lub SPN).
Następne kroki
- Omówienie rozwiązywania problemów
- Znane problemy z programem Windows Admin Center
- 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.