Beheben von Problemen und Fehlern während einer AKS Arc-Installation

Diese Fehlermeldung wird gezeigt, nachdem Install-AksHci ausgeführt wurde.

Wenn Sie keinen privaten Link verwenden, führen Sie die folgenden Schritte aus, um dieses Problem zu beheben:

1. Öffnen Sie PowerShell, und führen Sie Uninstall-AksHci aus.
2. Öffnen Sie das Azure-Portal, und navigieren Sie zur Ressourcengruppe, die Sie beim Ausführen von Install-AksHci verwendet haben.
3. Suchen Sie nach verbundenen Clusterressourcen, die im Zustand Getrennt angezeigt werden, und fügen Sie einen Namen ein, der als zufällig generierte GUID angezeigt wird.
4. Löschen Sie diese Clusterressourcen.
5. Schließen Sie die PowerShell-Sitzung, und öffnen Sie eine neue Sitzung, bevor Sie Install-AksHci erneut ausführen.

Dieser Fehler kann durch den Installationsvorgang verursacht werden, der versucht, eine Azure-Richtlinie zu verletzen, die für das Azure-Abonnement oder die Ressourcengruppe festgelegt wurde, die während des Azure Arc-Onboardingprozesses bereitgestellt wurde. Dieser Fehler kann für Benutzer auftreten, die Azure-Richtlinien auf Abonnement- oder Ressourcengruppenebene definiert haben, und dann versuchen, AKS auf Azure Local zu installieren, das gegen eine Azure-Richtlinie verstößt.

Um dieses Problem zu beheben, lesen Sie die Fehlermeldung, um zu verstehen, welche Von Ihrem Azure-Administrator festgelegte Azure-Richtlinie verletzt wurde, und ändern Sie dann die Azure-Richtlinie, indem Sie eine Ausnahme zu der Azure-Richtlinie erstellen. Weitere Informationen zu Richtlinienausnahmen finden Sie unter Azure Policy-Ausnahmenstruktur.

Ein zuvor installiertes Feature verbleibt in einem fehlerhaften Zustand und wurde nicht gelöscht. Es wird möglicherweise der folgende Fehler angezeigt:

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]

Oder Sie sehen möglicherweise:

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]

Um dieses Problem zu beheben, bereinigen Sie die Clusterrolle manuell. Sie können die Ressource aus dem Failovercluster-Manager entfernen, indem Sie das folgende PowerShell-Cmdlet ausführen: Remove-ClusterResource -name <resource name>

Das Install-AksHci Cmdlet schlägt mit "GetRelease-Fehler, der vom API-Aufruf zurückgegeben wird: Dateidownloadfehler: Hashkonflikt" fehlschlägt.

1. Öffnen Sie PowerShell, und führen Sie Uninstall-AksHci aus.
2. Versuchen Sie eine Installation erneut.
3. Wenn das Problem weiterhin besteht, verwenden Sie den -concurrentDownloads Parameter mit Set-AksHciConfig , und legen Sie ihn auf eine Zahl niedriger als die Standardeinstellung 10 fest, bevor Sie eine Installation wiederholen. Das Verringern der Anzahl gleichzeitiger Downloads kann sensiblen Netzwerken helfen, große Dateidownloads erfolgreich abzuschließen. Dieser Parameter ist eine Previewfunktion.

Nach der Bereitstellung hat der AKS-Bericht beim Neustart der lokalen Azure-Knoten einen fehlgeschlagenen Status für die Abrechnung angezeigt.

Um dieses Problem zu beheben, befolgen Sie die Anweisungen, um das Token manuell zu rotieren und das KMS-Plug-In neu zu starten.

Nach Ausführen von Install-AksHci wurde die Installation angehalten und die folgende Fehlermeldung angezeigt:

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

Es gibt mehrere Gründe, warum bei einer Installation der Fehler waiting for API server auftreten kann.

Im folgenden Abschnitt werden mögliche Ursachen und Lösungen für diesen Fehler beschrieben.

