Beheben bekannter Probleme und Fehler beim Konfigurieren eines Netzwerks in AKS Arc

Der Cloud-Agent kann möglicherweise nicht erfolgreich gestartet werden, wenn Pfadnamen mit Leerzeichen darin verwendet werden.

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.

Mit Azure Arc für Kubernetes verbundene Cluster können den Wert für die JSON-Eigenschaft distribution auf eine leere Zeichenfolge festgelegt haben. Für mit AKS Arc verbundene Cluster wird dieser Wert während der Erstinstallation festgelegt und wird für die Lebensdauer der Bereitstellung nie geändert.

Um das Problem zu reproduzieren, öffnen Sie ein Azure PowerShell Fenster, und führen Sie die folgenden Befehle aus:

az login
az account set --subscription <sub_id>
az connectedk8s show -g <rg_name> -n

Im Folgenden wird die Beispielausgabe dieses Befehls angezeigt:

{
"agentPublicKeyCertificate": <value>
"agentVersion": "1.8.14",
"azureHybridBenefit": "NotApplicable",
"connectivityStatus": "Connected",
"distribution": "",
"distributionVersion": null,
"id": "/subscriptions/<subscription>/resourceGroups/<resource group>/providers/Microsoft.Kubernetes/connectedClusters/<cluster name>",
"identity": {
  "principalId": "<principal id>",
  "tenantId": "<tenant id>",
  "type": "SystemAssigned"
},
"infrastructure": "azure_stack_hci",
"kubernetesVersion": "1.23.12",
"lastConnectivityTime": "2022-11-04T14:59:59.050000+00:00",
"location": "eastus",
"managedIdentityCertificateExpirationTime": "2023-02-02T14:24:00+00:00",
"miscellaneousProperties": null,
"name": "mgmt-cluster",
"offering": "AzureStackHCI_AKS_Management",
"privateLinkScopeResourceId": null,
"privateLinkState": "Disabled",
"provisioningState": "Succeeded",
"resourceGroup": "<resource group>",
"systemData": {
  "createdAt": "2022-11-04T14:29:17.680060+00:00",
  "createdBy": "<>",
  "createdByType": "Application",
  "lastModifiedAt": "2022-11-04T15:00:01.830067+00:00",
  "lastModifiedBy": "64b12d6e-6549-484c-8cc6-6281839ba394",
  "lastModifiedByType": "Application"
},
"tags": {},
"totalCoreCount": 4,
"totalNodeCount": 1,
"type": "microsoft.kubernetes/connectedclusters"
}

So beheben Sie das Problem

Wenn die Ausgabe für die JSON-Eigenschaft distribution eine leere Zeichenfolge zurückgibt, führen Sie die folgenden Anweisungen aus, um Ihren Cluster zu patchen:

1. Kopieren Sie die folgende Konfiguration in eine Datei namens patchBody.json:

   {
      "properties": {
        "distribution": "aks_management"
      }
   }
   

   Wichtig

   Wenn es sich bei Ihrem Cluster um einen AKS-Verwaltungscluster handelt, sollte der Wert auf aks_managementfestgelegt werden. Wenn es sich um einen Workloadcluster handelt, sollte er auf aks_workloadfestgelegt werden.

2. Kopieren Sie aus der oben abgerufenen JSON-Ausgabe Ihre verbundene Cluster-ID. Sie sollte als lange Zeichenfolge im folgenden Format angezeigt werden:

   "/subscriptions/<subscription >/resourceGroups/<resource group>/providers/Microsoft.Kubernetes/connectedClusters/<cluster name>",

3. Führen Sie den folgenden Befehl aus, um Ihren Cluster zu patchen. Der <cc_arm_id> Wert sollte die ID sein, die in Schritt 2 abgerufen wurde:

   az rest -m patch -u "<cc_arm_id>?api-version=2022-10-01-preview" -b "@patchBody.json"
   

4. Überprüfen Sie, ob Ihr Cluster erfolgreich gepatcht wurde, indem Sie ausführen az connectedk8s show -g <rg_name> -n <cc_name> , um sicherzustellen, dass die JSON-Eigenschaft distribution ordnungsgemäß festgelegt wurde.

Symptome:

• Proxy in AKS Arc aktiviert. Der WSSDAgent-Dienst blieb im starting Zustand hängen. Wird wie folgt angezeigt:
• Test-NetConnection -ComputerName <computer IP/Name> -Port <port> von dem Knoten, auf dem der Knoten-Agent fehlschlägt, auf den der Cloud-Agent auf dem System ordnungsgemäß funktioniert (auch wenn der wssdagent nicht gestartet werden kann)
• Curl.exe von dem Knoten, auf dem der Agent fehlschlägt, in Richtung des Cloud-Agents reproduziert das Problem und bleibt hängen: curl.exe https://<computerIP>:6500
• Um das Problem zu beheben, übergeben Sie das --noproxy Flag an curl.exe. Curl gibt einen Fehler von wssdcloudagent zurück. Dies wird erwartet, da curl kein GRPC-Client ist. Curl bleibt beim Senden des --noproxy Flags nicht hängen. Daher wird die Rückgabe eines Fehlers hier als erfolgreich betrachtet:

curl.exe --noproxy '*' https://<computerIP>:65000

Wahrscheinlich wurden die Proxyeinstellungen auf dem Host in einen fehlerhaften Proxy geändert. Die Proxyeinstellungen für AKS Arc sind Umgebungsvariablen, die vom übergeordneten Prozess auf dem Host geerbt werden. Diese Einstellungen werden nur weitergegeben, wenn ein neuer Dienst gestartet oder ein alter Dienst aktualisiert oder neu gestartet wird. Es ist möglich, dass fehlerhafte Proxyeinstellungen auf dem Host festgelegt wurden, die nach einem Update oder Neustart an den WSSDAgent weitergegeben wurden, wodurch der WSSDAgent fehlschlägt.

Sie müssen die Proxyeinstellungen korrigieren, indem Sie die Umgebungsvariablen auf dem Computer ändern. Ändern Sie die Variablen auf dem Computer mit den folgenden Befehlen:

  [Environment]::SetEnvironmentVariable("https_proxy", <Value>, "Machine")
  [Environment]::SetEnvironmentVariable("http_proxy", <Value>, "Machine")
  [Environment]::SetEnvironmentVariable("no_proxy", <Value>, "Machine")

Starten Sie den Computer neu, damit der Dienst-Manager und WSSDAgent den festen Proxy abrufen.

Dieser Fehler tritt auf, da jedes Mal, wenn der CAPH-Pod gestartet wird, versucht wird, sich bei cloudagent anzumelden und das Zertifikat im temporären Speichervolume gespeichert wird, das bei Podneustarts sauber wird. Daher wird jedes Mal, wenn ein Pod neu gestartet wird, das Zertifikat zerstört, und es wird ein neuer Anmeldeversuch unternommen.

Ein Anmeldeversuch startet eine Erneuerungsroutine, die das Zertifikat nach ablaufen erneuert. Der CAPH-Pod entscheidet, ob eine Anmeldung erforderlich ist, wenn das Zertifikat verfügbar ist oder nicht. Wenn das Zertifikat verfügbar ist, wird die Anmeldung nicht versucht, vorausgesetzt, die Erneuerungsroutine ist bereits vorhanden.

Bei einem Containerneustart wird das temporäre Verzeichnis jedoch nicht bereinigt, sodass die Datei weiterhin beibehalten wird und der Anmeldeversuch nicht durchgeführt wird, sodass die Erneuerungsroutine nicht gestartet wird. Dies führt zum Ablauf des Zertifikats.

Starten Sie den CAPH-Pod mit dem folgenden Befehl neu, um dieses Problem zu beheben:

kubectl delete pod pod-name

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.

In den meisten Fällen tritt dieser Fehler 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 über die Azure-Portal ein Supportticket erstellen.

Dieses Problem führt dazu, dass ein AKS Arc-Cluster für einen längeren Zeitraum im ScalingControlPlane-Zustand verbleibt .

So reproduzieren

Get-AksHciCluster -Name <cluster name> | select *

