Åtgärda kända problem och fel när du konfigurerar ett nätverk i AKS Arc

Molnagenten kan misslyckas med att starta när du använder sökvägsnamn med blanksteg i dem.

När du använder Set-AksHciConfig för att ange -imageDir, -workingDir, -cloudConfigLocationeller -nodeConfigLocation parametrar med ett sökvägsnamn som innehåller ett blankstegstecken, till exempel D:\Cloud Share\AKS HCI, kommer molnagentens klustertjänst inte att börja med följande (eller liknande) felmeddelande:

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'

Du kan undvika det här problemet genom att använda en sökväg som inte innehåller blanksteg, C:\CloudShare\AKS-HCItill exempel .

Azure Arc för Kubernetes-anslutna kluster kan ha värdet för JSON-egenskapen distribution inställt på en tom sträng. För AKS Arc-anslutna kluster anges det här värdet under den första installationen och ändras aldrig under distributionens livslängd.

Om du vill återskapa problemet öppnar du ett Azure PowerShell-fönster och kör följande kommandon:

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

Följande är exempelutdata från det här kommandot:

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

Så här löser du problemet

Om utdata för JSON-egenskapen distribution returnerar en tom sträng följer du de här anvisningarna för att korrigera klustret:

1. Kopiera följande konfiguration till en fil med namnet patchBody.json:

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

   Viktigt!

   Om klustret är ett AKS-hanteringskluster ska värdet anges till aks_management. Om det är ett arbetsbelastningskluster ska det vara inställt på aks_workload.

2. Från JSON-utdata som du fick ovan kopierar du ditt anslutna kluster-ID. Den bör visas som en lång sträng i följande format:

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

3. Kör följande kommando för att korrigera klustret. Värdet <cc_arm_id> ska vara det ID som erhölls i steg 2:

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

4. Kontrollera att klustret har korrigerats genom att köras az connectedk8s show -g <rg_name> -n <cc_name> för att kontrollera att JSON-egenskapen distribution har angetts korrekt.

Symtom:

• Proxy aktiverad i AKS Arc. WSSDAgent-tjänsten har fastnat i tillståndet starting . Visas som följande:
• Test-NetConnection -ComputerName <computer IP/Name> -Port <port> från noden där nodagenten misslyckas mot molnagenten fungerar korrekt i systemet (även när wssdagent inte startar)
• Curl.exe från noden där agenten misslyckas mot molnagenten återskapar problemet och fastnar: curl.exe https://<computerIP>:6500
• Åtgärda problemet genom att skicka --noproxy flaggan till curl.exe. Curl returnerar ett fel från wssdcloudagent. Detta är förväntat eftersom curl inte är en GRPC-klient. Curl fastnar inte i väntan när du skickar --noproxy flaggan. Så att returnera ett fel anses vara en framgång här:

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

Det är troligt att proxyinställningarna har ändrats till en felaktig proxy på värden. Proxyinställningarna för AKS Arc är miljövariabler som ärvs från den överordnade processen på värden. De här inställningarna sprids bara när en ny tjänst startas eller en gammal uppdateras eller startas om. Det är möjligt att felaktiga proxyinställningar har angetts på värden och att de har spridits till WSSDAgent efter en uppdatering eller omstart, vilket har gjort att WSSDAgent misslyckades.

Du måste åtgärda proxyinställningarna genom att ändra miljövariablerna på datorn. På datorn ändrar du variablerna med följande kommandon:

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

Starta om datorn så att servicehanteraren och WSSDAgent hämtar den fasta proxyn.

Det här felet beror på att varje gång CAPH-podden startas görs ett försök att logga in på cloudagent och certifikatet lagras i den tillfälliga lagringsvolymen, vilket rensas vid omstarter av poddar. Varje gång en podd startas om förstörs därför certifikatet och ett nytt inloggningsförsök görs.

Ett inloggningsförsök startar en förnyelserutin som förnyar certifikatet när det snart upphör att gälla. CAPH-podden avgör om en inloggning behövs om certifikatet är tillgängligt eller inte. Om certifikatet är tillgängligt görs inte inloggningen, förutsatt att förnyelserutinen redan finns där.

Vid omstart av en container rensas dock inte den tillfälliga katalogen, så filen är fortfarande sparad och inloggningsförsöket görs inte, vilket gör att förnyelserutinen inte startas. Detta leder till att certifikatet upphör att gälla.

Du kan åtgärda det här problemet genom att starta om CAPH-podden med hjälp av följande kommando:

kubectl delete pod pod-name

När du kör Set-AksHciConfig kan följande fel uppstå:

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.

För det mesta uppstår det här felet till följd av en ändring i användarens säkerhetstoken (på grund av en ändring i gruppmedlemskapet), en lösenordsändring eller ett lösenord som har upphört att gälla. I de flesta fall kan problemet åtgärdas genom att logga ut från datorn och logga in igen. Om felet fortfarande inträffar kan du skapa en supportbegäran via Azure Portal.

Det här problemet gör att ett AKS Arc-kluster förblir i scalingControlPlane-tillståndet under en längre tid.

Återskapa

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>

Det här problemet har åtgärdats i de senaste AKS Arc-versionerna. Vi rekommenderar att du uppdaterar dina AKS Arc-kluster till den senaste versionen.

För att åtgärda det här problemet kontaktar du supporten för att manuellt korrigera statusen för kontrollplansnoderna för att ta bort villkoret MachineOwnerRemediatedCondition från datorns status via kubectl.

