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

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

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.

Azure Arc für Kubernetes-verbundene Cluster können den Wert für die JSON-Eigenschaft distribution auf eine leere Zeichenfolge festlegen. Bei AKS Arc-verbundenen Clustern wird dieser Wert während der Erstinstallation festgelegt und 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 sehen Sie eine Beispielausgabe dieses Befehls:

{
"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, befolgen Sie die folgenden Anweisungen, um den Cluster zu patchen:

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

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

   Wichtig

   Wenn Ihr Cluster ein AKS-Verwaltungscluster ist, sollte der Wert auf . aks_management festgelegt werden. Wenn es sich um einen Workloadcluster handelt, sollte er auf " aks_workload.

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 den Cluster zu patchen. Der <cc_arm_id> Wert sollte die ID sein, die in Schritt 2 abgerufen wird:

   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 richtig festgelegt wurde.

Symptome:

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

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

Wahrscheinlich wurden die Proxyeinstellungen in einen fehlerhaften Proxy auf dem Host 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 wird oder eine alte Aktualisierung oder ein Neustart erfolgt. Es ist möglich, dass fehlerhafte Proxyeinstellungen auf dem Host festgelegt wurden und sie nach einem Update oder Neustart an den WSSDAgent weitergegeben wurden, was dazu führte, dass der WSSDAgent fehlschlug.

Sie müssen die Proxyeinstellungen beheben, indem Sie die Umgebungsvariablen auf dem Computer ändern. Ändern Sie auf dem Computer die Variablen 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 der WSSDAgent den festen Proxy aufnehmen.

Dieser Fehler tritt auf, da bei jedem Start des CAPH-Pods eine Anmeldung bei Cloudagent versucht wird und das Zertifikat im temporären Speichervolume gespeichert wird, das bei Pod-Neustarts bereinigt wird. Daher wird jedes Mal, wenn ein Pod neu gestartet wird, das Zertifikat zerstört und ein neuer Anmeldeversuch unternommen.

Ein Anmeldeversuch startet eine Verlängerungsroutine, die das Zertifikat verlängert, wenn es bald abläuft. 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 Verlängerungsroutine 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, wodurch die Verlängerungsroutine nicht gestartet wird. Dies führt zum Ablauf des Zertifikats.

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

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 bewirkt, dass ein AKS Arc-Cluster für einen längeren Zeitraum im ScalingControlPlane-Zustand verbleibt.

Schritte zum 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. Wir empfehlen, Ihre AKS Arc-Cluster auf die neueste Version zu aktualisieren.

Um dieses Problem zu beheben, wenden Sie sich an den Support, um den Status der Steuerebenenknoten manuell zu patchen, um den Zustand MachineOwnerRemediatedCondition aus dem Computerstatus über kubectl zu entfernen.

Der Workloadcluster kann nicht gefunden werden, wenn die IP-Adresspools von zwei AKS in lokalen Azure-Bereitstellungen identisch oder überlappen. Wenn Sie zwei AKS-Hosts bereitstellen und dieselbe AksHciNetworkSetting Konfiguration für beides verwenden, kann PowerShell und Windows Admin Center den Workloadcluster möglicherweise nicht finden, da dem API-Server die gleiche IP-Adresse in beiden Clustern 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 mit einem nicht überlappenden Netzwerk mit den anderen Clustern.

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 "Fehlgeschlagen" angezeigt. Diese Vorabüberprüfung prüft, dass alle IPv4-Adressen und DNS-Netzwerknamen online und erreichbar sind. Beispielsweise kann ein fehlgeschlagener 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 Onlinestatus 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 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.

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

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 Anwendungs-Pods festgelegt.

Voraussetzungen

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

Schritte

1. Führen Sie den folgenden kubectl Befehl mit dem Workload cluster 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 mithilfe der Ausgabe aus den vorherigen Schritten die folgenden Schritte für jeden Knotenpoolknoten aus, der die NTP-Konfiguration aktualisiert:

   1. SSH in einem knotenpoolknoten VM:

      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 die nodepool-VM 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 Uhrzeit 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 Zeit nicht automatisch aktualisiert, starten Sie die zugehörigen Pods neu.

Nächste Schritte

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