Grund 1: Falsche IP-Gatewaykonfiguration Wenn Sie statische IP-Adressen verwenden und die folgende Fehlermeldung erhalten haben, vergewissern Sie sich, dass die Konfiguration für die IP-Adresse und das Gateway korrekt ist.

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

Führen Sie den folgenden Befehl aus, um zu überprüfen, ob Sie über die richtige Konfiguration für Ihre IP-Adresse und Ihr Gateway verfügen:

ipconfig /all

Bestätigen Sie die Konfiguration in den angezeigten Konfigurationseinstellungen. Sie können auch versuchen, das IP-Gateway und den DNS-Server zu pingen.

ping <DNS server>

Wenn diese Methoden nicht funktionieren, verwenden Sie New-AksHciNetworkSetting, um die Konfiguration zu ändern.

Grund 2: Falscher DNS-Server Wenn Sie statische IP-Adressen verwenden, vergewissern Sie sich, dass der DNS-Server ordnungsgemäß konfiguriert ist. Überprüfen Sie mit folgendem Befehl die DNS-Serveradresse des Hosts:

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

Vergewissern Sie sich, dass die DNS-Serveradresse mit der Adresse übereinstimmt, die beim Ausführen von New-AksHciNetworkSetting verwendet wird, indem Sie folgenden Befehl ausführen:

Get-MocConfig

Wenn der DNS-Server falsch konfiguriert wurde, installieren Sie AKS auf Azure Local mit dem richtigen DNS-Server neu. Weitere Informationen finden Sie unter Neustarten, Entfernen oder Erneutes Installieren von Azure Kubernetes Service auf Azure Local .

Das Problem wurde behoben, nachdem die Konfiguration gelöscht und die VM mit einer neuen Konfiguration neu gestartet wurde.

Install-AksHci ist mit diesem Fehler fehlgeschlagen, weil ein anderer Prozess auf mocstack.cab zugreift.

Um dieses Problem zu beheben, schließen Sie alle geöffneten PowerShell-Fenster, und öffnen Sie dann erneut ein neues PowerShell-Fenster.

Auf die Datei kann nicht zugegriffen werden, weil sie von einem anderen Prozess verwendet wird.

Sie können dieses Problem beheben, indem Sie Ihre PowerShell-Sitzung neu starten. Schließen Sie das PowerShell-Fenster, und versuchen Sie es erneut mit Install-AksHci.

Install-AksHci fehler mit diesem Fehler, da die in der AKS in der lokalen Azure-Konfiguration bereitgestellten IP-Poolbereiche im CIDR um 1 deaktiviert waren und cloudAgent abstürzte. Wenn Sie beispielsweise das Subnetz 10.0.0.0/21 mit dem Adressbereich 10.0.0.0 bis 10.0.7.255 verwenden und dann die Startadresse 10.0.0.1 oder die Endadresse 10.0.7.254 verwenden, würde dies zu einem Absturz von CloudAgent führen.

Um dieses Problem zu umgehen, führen Sie New-AksHciNetworkSetting aus, und verwenden Sie einen anderen gültigen IP-Adressbereich für Ihren VIP-Pool und Kubernetes-Knotenpool. Stellen Sie sicher, dass die von Ihnen verwendeten Werte am Anfang oder Ende des Adressbereichs nicht um 1 deaktiviert sind.

Beim Ausführen von Install-AksHci bei einem Setup mit einem Knoten war die Installation erfolgreich. Beim Einrichten des Failoverclusters tritt bei der Installation jedoch die Fehlermeldung auf. Beim Pingen des Cloud-Agents (CloudAgent) wurde jedoch ermittelt, dass der Cloud-Agent erreichbar war.

Um sicherzustellen, dass alle Knoten das DNS des Cloud-Agents auflösen können, führen Sie auf jedem Knoten den folgenden Befehl aus:

Resolve-DnsName <FQDN of cloudagent>

Wenn der obige Schritt auf den Knoten erfolgreich ist, vergewissern Sie sich, dass die Knoten den CloudAgent-Port erreichen können. So stellen Sie sicher, dass kein Proxy diese Verbindung blockiert und dass der Port geöffnet ist. Führen Sie zu diesem Zweck den folgenden Befehl auf jedem Knoten aus:

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

