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

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

Om du inte använder Private Link använder du följande steg för att lösa problemet:

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 orsakas av 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 Stack HCI som bryter mot en Azure Policy.

Lös problemet genom att läsa felmeddelandet för att förstå vilka Azure Policy som angetts av Azure-administratören har brutits och ändra sedan Azure-principen genom att göra ett undantag till 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 växling vid fel 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-matchningsfel".

1. Öppna PowerShell och kör Uninstall-AksHci.
2. Försök att 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örhandsgranskningsfunktion.

När du startade om Azure Stack HCI-noderna efter distributionen visade AKS-rapporten en misslyckad status för fakturering.

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 felet waiting for API server .

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 fick 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. Kontrollera värdens DNS-serveradress genom att köra följande kommando:

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

Kontrollera att DNS-serveradressen är samma som adressen 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 Stack HCI med rätt DNS-server. Mer information finns i Starta om, ta bort eller installera om Azure Kubernetes Service på Azure Stack HCI .

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 Install-AksHci igen.

Install-AksHci misslyckades med det här felet eftersom IP-poolintervallen i AKS på Azure Stack HCI-konfigurationen var inaktiverade av 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 undvika 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 som du använder inte är inaktiverade med 1 i början eller slutet av adressintervallet.

När du kör Install-AksHci på en konfiguration med en nod fungerade installationen, men när du konfigurerade redundansklustret misslyckas installationen med felmeddelandet. När molnagenten pingades visade det dock 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 den här 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>

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å Azure Stack HCI-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. Använd följande kommandon för att övervaka registreringsprocessen.

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

• Ett huvudnamn för tjänsten används i AKS på Azure Stack HCI-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 Stack HCI 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 ett huvudnamn för tjänsten.
3. Install-AksHci.

Förväntat beteende:

1. AKS på Azure Stack HCI-installationen låser sig på Waiting for azure-arc-onboarding to complete.
2. Azure-arc-onboarding poddar hamnar i en kraschloop.
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 Stack HCI är utan princip. Anslutningsstatusen i klustret kan visa att den är ansluten, men händelseloggen visar varningsmeddelandet som Azure Stack HCI's subscription is expired, run Sync-AzureStackHCI to renew the subscription.

Lös det här felet genom att kontrollera att klustret är registrerat 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 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

Om problemet inte har lösts när du har kört cmdleten Sync-AzureStackHCI bör du kontakta Microsofts support.

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 misslyckas med Install-AksHci bör du köra Uninstall-AksHci innan du kör Install-AksHci igen.

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

Lös felet genom att köra uninstall-akshci och stänga alla PowerShell-fönster. Öppna en ny PowerShell-session och starta om AKS-HCI-installationsprocessen genom att installera AKS-HCI 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-prefix-URL.

Om så 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-prefixade URL-värde som du angav för -http.
3. Kör Set-AksHciConfig och fortsätt.

När du distribuerar AKS på Azure Stack HCI 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 det 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 Azure Stack HCI-noden kan matcha namnet på nedladdnings-URL:en, msk8s.api.cdp.microsoft.commen 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 dns-målets namn: ping msk8s.api.cdp.microsoft.com.
2. Om du får ett svar tillbaka och ingen timeout fungerar den grundläggande nätverkssökvägen.
3. Om anslutningen överskrider tidsgränsen kan datasökvägen brytas. Mer information finns i kontrollera proxyinställningarna. 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 HCI-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.

Återskapa: Install AksHci och ha ett kluster igång tills antalet agentloggar överskrider 100. När 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 molnagent 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 Platser till 100 och spara konfigurationsfilerna.

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

De här stegen startar loggrotationen först när 100 nya loggar har genererats från agentens omstart. Om det redan finns n agentloggar vid tidpunkten för omstarten startar loggrotationen först när 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'

Om du vill kringgå det här problemet använder du 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. Kontrollera om IP-adressen och gatewaykonfigurationen är korrekta genom att köra kommandot ipconfig/all.
   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 Domain 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 organisationsenheten eller containern inte har de behörigheter som krävs. Tvingande läge, som introducerades i KB5008383, kan till exempel 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 du skapar Kubernetes-noder. Det här problemet kan leda till minnesöverbelastning och virtuella datorer som inte startar. 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. Ta sedan med 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 och tidsgränsen översgick sedan efter två timmar. Försök att felsöka genom att kontrollera gatewayen och DNS-servern visade att de fungerade korrekt. Det finns inga kontroller för 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-timeout (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 har distribuerats ansluter du till den virtuella datorn med hanteringsklustret 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 avblockerar du hämtningen av containeravbildningen.

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 hämtningen av containeravbildningen 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 ClusterAndClientlika med . På en av klusternoderna väljer du sedan namn, adress och adressmask för att kontrollera att IP-adressen för parametern -cloudServiceIPNew-AksHciNetworkSetting matchar ett av de nätverk som visas.

Nästa steg

• Felsökningsöversikt
• Windows Admin Center kända problem
• 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.