Status                : {ProvisioningState, Details}
ProvisioningState     : ScalingControlPlane
KubernetesVersion     : v1.22.6
PackageVersion        : v1.22.6-kvapkg.0
NodePools             : {nodepoolA, nodepoolB}
WindowsNodeCount      : 0
LinuxNodeCount        : 1
ControlPlaneNodeCount : 1
ControlPlaneVmSize    : Standard_D4s_v3
AutoScalerEnabled     : False
AutoScalerProfile     :
Name                  : <cluster name>

Dieses Problem wurde in den letzten AKS Arc-Versionen behoben. Es wird empfohlen, Ihre AKS Arc-Cluster auf das neueste Release zu aktualisieren.

Um dieses Problem zu beheben, wenden Sie sich an den Support, um die status der Knoten der Steuerungsebene manuell zu patchen, um die Bedingung MachineOwnerRemediatedCondition vom Computer status über kubectl zu entfernen.

Der Workloadcluster wird möglicherweise nicht gefunden, wenn die IP-Adresspools von zwei AKS-Instanzen auf Azure Stack HCI-Bereitstellungen identisch sind oder sich überlappen. Wenn Sie zwei AKS-Hosts bereitstellen und die gleiche AksHciNetworkSetting Konfiguration für beide verwenden, können PowerShell und Windows Admin Center den Workloadcluster möglicherweise nicht finden, da dem API-Server in beiden Clustern dieselbe IP-Adresse zugewiesen wird, was zu einem Konflikt führt.

Die Fehlermeldung, die Sie erhalten, ähnelt dem unten gezeigten Beispiel.