Der Fehler stammt aus einem Fehler beim Download.

Wenn diese Fehlermeldung angezeigt wird, sollten Sie die neueste Version von Microsoft Edge oder Google Chrome verwenden und es erneut versuchen.

Dieser Fehler wird angezeigt, nachdem Set-AksHciRegistration in einer AKS auf der lokalen Azure-Installation ausgeführt wurde. Der Fehler weist darauf hin, dass die Kubernetes-Ressourcenanbieter nicht für den aktuell angemeldeten Mandanten registriert sind.

Führen Sie zum Beheben dieses Problems die folgenden Azure CLI- oder PowerShell-Schritte aus:

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

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

Die Registrierung dauert ca. zehn Minuten. Verwenden Sie zum Überwachen des Registrierungsprozesses die folgenden Befehle:

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 bleibt bei Waiting for azure-arc-onboarding to complete hängen, bevor ein Timeout erfolgt, wenn Folgendes zutrifft:

• Ein Dienstprinzipal wird in AKS für die lokale Azure-Registrierung (Set-AksHciRegistration) verwendet.
• Die PowerShell-Modulversion (2.7.x) von Az.Accounts ist installiert.

Az.Accounts 2.7.x Versionen entfernen die ServicePrincipalSecret und CertificatePassword in PSAzureRmAccount, die von AKS auf Azure Local für Azure Arc Onboarding verwendet wird.

Schritte zum Reproduzieren:

1. Installieren Sie die PowerShell-Modulversion von Az.Accounts (>= 2.7.0).
2. Set-AksHciRegistration unter Verwendung eines Dienstprinzipals.
3. Install-AksHci.

Erwartetes Verhalten:

1. Die AKS auf der lokalen Azure-Installation hängt bei Waiting for azure-arc-onboarding to complete.
2. Azure-arc-onboarding befinden sich in einem Absturzschleifenzustand.
3. Für die Azure-arc-onboarding-Pods tritt folgender Fehler auf:
   Starting onboarding process ERROR: variable CLIENT_SECRET is required

So beheben Sie dieses Problem:

Deinstallieren Sie Az.Accounts-Module mit den Versionen 2.7.x. Führen Sie das folgende Cmdlet aus:

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

Dieser Fehler tritt auf, wenn Azure Local außerhalb der Richtlinie ist. Der Verbindungsstatus im Cluster zeigt möglicherweise an, dass er verbunden ist, aber im Ereignisprotokoll wird die Warnmeldung Azure Local's subscription is expired, run Sync-AzureStackHCI to renew the subscription angezeigt.

Um diesen Fehler zu beheben, überprüfen Sie, ob der Cluster bei Azure registriert ist, indem Sie das PowerShell-Cmdlet Get-AzureStackHCI verwenden, das auf Ihrem Computer verfügbar ist. Im Windows Admin Center-Dashboard werden auch Statusinformationen zur Azure-Registrierung des Clusters angezeigt.

Wenn der Cluster bereits registriert ist, sollten Sie das Feld LastConnected in der Ausgabe von Get-AzureStackHCI anzeigen. Wenn das Feld anzeigt, dass es länger als 30 Tage her ist, sollten Sie versuchen, die Situation mithilfe des Cmdlets Sync-AzureStackHCI zu beheben.

Sie können auch mit dem folgenden Cmdlet überprüfen, ob jeder Knoten Ihres Clusters über die erforderliche Lizenz verfügt:

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

Wenn das Problem nach dem Ausführen des Cmdlets Sync-AzureStackHCI nicht behoben ist, sollten Sie sich an den Microsoft-Support wenden.

Dieses Problem tritt auf, weil eine fehlgeschlagene Installation zu Ressourcenverlusten führen kann, die bereinigt werden müssen, bevor Sie die Installation erneut starten können.

Wenn die Installation mit Install-AksHci fehlschlägt, sollten Sie Uninstall-AksHci ausführen, bevor Sie erneut Install-AksHci ausführen.

Sie können diese Fehler auslösen, wenn Sie ausführen, ohne "Set-AksHciConfig" zuerst auszuführen.Install-AksHci

