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

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

Wenn Sie Private Link nicht 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, gegen eine Azure-Richtlinie zu verstoßen, die im Rahmen des Azure Arc-Onboardingprozesses für das Azure-Abonnement oder die Azure-Ressourcengruppe festgelegt wurde. Dieser Fehler kann für Benutzer auftreten, die Azure-Richtlinien auf Abonnement- oder Ressourcengruppenebene definiert haben, und dann versuchen, AKS in Azure Stack HCI zu installieren, was gegen eine Azure-Richtlinie verstößt.

Um dieses Problem zu beheben, lesen Sie die Fehlermeldung, um zu verstehen, welche Azure Policy von Ihrem Azure-Administrator verletzt wurde, und ändern Sie dann die Azure-Richtlinie, indem Sie eine Ausnahme für die Azure-Richtlinie machen. 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, sauber Sie die Clusterrolle manuell auf. 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 vom API-Aufruf zurückgegeben: Dateidownloadfehler: Hashkonflikt" fehl.

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

Nach der Bereitstellung wurde beim Neustart der Azure Stack HCI Knoten im AKS-Bericht ein Fehlerstatus 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 angezeigt wurde, 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 Stack HCI mit dem richtigen DNS-Server neu. Weitere Informationen finden Sie unter Erneutes Starten, Entfernen oder Neuinstallieren von Azure Kubernetes Service auf Azure Stack HCI.

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

Install-AksHci Dieser Fehler ist fehlgeschlagen, da die ip-Poolbereiche, die in der AKS in Azure Stack HCI-Konfiguration bereitgestellt werden, im CIDR um 1 deaktiviert waren und zu einem Absturz von CloudAgent führen können. 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 dieser Fehler angezeigt wird, sollten Sie die neueste Version von Microsoft Edge oder Google Chrome verwenden und es erneut versuchen.

Dieser Fehler tritt nach Ausführen von Set-AksHciRegistration bei Installation von AKS in Azure Stack HCI auf. 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:

• Bei der AKS in Azure Stack HCI-Registrierung (Set-AksHciRegistration) wird ein Dienstprinzipal verwendet.
• Die PowerShell-Modulversion (2.7.x) von Az.Accounts ist installiert.

Az.Accounts 2.7.x-Version entfernt das ServicePrincipalSecret und CertificatePassword in PSAzureRmAccount, die von AKS in Azure Stack HCI für das Azure Arc-Onboarding verwendet werden.

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 in Azure Stack HCI-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 lösen Sie das 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 Stack HCI nicht mehr der Richtlinie entspricht. Der Verbindungsstatus im Cluster zeigt möglicherweise an, dass er verbunden ist, aber im Ereignisprotokoll wird die Warnmeldung Azure Stack HCI'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 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

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 ausführen.

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

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 Ihren AKS-HCI-Installationsprozess neu, indem Sie Installieren von AKS-HCI mithilfe von PowerShell ausführen.

Das Set-AksHciConfig PowerShell-Cmdlet schlägt mit folgendem 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 beim Festlegen des erforderlichen WERTs für die HTTPS-Proxy-URL möglicherweise die falsche URL verwendet. Die Werte für HTTP-Proxy-URL und HTTPS-Proxy-URL sind beide erforderlich, wenn AKS mit einem Proxyserver konfiguriert wird, aber es ist üblich, dass beide Werte die gleiche URL mit HTTP-Präfix verwenden.

Wenn dies in Ihrer Umgebung der Fall sein kann, führen Sie die folgenden Schritte zur Entschärfung aus:

1. Schließen Sie das PowerShell-Fenster, und öffnen Sie ein neues Fenster.
2. Führen Sie die New-AksHciNetworkSetting Cmdlets und New-AksHciProxySetting erneut aus. Wenn Sie ausführen New-AksHciProxySetting, legen Sie den -https Parameter mit demselben URL-Präfix mit HTTP-Präfix fest, den Sie für -httpfestgelegt haben.
3. Führen Sie aus Set-AksHciConfig , und fahren Sie fort.