A workload cluster with the name 'clustergroup-management' was not found.
At C:\Program Files\WindowsPowerShell\Modules\Kva\0.2.23\Common.psm1:3083 char:9
+         throw $("A workload cluster with the name '$Name' was not fou ...
+         ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : OperationStopped: (A workload clus... was not found.:String) [], RuntimeException
    + FullyQualifiedErrorId : A workload cluster with the name 'clustergroup-management' was not found.

Um das Problem zu beheben, löschen Sie einen der Cluster, und erstellen Sie eine neue AKS-Clusternetzwerkeinstellung, die ein nicht überlappende Netzwerk mit den anderen Clustern aufweist.

Wenn Sie den Befehl Get-AksHciClusterNetwork ausführen, wird eine Liste aller Konfigurationen des virtuellen Netzwerks angezeigt. Der Befehl zeigt jedoch nicht die aktuelle Zuordnung der IP-Adressen an.

Verwenden Sie die folgenden Schritte, um herauszufinden, welche IP-Adressen derzeit in einem virtuellen Netzwerk verwendet werden:

1. Führen Sie den folgenden Befehl aus, um die Gruppe abzurufen:

Get-MocGroup -location MocLocation

2. Führen Sie den folgenden Befehl aus, um die Liste der derzeit verwendeten IP-Adressen und die Liste der verfügbaren oder verwendeten virtuellen IP-Adressen abzurufen:

Get-MocNetworkInterface -Group <groupName> | ConvertTo-Json -depth 10

3. Verwenden Sie den folgenden Befehl, um die Liste der derzeit verwendeten virtuellen IP-Adressen anzuzeigen:

Get-MocLoadBalancer -Group <groupName> | ConvertTo-Json -depth 10

Eine Cluster-IP-Adresse wird während der Vorabüberprüfung als "Fehler" angezeigt. Bei dieser Vorabüberprüfung wird getestet, dass alle IPv4-Adressen und DNS-Netzwerknamen online und erreichbar sind. Beispielsweise kann ein fehlerhafter IPv4- oder Netzwerkname dazu führen, dass dieser Test fehlschlägt.

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

1. Führen Sie den folgenden Befehl aus:

   Get-ClusterGroup -name "Cluster Group" | Get-ClusterResource
   

2. Stellen Sie sicher, dass sich alle Netzwerknamen und IP-Adressen in einem Onlinezustand befinden.

3. Führen Sie die folgenden beiden Befehle aus:

   Stop-ClusterResource -name "Cluster IP Address x.x.x.x"
   

   Und dann

   Start-ClusterResource -name "Cluster IP Address x.x.x.x"
   

Wenn Sie AKS in Azure Stack HCI bereitstellen, kann für die Bereitstellung ein Timeout 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.

Anwendungen, die ntp-zeitabhängig sind, können Hunderte von falschen Warnungen auslösen, wenn sie nicht mehr zeitsynchron sind. Wenn der Cluster in einer Proxyumgebung ausgeführt wird, können Ihre Knotenpools möglicherweise nicht über Ihren Proxy oder Ihre Firewall mit dem STANDARD-NTP-Server kommunizieren, time.windows.com.

Problemumgehung

Um dieses Problem zu umgehen, aktualisieren Sie die NTP-Serverkonfiguration auf jedem Knotenpoolknoten, um die Uhren zu synchronisieren. Auf diese Weise werden auch die Uhren in jedem Ihrer Anwendungspods festgelegt.

Voraussetzungen

• Eine Adresse eines NTP-Servers, auf den in jedem Knotenpoolknoten zugegriffen werden kann.
• Zugriff auf die Kubeconfig-Datei des Workloadclusters.
• Zugriff auf den Verwaltungscluster kubeconfig.

Schritte

1. Führen Sie den folgenden kubectl Befehl mithilfe des Workloadclusters kubeconfig aus, um eine Liste der Darin enthaltenen Knoten abzurufen:

   kubectl --kubeconfig <PATH TO KUBECONFIG> get nodes -owide
   

2. Führen Sie den folgenden kubectl Befehl aus, um die Knotennamen aus dem vorherigen Befehl mit den Knotenpoolknoten des Workloadclusters zu korrelieren. Notieren Sie sich die relevanten IP-Adressen aus der Ausgabe des vorherigen Befehls.

   kubectl --kubeconfig (Get-KvaConfig).kubeconfig get machine -l cluster.x-k8s.io/cluster-name=<WORKLOAD_CLUSTER_NAME>
   

3. Führen Sie anhand der Ausgabe aus den vorherigen Schritten die folgenden Schritte für jeden Knotenpoolknoten aus, für den die NTP-Konfiguration aktualisiert werden muss:

   1. STELLEN Sie eine SSH-Verbindung mit einer Knotenpoolknoten-VM her:

      ssh -o StrictHostKeyChecking=no -i (Get-MocConfig).sshPrivateKey clouduser@<NODEPOOL_IP>
      

   2. Stellen Sie sicher, dass der konfigurierte NTP-Server nicht erreichbar ist:

      sudo timedatectl timesync-status
      

      Wenn die Ausgabe wie folgt aussieht, ist der NTP-Server nicht erreichbar und muss geändert werden:

      Server: n/a (time.windows.com)
      Poll interval: 0 (min: 32s; max 34min 8s)
      Packet count: 0
      

   3. Um den NTP-Server zu aktualisieren, führen Sie die folgenden Befehle aus, um den NTP-Server in der timesync-Konfigurationsdatei auf einen festzulegen, auf den über den virtuellen Knotenpool zugegriffen werden kann:

      # make a backup of the config file
      sudo cp /etc/systemd/timesyncd.conf ~/timesyncd.conf.bak
      
      # update the ntp server
      NTPSERVER="NEW_NTP_SERVER_ADDRESS"
      sudo sed -i -E "s|^(NTP=)(.*)$|\1$NTPSERVER|g" /etc/systemd/timesyncd.conf
      
      # verify that the NTP server is updated correctly - check the value for the field that starts with "NTP="
      sudo cat /etc/systemd/timesyncd.conf 
      

   4. Starten Sie den timesync-Dienst neu:

      sudo systemctl restart systemd-timesyncd.service
      

   5. Stellen Sie sicher, dass auf den NTP-Server zugegriffen werden kann:

      sudo timedatectl timesync-status
      

   6. Stellen Sie sicher, dass die Uhr die richtige Zeit anzeigt:

      date
      

4. Stellen Sie sicher, dass jeder Knotenpoolknoten die gleiche Zeit anzeigt, indem Sie den Befehl aus Schritt 3.f ausführen.

5. Wenn Ihre Anwendung die Uhrzeit nicht automatisch aktualisiert, starten Sie die Pods neu.

Nächste Schritte

• Problembehandlung: Übersicht, Feedback und Support
• Installationsprobleme und -fehler
• Bekannte Speicherprobleme