Um den Fehler zu beheben, führen Sie uninstall-akshci auf, und schließen Sie alle PowerShell-Fenster. Öffnen Sie eine neue PowerShell-Sitzung, und starten Sie Ihre AKS bei der lokalen Azure-Installation neu, indem Sie AKS auf Azure Local mithilfe von PowerShell installieren.

Das Set-AksHciConfig PowerShell-Cmdlet schlägt mit dem Fehler fehl:

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

Wenn Sie AKS mit einem Proxyserver verwenden, haben Sie möglicherweise beim Festlegen des erforderlichen HTTPS-Proxy-URL-Werts die falsche URL verwendet. Die HTTP-Proxy-URL- und HTTPS-Proxy-URL-Werte sind beide erforderlich, wenn AKS mit einem Proxyserver konfiguriert werden. Es ist jedoch üblich, dass beide Werte dieselbe HTTP-Präfix-URL gemeinsam verwenden.

Wenn dies in Ihrer Umgebung der Fall sein kann, probieren Sie die folgenden Gegenmaßnahmen aus:

1. Schließen Sie das PowerShell-Fenster, und öffnen Sie ein neues Fenster.
2. Führen Sie die Cmdlets und New-AksHciProxySetting die New-AksHciNetworkSetting Cmdlets erneut aus. Legen Sie beim Ausführen New-AksHciProxySettingden -https Parameter mit demselben HTTP-Präfix-URL-Wert fest, für -httpden Sie festgelegt haben.
3. Führen Sie den Vorgang aus, und fahren Sie Set-AksHciConfig fort.

Wenn Sie AKS auf Azure Local bereitstellen, kann die Bereitstellung an verschiedenen Stellen des Prozesses zeitüberschreitungen, je nachdem, wo die Fehlkonfiguration aufgetreten ist. Sie sollten die Fehlermeldung überprüfen, um die Ursache und die Stelle zu ermitteln, an dem der Fehler aufgetreten ist.

Im folgenden Fehler befindet sich beispielsweise die Stelle, an der die Fehlkonfiguration aufgetreten ist, in 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"}

Dies gibt an, dass der physische Azure Local-Knoten den Namen der Download-URL auflösen kann, msk8s.api.cdp.microsoft.comaber der Knoten kann keine Verbindung mit dem Zielserver herstellen.

Um dieses Problem zu beheben, müssen Sie bestimmen, wo die Unterbrechung im Verbindungs-Flow aufgetreten ist. Im Folgenden finden Sie einige Schritte, mit denen Sie versuchen können, das Problem über den physischen Clusterknoten zu beheben:

1. Pingen Sie den DNS-Zielnamen: ping msk8s.api.cdp.microsoft.com.
2. Wenn Sie eine Antwort zurückbekommen und keine Zeitüberschreitung, dann funktioniert der grundlegende Netzwerkpfad.
3. Wenn es bei der Verbindung zu einem Timeout kommt, könnte eine Unterbrechung im Datenpfad vorliegen. Weitere Informationen finden Sie unter Überprüfen der Proxyeinstellungen. Oder es könnte eine Unterbrechung im Rückgabepfad vorliegen, weshalb Sie die Firewallregeln überprüfen sollten.

Beim Ausführen von Set-AksHciConfig tritt möglicherweise folgender Fehler auf:

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.

Dieser Fehler tritt meist aufgrund einer Änderung im Sicherheitstoken des Benutzers (aufgrund einer Änderung der Gruppenmitgliedschaft), einer Kennwortänderung oder eines abgelaufenen Kennworts auf. In den meisten Fällen kann das Problem durch Abmelden vom Computer und erneutes Anmelden behoben werden. Wenn der Fehler weiterhin auftritt, können Sie ein Problem bei GitHub AKS Azure Local-Problemen ablegen.

Es wird erwartet, dass Moc-Agents nur die letzten 100 Agent-Protokolle beibehalten. Die älteren Protokolle sollen gelöscht werden. Die Protokollrotation erfolgt jedoch nicht, und die angesammelten Protokolle nehmen immer mehr Speicherplatz ein.