Det går inte att hitta arbetsbelastningsklustret om IP-adresspoolerna för två AKS på Azure Local-distributioner är desamma eller överlappar varandra. Om du distribuerar två AKS-värdar och använder samma AksHciNetworkSetting konfiguration för båda, kommer PowerShell och Windows Admin Center eventuellt inte att hitta arbetsbelastningsklustret eftersom API-servern tilldelas samma IP-adress i båda klustren, vilket resulterar i en konflikt.

Felmeddelandet du får ser ut ungefär som exemplet nedan.

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.

Lös problemet genom att ta bort ett av klustren och skapa en ny nätverksinställning för AKS-kluster som har ett icke-överlappande nätverk med de andra klustren.

När du kör kommandot Get-AksHciClusterNetwork finns en lista över alla konfigurationer för virtuella nätverk. Kommandot visar dock inte den aktuella allokeringen av IP-adresserna.

Om du vill ta reda på vilka IP-adresser som används i ett virtuellt nätverk använder du stegen nedan:

1. Kör följande kommando för att hämta gruppen:

Get-MocGroup -location MocLocation

2. Kör följande kommando för att hämta listan över IP-adresser som används för närvarande och listan över tillgängliga eller använda virtuella IP-adresser:

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

3. Använd följande kommando för att visa listan över virtuella IP-adresser som för närvarande används:

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

En kluster-IP-adress visas som "Misslyckades" under förkontrollen. Den här förkontrollen testar att alla IPv4-adresser och DNS-nätverksnamn är online och kan nås. Ett misslyckat IPv4- eller nätverksnamn kan till exempel göra att testet misslyckas.

Lös detta genom att utföra följande steg:

1. Kör följande kommando:

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

2. Kontrollera att alla nätverksnamn och IP-adresser är i onlinetillstånd.

3. Kör följande två kommandon:

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

   och sedan

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

När du distribuerar AKS på Azure Local kan distributionen överskrida tidsgränsen vid olika tidpunkter i processen beroende på var felkonfigurationen inträffade. Du bör granska felmeddelandet för att fastställa orsaken och var den inträffade.

I följande fel finns till exempel den punkt där felkonfigurationen inträffade i 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"}

Detta anger att den fysiska lokala Azure-noden kan matcha namnet på nedladdnings-URL:en, msk8s.api.cdp.microsoft.com, men noden kan inte ansluta till målservern.

För att lösa det här problemet måste du ta reda på var uppdelningen inträffade i anslutningsflödet. Här följer några steg för att försöka lösa problemet från den fysiska klusternoden:

1. Pinga målets DNS-namn: ping msk8s.api.cdp.microsoft.com.
2. Om du får ett svar tillbaka och ingen tidsgräns fungerar den grundläggande nätverkssökvägen.
3. Om anslutningen överskrider tidsgränsen kan det uppstå en paus i datasökvägen. Mer information finns i kontrollera proxyinställningar. Eller så kan det finnas en paus i retursökvägen, så du bör kontrollera brandväggsreglerna.

Program som är NTP-tidsberoende kan utlösa hundratals falska aviseringar när de inte synkroniseras. Om klustret körs i en proxymiljö kanske nodpoolerna inte kan kommunicera med NTP-standardservern, time.windows.com, via proxyn eller brandväggen.

Lösning

Du kan undvika det här problemet genom att uppdatera NTP-serverkonfigurationen på varje nodpoolnod för att synkronisera klockorna. Om du gör det ställs även klockorna in i var och en av dina programpoddar.

Förutsättningar

• En adress till en NTP-server som är tillgänglig i varje nodpoolnod.
• Åtkomst till kubeconfig-filen för arbetsbelastningsklustret.
• Åtkomst till hanteringsklustret kubeconfig.

Steg

1. Kör följande kubectl kommando med kubeconfig för arbetsbelastningsklustret för att hämta en lista över noder i det:

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

2. Kör följande kubectl kommando för att korrelera nodnamnen från föregående kommando till arbetsbelastningsklustrets noder i nodpoolen. Anteckna relevanta IP-adresser från föregående kommandos utdata.

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

3. Kör följande steg för varje nodpoolnod som behöver NTP-konfigurationen uppdaterad med hjälp av utdata från föregående steg:

   1. SSH till en virtuell nodnod för nod:

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

   2. Kontrollera att den konfigurerade NTP-servern inte kan nås:

      sudo timedatectl timesync-status
      

      Om utdata ser ut så här går det inte att nå NTP-servern och den måste ändras:

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

   3. Om du vill uppdatera NTP-servern kör du följande kommandon för att ange NTP-servern i tidssynkron konfigurationsfilen till en som är tillgänglig från den virtuella nodepool-datorn:

      # 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. Starta om timesync-tjänsten:

      sudo systemctl restart systemd-timesyncd.service
      

   5. Kontrollera att NTP-servern är tillgänglig:

      sudo timedatectl timesync-status
      

   6. Kontrollera att klockan visar rätt tid:

      date
      

4. Kontrollera att varje nodpoolnod visar samma tid genom att köra kommandot från steg 3.f.

5. Om programmet inte uppdaterar sin tid automatiskt startar du om poddarna.

Nästa steg

• Felsökningsöversikt
• Installationsproblem och -fel
• Kända problem med lagring