Lösa problem och fel under en AKS Arc-installation

Det här felmeddelandet visas när Install-AksHci har körts.

Om du inte använder Private Link kan du lösa problemet med hjälp av följande steg:

1. Öppna PowerShell och kör Uninstall-AksHci.
2. Öppna Azure Portal och gå till den resursgrupp som du använde när du körde Install-AksHci.
3. Sök efter anslutna klusterresurser som visas i ett frånkopplat tillstånd och inkludera ett namn som visas som ett slumpmässigt genererat GUID.
4. Ta bort dessa klusterresurser.
5. Stäng PowerShell-sessionen och öppna den nya sessionen innan du kör Install-AksHci den igen.

Det här felet kan bero på att installationsprocessen försöker bryta mot en Azure-princip som har angetts för Azure-prenumerationen eller resursgruppen som angavs under Azure Arc-registreringsprocessen. Det här felet kan inträffa för användare som har definierat Azure-principer på prenumerations- eller resursgruppsnivå och sedan försöka installera AKS på Azure Local som bryter mot en Azure-princip.

Lös problemet genom att läsa felmeddelandet för att förstå vilken Azure Policy som angetts av Azure-administratören och ändra sedan Azure-principen genom att göra ett undantag från Azure-principen. Mer information om principundantag finns i Azure Policy-undantagsstruktur.

En tidigare installerad funktion kvarstår i ett feltillstånd och har inte rensats. Du kan se följande fel:

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]

Eller så kan du se:

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]

Lös problemet genom att rensa klusterrollen manuellt. Du kan ta bort resursen från klusterhanteraren för redundanskluster genom att köra följande PowerShell-cmdlet: Remove-ClusterResource -name <resource name>.

Cmdleten Install-AksHci misslyckas med "GetRelease-fel som returneras av API-anropet: Filnedladdningsfel: Hash-felmatchning."

1. Öppna PowerShell och kör Uninstall-AksHci.
2. Försök installera igen.
3. Om problemet kvarstår använder du parametern -concurrentDownloads med Set-AksHciConfig och anger ett tal som är lägre än standardvärdet 10 innan du försöker installera igen. Att minska antalet samtidiga nedladdningar kan hjälpa känsliga nätverk att slutföra stora filnedladdningar. Den här parametern är en förhandsversionsfunktion.

Efter distributionen visade AKS-rapporten en misslyckad status för fakturering när du startade om de lokala Azure-noderna.

Lös problemet genom att följa anvisningarna för att rotera token manuellt och starta om KMS-plugin-programmet.

När du har kört Install-AksHci stoppades installationen och följande felmeddelande visades:

\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.]

Det finns flera orsaker till varför en installation kan misslyckas med waiting for API server felet.

I följande avsnitt beskrivs möjliga orsaker och lösningar för det här felet.

Orsak 1: Felaktig KONFIGURATION av IP-gateway Om du använder statiska IP-adresser och du får följande felmeddelande kontrollerar du att konfigurationen för IP-adressen och gatewayen är korrekt.

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 [ ]

Kör följande kommando för att kontrollera om du har rätt konfiguration för din IP-adress och gateway:

ipconfig /all

Bekräfta konfigurationen i konfigurationsinställningarna som visas. Du kan också försöka pinga IP-gatewayen och DNS-servern.

ping <DNS server>

Om dessa metoder inte fungerar använder du New-AksHciNetworkSetting för att ändra konfigurationen.

Orsak 2: Felaktig DNS-server Om du använder statiska IP-adresser kontrollerar du att DNS-servern är korrekt konfigurerad. Om du vill kontrollera värdens DNS-serveradress använder du följande kommando:

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

Kontrollera att DNS-serveradressen är samma som den adress som användes när du körde New-AksHciNetworkSetting genom att köra följande kommando:

Get-MocConfig

Om DNS-servern har konfigurerats felaktigt installerar du om AKS på Azure Local med rätt DNS-server. Mer information finns i Starta om, ta bort eller installera om Azure Kubernetes Service på Azure Local .

Problemet löstes när konfigurationen togs bort och den virtuella datorn startades om med en ny konfiguration.