Schritte zum Reproduzieren: Install AksHci, und führen Sie einen Cluster aus, bis die Anzahl der Agent-Protokolle 100 überschreitet. Zum Zeitpunkt der Erstellung des n-ten Protokolls wird erwartet, dass die Agents das n.–100. Protokoll löschen, sofern vorhanden.

So lösen Sie das Problem:

1. Ändern Sie die logconf-Dateien des Cloud-Agents und der Knoten-Agents. Die logconfig-Datei des Cloud-Agents befindet sich unter:
   (Get-MocConfig).cloudConfigLocation+"\log\logconf".
   Die logconfig-Datei des Node-Agents befindet sich hier:
   (Get-MocConfig).cloudConfigLocation+"\log\logconf".

2. Ändern Sie den Wert von Limit auf 100 und Slots auf 100, und speichern Sie die Konfigurationsdateien.

3. Starten Sie den Cloud-Agent und die Knoten-Agents neu, um diese Änderungen zu registrieren.

Mit diesen Schritten wird die Protokollrotation erst gestartet, nachdem nach dem Neustart des Agents 100 neue Protokolle generiert wurden. Wenn zum Zeitpunkt des Neustarts bereits n Agent-Protokolle vorhanden sind, wird die Protokollrotation erst gestartet, nachdem n+100 Protokolle generiert wurden.

Wenn Sie Set-AksHciConfig verwenden, um die Parameter -imageDir, -workingDir, -cloudConfigLocation oder -nodeConfigLocationmit einem Pfadnamen anzugeben, der ein Leerzeichen enthält (z. B. D:\Cloud Share\AKS HCI), wird der Cloud-Agent-Clusterdienst möglicherweise nicht gestartet, und es wird eine Fehlermeldung wie die folgende angezeigt:

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'

Um dieses Problem zu umgehen, verwenden Sie einen Pfad ohne Leerzeichen, z. B. C:\CloudShare\AKS-HCI.

Dieser Fehler kann auftreten, wenn eine Fehlkonfiguration der Infrastruktur vorliegt.

Führen Sie die folgenden Schritte aus, um den Fehler zu beheben:

1. Überprüfen Sie die Konfiguration des Host-DNS-Servers und die Gatewayeinstellungen:

   1. Vergewissern Sie sich, dass der DNS-Server ordnungsgemäß konfiguriert ist. Führen Sie folgenden Befehl aus, um die DNS-Serveradresse des Hosts zu überprüfen:

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

   2. Führen Sie den Befehl ipconfig/all aus, um zu überprüfen, ob Ihre IP-Adresse und die Gatewaykonfiguration korrekt sind.
   3. Versuchen Sie, das IP-Gateway und den DNS-Server zu pingen.

2. Überprüfen Sie den CloudAgent-Dienst, um sicherzustellen, dass er ausgeführt wird:

   1. Pingen Sie den CloudAgent-Dienst, um sicherzustellen, dass er erreichbar ist.
   2. Stellen Sie sicher, dass alle Knoten das DNS des CloudAgent auflösen können, indem Sie den folgenden Befehl auf jedem Knoten ausführen:

      Resolve-DnsName <FQDN of cloudagent>
      

   3. Wenn der vorherige Schritt auf den Knoten erfolgreich ist, vergewissern Sie sich, dass die Knoten den CloudAgent-Port erreichen können. So stellen Sie sicher, dass kein Proxy diese Verbindung blockiert und dass der Port geöffnet ist. Führen Sie zu diesem Zweck den folgenden Befehl auf jedem Knoten aus:

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

   4. Um zu überprüfen, ob der Clusterdienst für einen Failovercluster ausgeführt wird, können Sie auch den folgenden Befehl ausführen:

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

Dies weist in der Regel darauf hin, dass das Clustername-Objekt (Cluster Name Object, CNO), das Ihren zugrunde liegenden Failovercluster in Active Directory-Domäne Services (AD DS) darstellt, keine Berechtigungen zum Erstellen eines virtuellen Computerobjekts (Virtual Computer Object, VCO) in der Organisationseinheit (OU) oder im Container hat, in dem sich der Cluster befindet.

