Bekende problemen en fouten bij het configureren van een netwerk in AKS Arc oplossen

Cloudagent kan niet worden gestart bij het gebruik van padnamen met spaties erin.

Wanneer u Set-AksHciConfig gebruikt om parameters op te geven-imageDir, -workingDir-cloudConfigLocationof -nodeConfigLocation parameters met een padnaam die een spatieteken bevat, zoalsD:\Cloud Share\AKS HCI, kan de cloudagentclusterservice niet beginnen met het volgende (of vergelijkbare) foutbericht:

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'

Als u dit probleem wilt omzeilen, gebruikt u een pad dat geen spaties bevat, C:\CloudShare\AKS-HCIbijvoorbeeld.

Met Azure Arc voor Kubernetes verbonden clusters kan de waarde voor de JSON-eigenschap distribution zijn ingesteld op een lege tekenreeks. Voor clusters die zijn verbonden met AKS Arc, wordt deze waarde ingesteld tijdens de eerste installatie en wordt deze waarde nooit gewijzigd voor de levensduur van de implementatie.

Als u het probleem wilt reproduceren, opent u een Azure PowerShell-venster en voert u de volgende opdrachten uit:

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

Hier volgt een voorbeeld van uitvoer van deze opdracht:

{
"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"
}

Het probleem oplossen

Als de uitvoer voor de JSON-eigenschap distribution een lege tekenreeks retourneert, volgt u deze instructies om uw cluster te patchen:

1. Kopieer de volgende configuratie naar een bestand met de naam patchBody.json:

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

   Belangrijk

   Als uw cluster een AKS-beheercluster is, moet de waarde worden ingesteld op aks_management. Als het een workloadcluster is, moet het worden ingesteld op aks_workload.

2. Kopieer de id van uw verbonden cluster vanuit de JSON-uitvoer die u hierboven hebt verkregen. Deze moet worden weergegeven als een lange tekenreeks in de volgende indeling:

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

3. Voer de volgende opdracht uit om uw cluster te patchen. De <cc_arm_id> waarde moet de id zijn die is verkregen in stap 2:

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

4. Controleer of uw cluster is gepatcht door uit te voeren az connectedk8s show -g <rg_name> -n <cc_name> om te controleren of de JSON-eigenschap distribution juist is ingesteld.

Symptomen:

• Proxy ingeschakeld in AKS Arc. De WSSDAgent-service is vastgelopen in de starting status. Wordt weergegeven als het volgende:
• Test-NetConnection -ComputerName <computer IP/Name> -Port <port> van het knooppunt waar de knooppuntagent mislukt naar de cloudagent goed werkt op het systeem (zelfs wanneer de wssdagent niet kan worden gestart)
• Curl.exe van het knooppunt waarop de agent mislukt naar de cloudagent, reproduceert het probleem en blijft hangen: curl.exe https://<computerIP>:6500
• Als u het probleem wilt oplossen, geeft u de --noproxy vlag door aan curl.exe. Curl retourneert een fout van wssdcloudagent. Dit wordt verwacht omdat curl geen GRPC-client is. Curl blijft niet hangen wanneer u de --noproxy vlag verzendt. Het retourneren van een fout wordt hier dus als een succes beschouwd):

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

De proxy-instellingen zijn waarschijnlijk gewijzigd in een onjuiste proxy op de host. De proxy-instellingen voor AKS Arc zijn omgevingsvariabelen die worden overgenomen van het bovenliggende proces op de host. Deze instellingen worden alleen doorgegeven wanneer een nieuwe service wordt gestart of een oude update of opnieuw wordt opgestart. Het is mogelijk dat onjuiste proxy-instellingen zijn ingesteld op de host en ze zijn doorgegeven aan de WSSDAgent na een update of opnieuw opstarten, waardoor de WSSDAgent is mislukt.

U moet de proxyinstellingen herstellen door de omgevingsvariabelen op de computer te wijzigen. Wijzig de variabelen op de computer met de volgende opdrachten:

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

Start de computer opnieuw op zodat de servicebeheerder en de WSSDAgent de vaste proxy ophalen.