Install-AksHci misslyckades med det här felet eftersom en annan process har mocstack.cabåtkomst till .

Lös problemet genom att stänga alla öppna PowerShell-fönster och öppna sedan ett nytt PowerShell-fönster igen.

Det går inte att komma åt filen eftersom den används av en annan process.

Du kan lösa det här problemet genom att starta om PowerShell-sessionen. Stäng PowerShell-fönstret och försök installera AksHci igen.

Install-AksHci misslyckades med det här felet eftersom IP-poolintervallen i AKS på Azure Local-konfigurationen var inaktiverade med 1 i CIDR och kan orsaka att CloudAgent kraschar. Om du till exempel har undernätet 10.0.0.0/21 med ett adressintervall på 10.0.0.0–10.0.7.255 och sedan använder startadressen 10.0.0.1 eller slutadressen 10.0.7.254 kommer CloudAgent att krascha.

Du kan lösa det här problemet genom att köra New-AksHciNetworkSetting och använda andra giltiga IP-adressintervall för din VIP-pool och Kubernetes-nodpool. Kontrollera att de värden du använder inte är inaktiverade med 1 i början eller slutet av adressintervallet.

När du kör Install-AksHci i en installation med en nod fungerade installationen, men när du konfigurerade redundansklustret misslyckas installationen med felmeddelandet. Men när molnagenten pingades visade det sig att CloudAgent kunde nås.

Kontrollera att alla noder kan matcha CloudAgents DNS genom att köra följande kommando på varje nod:

Resolve-DnsName <FQDN of cloudagent>

När steget ovan lyckas på noderna kontrollerar du att noderna kan nå CloudAgent-porten för att kontrollera att en proxy inte försöker blockera anslutningen och att porten är öppen. Det gör du genom att köra följande kommando på varje nod:

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

Felet beror på ett fel vid nedladdning.

Om du får det här felet bör du använda den senaste versionen av Microsoft Edge eller Google Chrome och försöka igen.

Det här felet visas när du har kört Set-AksHciRegistration i en AKS på En lokal Azure-installation. Felet anger att Kubernetes-resursprovidrar inte är registrerade för den klientorganisation som för närvarande är inloggad.

Lös problemet genom att köra antingen Azure CLI eller PowerShell-stegen nedan:

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

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

Registreringen tar cirka 10 minuter att slutföra. Om du vill övervaka registreringsprocessen använder du följande kommandon.

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 låser sig Waiting for azure-arc-onboarding to complete innan tidsgränsen nås när:

• Ett huvudnamn för tjänsten används i AKS för lokal Azure-registrering (Set-AksHciRegistration).
• Az.Accounts PowerShell-modulversion (2.7.x) installerad.

Az.Accounts 2.7.x versioner tar bort ServicePrincipalSecret och CertificatePassword i PSAzureRmAccount, som används av AKS på Azure Local för Azure Arc-registrering.

Så här återskapar du:

1. Installera Az.Accounts PowerShell-modulversionen (>= 2.7.0).
2. Set-AksHciRegistration med hjälp av tjänstens huvudnamn.
3. Install-AksHci.

Förväntat beteende:

1. AKS på Azure Local-installationen låser sig på Waiting for azure-arc-onboarding to complete.
2. Azure-arc-onboarding poddar hamnar i kraschloopen.
3. Poddfelet Azure-arc-onboarding med följande fel:
   Starting onboarding process ERROR: variable CLIENT_SECRET is required

Lös problemet så här:

Avinstallera Az.Accounts-moduler med version 2.7.x. kör följande cmdlet:

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

Det här felet uppstår när Azure Local inte har någon princip. Anslutningsstatusen i klustret kan visa att den är ansluten, men händelseloggen visar varningsmeddelandet att Azure Local's subscription is expired, run Sync-AzureStackHCI to renew the subscription.

Du kan lösa det här felet genom att kontrollera att klustret har registrerats med Azure med hjälp av PowerShell-cmdleten Get-AzureStackHCI som är tillgänglig på datorn. På instrumentpanelen i Windows Admin Center visas även statusinformation om klustrets Azure-registrering.