Wenn Sie kein Domänenadministrator sind, können Sie einen bitten, der OU die CNO-Berechtigungen zu erteilen oder eine VCO für den generischen Clusterdienst des Cloud-Agents vorab zu erteilen.

Wenn Sie ein Domänenadministrator sind, ist es dennoch möglich, dass Ihre OU oder Ihr Container nicht über die erforderlichen Berechtigungen verfügt. Beispielsweise kann der in KB5008383 eingeführte Erzwingungsmodus in Active Directory aktiviert sein. Versuchen Sie folgendes, bevor Sie eine Neuinstallation versuchen.

1. Navigieren Sie zu Active Directory-Benutzer und -Computer.
2. Klicken Sie mit der rechten Maustaste auf die OU oder den Container, in dem sich der Cluster befindet.
3. Wählen Sie Stellvertretungs-Steuerelement ... aus, um die Stellvertretung des Steuerelement-Assistenten zu öffnen.
4. Klicken Sie auf "Weiter> klicken" auf "Hinzufügen", um das Fenster "Benutzer, Computer oder Gruppen auswählen" zu öffnen.
5. Wählen Sie Ihre Auswahl von Gruppen oder Benutzern aus, an die Sie das Steuerelement > delegieren möchten, klicken Sie auf 'OK'.
6. Wählen Sie "Benutzerdefinierte Aufgabe erstellen" aus, um "Weiter" zu delegieren>, um zur Seite "Active Directory-Objekttyp" zu wechseln.
7. Wählen Sie im Ordner "Computerobjekte> auswählen" nur die folgenden Objekte aus, und wählen Sie "Ausgewählte Objekte in diesem Ordner> erstellen" aus, und klicken Sie auf "Weiter", um zur Seite "Berechtigungen" zu wechseln.>
8. Wählen Sie "Alle untergeordneten Objekte erstellen" und "Alle untergeordneten Objekte löschen" aus der Liste der Berechtigungen > "Klicken Sie auf 'Weiter fertig stellen'">aus.

Wenn eine Neuinstallation fehlschlägt, wiederholen Sie die oben aufgeführten Änderungen in den Schritten 7 und 8:

• Schritt 7: Wählen Sie diesen Ordner, vorhandene Objekte in diesem Ordner aus, und erstellen Sie neue Objekte in diesem Ordner> auf " Weiter".
• Schritt 8: Wählen Sie "Lesen", "Schreiben", "Alle untergeordneten Objekte erstellen" und "Alle untergeordneten Objekte löschen" aus der Liste der Berechtigungen "Klicken Sie auf 'Weiter> fertig stellen'>" aus.

Möglicherweise wird diese Fehlermeldung beim Ausführen von Install-AksHci angezeigt.

Sie können weitere Informationen erhalten, indem Sie ausführen $error = Install-AksHci und dann $error[0].Exception.InnerException.

Die Aks-Hci-PowerShell-Befehle überprüfen vor dem Erstellen von Kubernetes-Knoten nicht den verfügbaren Arbeitsspeicher auf dem Hostserver. Dieses Problem kann dazu führen, dass der Speicher ausgelastet ist und virtuelle Computer nicht starten. Dieser Fehler wird derzeit nicht angemessen behandelt, und die Bereitstellung reagiert nicht mehr, ohne dass eine eindeutige Fehlermeldung angezeigt wird.

Wenn Ihre Bereitstellung nicht mehr reagiert, öffnen Sie die Ereignisanzeige, und suchen Sie nach Hyper-V-bezogenen Fehlermeldungen, die darauf hinweist, dass nicht genügend Arbeitsspeicher zum Starten der VM vorhanden ist.

Dieser Fehler kann auftreten, wenn es in Ihrem Azure-Konto mehrere Mandanten gibt.

Verwenden Sie $tenantId = (Get-AzContext).Tenant.Id, um den richtigen Mandanten einzustellen. Schließen Sie diesen Mandanten dann als Parameter ein, während Sie Set-AksHciRegistration ausführen.