Deze fout treedt op omdat elke keer dat de CAPH-pod wordt gestart, een aanmelding bij cloudagent wordt geprobeerd en het certificaat wordt opgeslagen in het tijdelijke opslagvolume, dat wordt opgeschoond bij het opnieuw opstarten van de pod. Daarom wordt telkens wanneer een pod opnieuw wordt opgestart, het certificaat vernietigd en wordt er een nieuwe aanmeldingspoging gedaan.

Een aanmeldingspoging start een verlengingsroutine, waarmee het certificaat wordt vernieuwd wanneer het bijna verloopt. De CAPH-pod bepaalt of er een aanmelding nodig is als het certificaat beschikbaar is of niet. Als het certificaat beschikbaar is, wordt de aanmelding niet geprobeerd, ervan uitgaande dat de verlengingsroutine al aanwezig is.

Bij het opnieuw opstarten van een container wordt de tijdelijke map echter niet opgeschoond, dus het bestand blijft behouden en de aanmeldingspoging wordt niet uitgevoerd, waardoor de vernieuwingsroutine niet wordt gestart. Dit leidt tot het verlopen van certificaten.

U kunt dit probleem oplossen door de CAPH-pod opnieuw te starten met behulp van de volgende opdracht:

kubectl delete pod pod-name

Bij het uitvoeren van Set-AksHciConfig kan de volgende fout optreden:

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.

Meestal treedt deze fout op als gevolg van een wijziging in het beveiligingstoken van de gebruiker (vanwege een wijziging in groepslidmaatschap), een wachtwoordwijziging of een verlopen wachtwoord. In de meeste gevallen kan het probleem worden opgelost door u af te melden bij de computer en u opnieuw aan te melden. Als de fout zich nog steeds voordoet, kunt u een ondersteuningsticket maken via Azure Portal.

Dit probleem zorgt ervoor dat een AKS Arc-cluster gedurende langere tijd in de status ScalingControlPlane blijft.

Om te reproduceren

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>

Dit probleem is opgelost in recente AKS Arc-versies. U wordt aangeraden uw AKS Arc-clusters bij te werken naar de nieuwste versie.

Neem contact op met de ondersteuning om de status van de besturingsvlakknooppunten handmatig te patchen om de voorwaarde MachineOwnerRemediatedCondition te verwijderen uit de machinestatus via kubectl.

Het workloadcluster kan niet worden gevonden als de IP-adresgroepen van twee AKS in lokale Azure-implementaties hetzelfde zijn of elkaar overlappen. Als u twee AKS-hosts implementeert en dezelfde AksHciNetworkSetting configuratie voor beide gebruikt, kunnen PowerShell en Het Windows-beheercentrum het workloadcluster niet vinden omdat aan de API-server hetzelfde IP-adres in beide clusters wordt toegewezen, wat resulteert in een conflict.

Het foutbericht dat u ontvangt, ziet er ongeveer uit zoals in het onderstaande voorbeeld.

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.

Als u het probleem wilt oplossen, verwijdert u een van de clusters en maakt u een nieuwe AKS-clusternetwerkinstelling met een niet-overlappend netwerk met de andere clusters.

Als u de opdracht Get-AksHciClusterNetwork uitvoert, ziet u een lijst met alle configuraties van virtuele netwerken. De opdracht geeft echter niet de huidige toewijzing van de IP-adressen weer.

Volg de onderstaande stappen om te achterhalen welke IP-adressen momenteel worden gebruikt in een virtueel netwerk:

1. Voer de volgende opdracht uit om de groep op te halen:

Get-MocGroup -location MocLocation

2. Voer de volgende opdracht uit om de lijst met IP-adressen op te halen die momenteel in gebruik zijn en de lijst met beschikbare of gebruikte virtuele IP-adressen:

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

3. Gebruik de volgende opdracht om de lijst met virtuele IP-adressen weer te geven die momenteel in gebruik zijn:

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

Een IP-adres van een cluster wordt tijdens het vooraf controleren weergegeven als 'Mislukt'. Met deze test wordt gecontroleerd of alle IPv4-adressen en DNS-netwerknamen online en bereikbaar zijn. Een mislukte IPv4- of netwerknaam kan er bijvoorbeeld toe leiden dat deze test mislukt.

Voer de volgende stappen uit om dit op te lossen:

1. Voer de volgende opdracht uit:

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