Om klustret redan är registrerat bör du granska fältet LastConnected i utdata för Get-AzureStackHCI. Om fältet visar att det har gått mer än 30 dagar ska du försöka lösa problemet med hjälp av cmdleten Sync-AzureStackHCI.

Du kan också kontrollera om varje nod i klustret har den licens som krävs med hjälp av följande cmdlet:

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

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

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

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

Om problemet inte har lösts efter att du har kört cmdleten Sync-AzureStackHCI bör du kontakta Microsoft-supporten.

Det här problemet beror på att en misslyckad installation kan resultera i läckta resurser som måste rensas innan du kan installera igen.

Om installationen inte kan användas med Install-AksHci bör du köra Uninstall-AksHci innan du kör Install-AksHci den igen.

Du kan utlösa dessa fel när du kör Install-AksHci utan att köra Set-AksHciConfig först.

Lös felet genom att köra uninstall-akshci och stänga alla PowerShell-fönster. Öppna en ny PowerShell-session och starta om din AKS på Azure Local-installationsprocessen genom att följa installationen av AKS på Azure Local med hjälp av PowerShell.

Set-AksHciConfig PowerShell-cmdleten misslyckas med felet:

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

Om du använder AKS med en proxyserver kan du ha använt fel URL när du angav det nödvändiga HTTPS-proxy-URL-värdet. VÄRDENA FÖR HTTP-proxy-URL och HTTPS-proxy-URL krävs båda när du konfigurerar AKS med en proxyserver, men det är vanligt att båda värdena behöver dela samma HTTP-prefixerade URL.

Om detta kan vara fallet i din miljö kan du prova följande åtgärdssteg:

1. Stäng PowerShell-fönstret och öppna ett nytt.
2. New-AksHciNetworkSetting Kör cmdletarna och New-AksHciProxySetting igen. När du kör New-AksHciProxySettinganger du parametern -https med samma HTTP-prefixerade URL-värde som du angav för -http.
3. Kör Set-AksHciConfig och fortsätt.

När du distribuerar AKS på Azure Local kan distributionen överskrida tidsgränsen vid olika tidpunkter i processen beroende på var felkonfigurationen inträffade. Du bör granska felmeddelandet för att fastställa orsaken och var den inträffade.

I följande fel finns till exempel den punkt där felkonfigurationen inträffade i 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"}

Detta anger att den fysiska lokala Azure-noden kan matcha namnet på nedladdnings-URL:en, msk8s.api.cdp.microsoft.com, men noden kan inte ansluta till målservern.

För att lösa det här problemet måste du ta reda på var uppdelningen inträffade i anslutningsflödet. Här följer några steg för att försöka lösa problemet från den fysiska klusternoden:

1. Pinga målets DNS-namn: ping msk8s.api.cdp.microsoft.com.
2. Om du får ett svar tillbaka och ingen tidsgräns fungerar den grundläggande nätverkssökvägen.
3. Om anslutningen överskrider tidsgränsen kan det uppstå en paus i datasökvägen. Mer information finns i kontrollera proxyinställningar. Eller så kan det finnas en paus i retursökvägen, så du bör kontrollera brandväggsreglerna.

När du kör Set-AksHciConfig kan följande fel uppstå:

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.

Det här felet uppstår vanligtvis på grund av en ändring i användarens säkerhetstoken (på grund av en ändring i gruppmedlemskapet), en lösenordsändring eller ett utgånget lösenord. I de flesta fall kan problemet åtgärdas genom att logga ut från datorn och logga in igen. Om det fortfarande misslyckas kan du skapa ett problem på GitHub AKS Azure Local-problem.

Moc-agenter förväntas endast behålla de senaste 100 agentloggarna. De ska ta bort de äldre loggarna. Loggrotationen sker dock inte och loggarna får hela tiden ackumulerat diskutrymme.

Så här återskapar du: Install AksHci och har ett kluster igång tills antalet agentloggar överstiger 100. När den n:e loggen skapas förväntas agenterna ta bort den n-100:e loggen, om de finns.

Så här löser du problemet:

1. Ändra molnagentens och nodagenternas logconf-filer. Logconfig för molnagenten finns på:
   (Get-MocConfig).cloudConfigLocation+"\log\logconf".
   Node agent logconfig finns på:
   (Get-MocConfig).cloudConfigLocation+"\log\logconf".