Wenn Sie versuchen, einen AKS-Cluster auf einem virtuellen Azure-Computer bereitzustellen, ist die Installation hängen Waiting for pod 'Cloud Operator' to be ready...geblieben, und es ist nach zwei Stunden ein Fehler aufgetreten und ein Timeout aufgetreten. Versuche zur Problembehandlung durch Überprüfung des Gateways und des DNS-Servers zeigten, dass diese einwandfrei funktionierten. Sucht nach IP- oder MAC-Adresskonflikten, die keine gefunden haben. Die Protokolle haben den VIP-Pool nicht angezeigt. Es lag eine Einschränkung beim Pullen des Containerimages mit sudo docker pull ecpacr.azurecr.io/kube-vip:0.3.4 vor, die ein TLS-Timeout (Transport Layer Security) anstelle von Nicht autorisiert zurückgab.

Führen Sie die folgenden Schritte aus, um dieses Problem zu beheben:

1. Beginnen Sie mit der Bereitstellung Ihres Clusters.
2. Wenn der Cluster bereitgestellt wird, stellen Sie eine Verbindung mit Ihrem Verwaltungscluster-VM über SSH her, wie unten gezeigt:

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

3. Ändern Sie die Einstellung „Maximale Übertragungseinheit“ (MTU). Zögern Sie nicht, die Änderung vorzunehmen; Wenn Sie die Änderung zu spät vornehmen, schlägt die Bereitstellung fehl. Wenn Sie die MTU-Einstellung ändern, können Sie das Blockieren des Pullens des Containerimages beseitigen.

sudo ifconfig eth0 mtu 1300

4. Führen Sie den folgenden Befehl aus, um den Status Ihrer Container anzuzeigen:

sudo docker ps -a

Nachdem Sie diese Schritte ausgeführt haben, sollte die Blockierung des Containerimage-Pull aufgehoben werden.

Dieser Fehler weist darauf hin, dass die IP-Adresse des Clouddiensts nicht Teil des Clusternetzwerks ist und keinem der Clusternetzwerke entspricht, für die die Rolle client and cluster communication aktiviert ist.

Um dieses Problem zu beheben, führen Sie Get-ClusterNetwork aus, wobei Role gleich ClusterAndClient ist. Wählen Sie dann auf einem der Clusterknoten den Namen, die Adresse und die Adressmaske aus, um zu überprüfen, ob die für den Parameter -cloudServiceIP von New-AksHciNetworkSetting bereitgestellte IP-Adresse mit einem der angezeigten Netzwerke übereinstimmt.

Enable-AksHciArcConnection kann einen AKS-Cluster mit Azure verbinden, zeigt jedoch die folgende Warnung an, wenn der Kunde einen Dienstprinzipal für die Authentifizierung verwendet:

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

Das aktuelle Verhalten des Arc-Onboardings besteht darin, benutzerdefinierte Speicherorte standardmäßig zu aktivieren. Um benutzerdefinierte Speicherorte zu aktivieren, wird die GetServicePrincipals-Aktion im Kontext des angemeldeten Azure-Benutzers ausgeführt. Wenn der Benutzer (oder SPN) nicht über ausreichende Berechtigungen verfügt, um dies ausführen zu können, gibt der Befehl eine Warnung aus, dass diese Berechtigungen nicht vorhanden sind, und daher wird das Feature "Benutzerdefinierte Speicherorte" nicht aktiviert.

Wenn Sie nicht möchten, dass benutzerdefinierte Speicherorte aktiviert werden, können Sie diese Warnung sicher ignorieren, da sich dies nicht auf das Cluster-Onboarding in Arc auswirkt. Wenn Sie jedoch benutzerdefinierte Speicherorte aktivieren müssen, müssen Sie dem Benutzer (oder SPN) die erforderlichen Berechtigungen erteilen.

Nächste Schritte

• Problembehandlung: Übersicht, Feedback und Support
• Bekannte Probleme mit Windows Admin Center
• Problembehandlung für Kubernetes-Cluster

Wenn weiterhin Probleme auftreten, wenn Sie AKS Arc verwenden, können Sie Fehler über GitHub ablegen.