2. Zorg ervoor dat alle netwerknamen en IP-adressen zich in een onlinestatus bevinden.

3. Voer de volgende 2 opdrachten uit:

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

   en vervolgens

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

Wanneer u AKS implementeert in Azure Local, kan er een time-out optreden voor de implementatie op verschillende tijdstippen van het proces, afhankelijk van waar de onjuiste configuratie is opgetreden. Bekijk het foutbericht om de oorzaak te bepalen en waar deze is opgetreden.

In de volgende fout bevindt zich bijvoorbeeld het punt waarop de onjuiste configuratie heeft plaatsgevonden 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"}

Dit geeft aan dat het fysieke Azure Local-knooppunt de naam van de download-URL kan omzetten, msk8s.api.cdp.microsoft.commaar het knooppunt kan geen verbinding maken met de doelserver.

U kunt dit probleem oplossen door te bepalen waar de uitsplitsing is opgetreden in de verbindingsstroom. Hier volgen enkele stappen om het probleem van het fysieke clusterknooppunt op te lossen:

1. Ping de DNS-naam van de bestemming: ping msk8s.api.cdp.microsoft.com.
2. Als u een antwoord terug krijgt en er geen time-out optreedt, werkt het basisnetwerkpad.
3. Als er een time-out optreedt voor de verbinding, kan er sprake zijn van een onderbreking in het gegevenspad. Zie Proxy-instellingen controleren voor meer informatie. Of er kan sprake zijn van een onderbreking in het retourpad, dus moet u de firewallregels controleren.

Toepassingen die afhankelijk zijn van NTP-tijd, kunnen honderden valse waarschuwingen activeren wanneer ze niet zijn gesynchroniseerd. Als het cluster wordt uitgevoerd in een proxyomgeving, kunnen uw knooppuntpools mogelijk niet communiceren met de standaard-NTP-server, time.windows.com, via uw proxy of firewall.

Tijdelijke oplossing

Als u dit probleem wilt omzeilen, werkt u de configuratie van de NTP-server op elk knooppuntpoolknooppunt bij om de klokken te synchroniseren. Als u dit doet, worden ook de klokken in elk van uw toepassingspods ingesteld.

Vereisten

• Een adres van een NTP-server die toegankelijk is in elk knooppuntpoolknooppunt.
• Toegang tot het kubeconfig-bestand van het workloadcluster.
• Toegang tot de kubeconfig van het beheercluster.

Stappen

1. Voer de volgende kubectl opdracht uit met behulp van de kubeconfig van het workloadcluster om er een lijst met knooppunten in op te halen:

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

2. Voer de volgende kubectl opdracht uit om de knooppuntnamen van de vorige opdracht te correleren met de knooppuntpoolknooppunten van het workloadcluster. Noteer de relevante IP-adressen uit de uitvoer van de vorige opdracht.

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

3. Voer met behulp van de uitvoer uit de vorige stappen de volgende stappen uit voor elk nodepoolknooppunt waarvoor de NTP-configuratie moet worden bijgewerkt:

   1. SSH naar een vm voor een knooppuntpoolknooppunt:

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

   2. Controleer of de geconfigureerde NTP-server niet bereikbaar is:

      sudo timedatectl timesync-status
      

      Als de uitvoer er als volgt uitziet, is de NTP-server onbereikbaar en moet deze worden gewijzigd:

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

   3. Als u de NTP-server wilt bijwerken, voert u de volgende opdrachten uit om de NTP-server in het timesync-configuratiebestand in te stellen op een server die toegankelijk is vanaf de nodepool-VM:

      # 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. Start de timesync-service opnieuw op:

      sudo systemctl restart systemd-timesyncd.service
      

   5. Controleer of de NTP-server toegankelijk is:

      sudo timedatectl timesync-status
      

   6. Controleer of de klok de juiste tijd weergeeft:

      date
      

4. Zorg ervoor dat elk knooppuntpoolknooppunt dezelfde tijd weergeeft door de opdracht uit te voeren vanaf stap 3.f.

5. Als uw toepassing de tijd niet automatisch bijwerkt, start u de pods opnieuw.

Volgende stappen

• Overzicht van probleemoplossing
• Installatieproblemen en -fouten
• Bekende problemen met opslag