2. Ändra värdet för Gräns till 100 och Fack till 100 och spara konfigurationsfilerna.

3. Starta om molnagenten och nodagenterna för att registrera ändringarna.

De här stegen startar loggrotationen först efter att 100 nya loggar har genererats från agentens omstart. Om det redan finns n agentloggar vid tidpunkten för omstarten startar loggrotationen först efter att n+100 loggar har genererats.

När du använder Set-AksHciConfig för att ange -imageDir, -workingDir, -cloudConfigLocationeller -nodeConfigLocation parametrar med ett sökvägsnamn som innehåller ett blankstegstecken, till exempel D:\Cloud Share\AKS HCI, kommer molnagentens klustertjänst inte att börja med följande (eller liknande) felmeddelande:

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'

Du kan undvika det här problemet genom att använda en sökväg som inte innehåller blanksteg, C:\CloudShare\AKS-HCItill exempel .

Det här felet kan uppstå om infrastrukturkonfigurationen är felaktig.

Åtgärda felet med följande steg:

1. Kontrollera konfigurations- och gatewayinställningarna för värd-DNS-servern:

   1. Bekräfta att DNS-servern är korrekt konfigurerad. Kontrollera värdens DNS-serveradress genom att köra följande kommando:

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

   2. Kör kommandot ipconfig/allför att kontrollera om ip-adressen och gatewaykonfigurationen är korrekta.
   3. Försök att pinga IP-gatewayen och DNS-servern.

2. Kontrollera CloudAgent-tjänsten för att kontrollera att den körs:

   1. Pinga CloudAgent-tjänsten för att säkerställa att den kan nås.
   2. Kontrollera att alla noder kan matcha CloudAgents DNS genom att köra följande kommando på varje nod:

      Resolve-DnsName <FQDN of cloudagent>
      

   3. När föregående steg lyckas på noderna kontrollerar du att noderna kan nå CloudAgent-porten för att försäkra dig om att en proxy inte försöker blockera anslutningen och att porten är öppen. Gör detta genom att köra följande kommando på varje nod:

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

   4. Om du vill kontrollera om klustertjänsten körs för ett redundanskluster kan du också köra följande kommando:

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

Detta indikerar vanligtvis att klusternamnsobjektet (CNO) som representerar ditt underliggande redundanskluster i Active Directory-domän Services (AD DS) inte har behörighet att skapa ett virtuellt datorobjekt (VCO) i organisationsenheten (OU) eller i containern där klustret finns.

Om du inte är domänadministratör kan du be en att bevilja CNO-behörigheter till organisationsenheten eller förinstallera en VCO för molnagentens allmänna klustertjänst.

Om du är domänadministratör är det fortfarande möjligt att din organisationsenhet eller container inte har de behörigheter som krävs. Till exempel kan tvingande läge, som introducerades i KB5008383, vara aktiverat i Active Directory. Prova följande innan du försöker installera om.

1. Gå till Active Directory - användare och datorer.
2. Högerklicka på organisationsenheten eller containern där klustret finns.
3. Välj Delegera kontroll... för att öppna guiden Delegering av kontroll.
4. Klicka på Nästa> klicka på Lägg till... för att öppna fönstret Välj användare, Datorer eller Grupper .
5. Välj grupp eller användare som du vill delegera kontrollen > till Klicka på OK.
6. Välj Skapa en anpassad uppgift för att delegera> Klicka på Nästa för att gå vidare till sidan Active Directory-objekttyp .
7. Välj Endast följande objekt i mappen> Välj datorobjekt> Välj Skapa markerade objekt i den här mappen och Ta bort markerade objekt i den här mappen> Klicka på Nästa för att gå vidare till sidan Behörigheter.
8. Välj Skapa alla underordnade objekt och ta bort alla underordnade objekt i listan med behörigheter > Klicka på Nästa>slutför

Om en ominstallation misslyckas gör du ett nytt försök med följande ändringar i steg 7 och 8:

• Steg 7: Välj den här mappen, befintliga objekt i den här mappen och skapa nya objekt i den här mappen> Klicka på Nästa.
• Steg 8: Välj Läs, Skriv, Skapa alla underordnade objekt och Ta bort alla underordnade objekt i listan med behörigheter > Klicka på Nästa> klicka på Slutför.

Du kan få det här felet när du kör Install-AksHci.

Du kan få mer information genom att köra $error = Install-AksHci och sedan $error[0].Exception.InnerException.

Aks-Hci PowerShell-kommandona verifierar inte det tillgängliga minnet på värdservern innan kubernetes-noder skapas. Det här problemet kan leda till minnesöverbelastning och virtuella datorer som inte startas. Det här felet hanteras för närvarande inte korrekt och distributionen slutar svara utan något tydligt felmeddelande.

Om du har en distribution som slutar svara öppnar du Loggboken och söker efter ett Hyper-V-relaterat felmeddelande som anger att det inte finns tillräckligt med minne för att starta den virtuella datorn.

Det här felet kan inträffa när du har flera klienter på ditt Azure-konto.

Använd $tenantId = (Get-AzContext).Tenant.Id för att ange rätt klientorganisation. Inkludera sedan den här klientorganisationen som en parameter när du kör Set-AksHciRegistration.

När du försökte distribuera ett AKS-kluster på en virtuell Azure-dator fastnade installationen på Waiting for pod 'Cloud Operator' to be ready...och misslyckades sedan och tidsgränsen överskrids efter två timmar. Försök att felsöka genom att kontrollera gatewayen och DNS-servern visade att de fungerade korrekt. Det går inte att hitta några ip- eller MAC-adresskonflikter. Loggarna visade inte VIP-poolen. Det fanns en begränsning för att hämta containeravbildningen med hjälp av sudo docker pull ecpacr.azurecr.io/kube-vip:0.3.4 som returnerade en TLS-tidsgräns (Transport Layer Security) i stället för obehörig.

Lös problemet genom att utföra följande steg:

1. Börja distribuera klustret.
2. När klustret distribueras ansluter du till den virtuella datorn för hanteringskluster via SSH enligt nedan:

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

3. Ändra inställningen för maximal överföringsenhet (MTU). Tveka inte att göra ändringen; Om du gör ändringen för sent misslyckas distributionen. Om du ändrar MTU-inställningen kan du avblockera containeravbildningshämtningen.

sudo ifconfig eth0 mtu 1300

4. Om du vill visa status för dina containrar kör du följande kommando:

sudo docker ps -a

När du har slutfört de här stegen bör containeravbildningshämtningen avblockeras.

Det här felet anger att molntjänstens IP-adress inte är en del av klusternätverket och inte matchar något av de klusternätverk som har client and cluster communication rollen aktiverad.

Lös problemet genom att köra Get-ClusterNetwork där Role är lika med ClusterAndClient. På en av klusternoderna väljer du sedan namn, adress och adressmask för att kontrollera att IP-adressen för parametern -cloudServiceIP New-AksHciNetworkSetting matchar ett av de nätverk som visas.

Enable-AksHciArcConnection kan ansluta ett AKS-kluster till Azure, men den visar följande varning när kunden använder tjänstens huvudnamn för autentisering:

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 on Azure Local cluster. To enable custom locations manually, visit aka.ms/enable-custom-location

Det aktuella beteendet för Arc-registrering är att aktivera anpassade platser som standard. För att aktivera anpassade platser utförs åtgärden GetServicePrincipals i kontexten för den inloggade Azure-användaren. Om användaren (eller SPN) inte har tillräcklig behörighet för att kunna göra detta utfärdar kommandot en varning om att dessa behörigheter inte finns och därför aktiveras inte funktionen Anpassade platser.

Om du inte vill att anpassade platser ska aktiveras kan du ignorera den här varningen på ett säkert sätt eftersom detta inte påverkar klusterregistreringen till Arc. Om du däremot behöver aktivera anpassade platser måste du ge användaren (eller SPN) nödvändiga behörigheter.

Nästa steg

• Felsökningsöversikt
• Kända problem med Windows Admin Center
• Felsöka Kubernetes-kluster

Om du fortsätter att stöta på problem när du använder AKS Arc kan du skicka buggar via GitHub.