Wenn Sie AKS in Azure Stack HCI bereitstellen, kann ein Timeout für die Bereitstellung an verschiedenen Stellen des Prozesses auftreten, 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 zeigt an, dass der physische Azure Stack HCI-Knoten den Namen der Download-URL msk8s.api.cdp.microsoft.com auflösen kann, doch 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 weiterhin ein Fehler auftritt, können Sie unter GitHub AKS HCI-Probleme ein Problem melden.

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 , -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. Vergewissern Sie sich, dass alle Knoten das DNS des Cloud-Agents auflösen können, indem Sie auf jedem Knoten den folgenden Befehl aus fü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 gibt in der Regel an, dass das Clusternamenobjekt (Cluster Name Object, CNO), das Den zugrunde liegenden Failovercluster in Active Directory Domain Services (AD DS) darstellt, nicht über die Berechtigungen zum Erstellen eines virtuellen Computerobjekts (Virtual Computer Object, VCO) in der Organisationseinheit (OE) oder in dem Container verfügt, in dem sich der Cluster befindet.

Wenn Sie kein Domänenadministrator sind, können Sie ihn bitten, der Organisationseinheit CNO-Berechtigungen zu erteilen oder eine VCO für den generischen Cloud-Agent-Clusterdienst vorab zu stellen.

Wenn Sie Domänenadministrator sind, ist es dennoch möglich, dass Ihre Organisationseinheit 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 Organisationseinheit oder den Container, in der sich der Cluster befindet.
3. Wählen Sie Steuerelement delegieren... aus, um den Assistenten zum Delegierungen von Steuerelementen zu öffnen.
4. Klicken Sie auf Weiter> Klicken Sie auf Hinzufügen... , um das Fenster Benutzer, Computer oder Gruppen auswählen zu öffnen.
5. Wählen Sie die gruppe oder die Benutzer aus, an die Sie das Steuerelement > delegieren möchten Klicken Sie auf OK.
6. Wählen Sie Benutzerdefinierte Aufgabe erstellen zum Delegieren> Klicken Sie auf Weiter , um zur Seite Active Directory-Objekttyp zu wechseln.
7. Wählen Sie Nur die folgenden Objekte im Ordner>Computerobjekte> auswählen Auswählen Ausgewählte Objekte in diesem Ordner erstellen und ausgewählte Objekte in diesem Ordner> löschen 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.

Wenn bei einer Neuinstallation ein Fehler auftritt, wiederholen Sie die obigen Schritte mit den folgenden Änderungen an 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> klicken Sie 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> klicken Sie auf Fertig stellen.

Möglicherweise erhalten Sie diesen Fehler, wenn Sie Install-AksHci ausführen.

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

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.

Beim Versuch, einen AKS-Cluster auf einem virtuellen Azure-Computer bereitzustellen, ist die Installation an Waiting for pod 'Cloud Operator' to be ready...hängen geblieben. Anschließend ist ein Fehler aufgetreten und nach zwei Stunden ein Timeout aufgetreten. Versuche zur Problembehandlung durch Überprüfung des Gateways und des DNS-Servers zeigten, dass diese einwandfrei funktionierten. Überprüft, ob IP- oder MAC-Adresskonflikte keine gefunden wurden. In den Protokollen wurde der 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 sudo docker pull ecpacr.azurecr.io/kube-vip:0.3.4 zurückgab.

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

1. Beginnen Sie mit der Bereitstellung Ihres Clusters.
2. Stellen Sie nach der Bereitstellung des Clusters eine Verbindung mit Ihrer 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-Pullvorgangs 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 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 -cloudServiceIP bereitgestellte IP-Adresse mit einem der angezeigten Netzwerke übereinstimmt.

Nächste Schritte

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

Wenn bei der Verwendung von AKS Arc weiterhin Probleme auftreten, können Sie Fehler über GitHub erstellen.