Oprava známých problémů a chyb při konfiguraci sítě v AKS Arc

Cloudový agent se nemusí úspěšně spustit při použití názvů cest s mezerami v nich.

Při použití set-AksHciConfig k určení -imageDir, -workingDir, -cloudConfigLocation, nebo -nodeConfigLocation parametrů s názvem cesty, který obsahuje znak mezery, například D:\Cloud Share\AKS HCI, cloud agent cluster service se nepodaří spustit následující (nebo podobné) chybová zpráva:

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'

Chcete-li tento problém vyřešit, použijte cestu, která neobsahuje mezery, C:\CloudShare\AKS-HCInapříklad .

Clustery připojené ke službě Azure Arc pro Kubernetes můžou mít hodnotu vlastnosti JSON distribution nastavenou na prázdný řetězec. U clusterů připojených ke službě AKS Arc se tato hodnota nastaví během počáteční instalace a po celou dobu trvání nasazení se nikdy nezmění.

Pokud chcete problém reprodukovat, otevřete okno Azure PowerShellu a spusťte následující příkazy:

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

Následuje příklad výstupu z tohoto příkazu:

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

Řešení problému

Pokud výstup vlastnosti JSON distribution vrátí prázdný řetězec, postupujte podle těchto pokynů a opravte cluster:

1. Zkopírujte následující konfiguraci do souboru s názvem patchBody.json:

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

   Důležité

   Pokud je váš cluster clusterem pro správu AKS, měla by být hodnota nastavená na aks_management. Pokud se jedná o cluster úloh, měl by být nastavený na aks_workloadhodnotu .

2. Z výstupu JSON, který jste získali výše, zkopírujte ID připojeného clusteru. Měl by se zobrazit jako dlouhý řetězec v následujícím formátu:

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

3. Spuštěním následujícího příkazu opravte cluster. Hodnota <cc_arm_id> by měla být ID získaná v kroku 2:

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

4. Zkontrolujte, jestli byl cluster úspěšně opraven spuštěním a az connectedk8s show -g <rg_name> -n <cc_name> ujistěte se, že je vlastnost distribution JSON správně nastavená.

Příznaky:

• Proxy server je povolený v AKS Arc. Služba WSSDAgent se zablokovala starting ve stavu. Zobrazí se takto:
• Test-NetConnection -ComputerName <computer IP/Name> -Port <port> z uzlu, ve kterém agent uzlu selhává směrem ke cloudovému agentu, funguje správně v systému (i když se agent wssdagent nepodaří spustit)
• Curl.exe z uzlu, na kterém agent selhává směrem ke cloudovému agentu, problém reprodukuje a zablokuje se: curl.exe https://<computerIP>:6500
• Pokud chcete tento problém vyřešit, předejte --noproxy příznak curl.exe. Curl vrátí chybu z wssdcloudagent. To se očekává, protože curl není klient GRPC. Curl se při odeslání příznaku --noproxy nezablokuje. Vrácení chyby se proto považuje za úspěch:

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

Je pravděpodobné, že se nastavení proxy serveru na hostiteli změnilo na vadný proxy server. Nastavení proxy serveru pro AKS Arc jsou proměnné prostředí, které se dědí z nadřazeného procesu na hostiteli. Tato nastavení se rozšíří jenom při spuštění nové služby nebo při restartování staré služby. Je možné, že na hostiteli byla nastavena chybná nastavení proxy serveru a byly rozšířeny do WSSDAgent po aktualizaci nebo restartování, což způsobilo selhání agenta WSSDAgent.

Nastavení proxy serveru budete muset opravit změnou proměnných prostředí na počítači. Na počítači změňte proměnné pomocí následujících příkazů:

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

Restartujte počítač tak, aby správce služeb a WSSDAgent zvedli pevný proxy server.

K této chybě dochází, protože při každém spuštění podu CAPH se pokusíte přihlásit ke cloudagentu a certifikát se uloží do dočasného svazku úložiště, který se vyčistí při restartování podu. Proto se při každém restartování podu zničí certifikát a provede se nový pokus o přihlášení.

Pokus o přihlášení spustí rutinu obnovení, která certifikát obnoví, když vyprší jeho platnost. Pod CAPH se rozhodne, jestli je potřeba přihlášení, pokud je certifikát dostupný nebo ne. Pokud je certifikát k dispozici, přihlášení se nepokusí za předpokladu, že rutina obnovení již existuje.

Při restartování kontejneru se však dočasný adresář nevyčistí, takže soubor je stále trvalý a pokus o přihlášení není proveden, což způsobí, že se rutina obnovení nespustí. To vede k vypršení platnosti certifikátu.

Pokud chcete tento problém zmírnit, restartujte pod CAPH pomocí následujícího příkazu:

kubectl delete pod pod-name

Při spuštění set-AksHciConfig se může zobrazit následující chyba:

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.

Ve většině případů k této chybě dochází v důsledku změny tokenu zabezpečení uživatele (kvůli změně členství ve skupině), změně hesla nebo vypršení platnosti hesla. Ve většině případů je možné tento problém napravit tím, že se odhlásíte z počítače a přihlásíte se znovu. Pokud k chybě stále dochází, můžete vytvořit lístek podpory prostřednictvím webu Azure Portal.

Tento problém způsobí, že cluster AKS Arc zůstane ve stavu ScalingControlPlane po delší dobu.

Reprodukování

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>

Tento problém je opravený v posledních verzích AKS Arc. Doporučujeme aktualizovat clustery AKS Arc na nejnovější verzi.

Pokud chcete tento problém zmírnit, obraťte se na podporu a ručně opravte stav uzlů řídicí roviny a odeberte podmínku MachineOwnerRemediatedCondition ze stavu počítače prostřednictvím kubectl.

Cluster úloh se nemusí najít, pokud jsou fondy IP adres dvou AKS v místních nasazeních Azure stejné nebo se překrývají. Pokud nasadíte dva hostitele AKS a použijete stejnou AksHciNetworkSetting konfiguraci pro oba, PowerShell i Centrum pro správu Windows pravděpodobně cluster úloh nenajde, protože server rozhraní API bude mít v obou clusterech přiřazenou stejnou IP adresu, což vede ke konfliktu.

Chybová zpráva, která se zobrazí, bude vypadat podobně jako v následujícím příkladu.

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.

Pokud chcete tento problém vyřešit, odstraňte jeden z clusterů a vytvořte nové nastavení sítě clusteru AKS, které má překrývající se síť s ostatními clustery.

Spuštění příkazu Get-AksHciClusterNetwork poskytuje seznam všech konfigurací virtuální sítě. Příkaz ale nezobrazuje aktuální přidělení IP adres.

Pokud chcete zjistit, jaké IP adresy se aktuálně používají ve virtuální síti, postupujte následovně:

1. Skupinu získáte spuštěním následujícího příkazu:

Get-MocGroup -location MocLocation

2. Pokud chcete získat seznam IP adres, které se aktuálně používají, a seznam dostupných nebo použitých virtuálních IP adres, spusťte následující příkaz:

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

3. Pomocí následujícího příkazu zobrazíte seznam virtuálních IP adres, které se aktuálně používají:

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

IP adresa clusteru se během předběžné kontroly zobrazuje jako neúspěšná. Tato předběžná kontrola testuje, že všechny adresy IPv4 a názvy sítí DNS jsou online a dostupné. Například neúspěšný název IPv4 nebo sítě může způsobit selhání tohoto testu.

Pokud chcete tento problém vyřešit, proveďte následující kroky:

1. Spusťte následující příkaz:

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

2. Ujistěte se, že jsou všechny názvy sítí a IP adresy v online stavu.

3. Spusťte následující dva příkazy:

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

   a pak

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

Když nasadíte AKS v Azure Local, může dojít k vypršení časového limitu nasazení v různých bodech procesu v závislosti na tom, kde došlo k chybné konfiguraci. Měli byste zkontrolovat chybovou zprávu a zjistit příčinu a místo, kde k ní došlo.

Například v následující chybě je bod, ve kterém došlo k Get-DownloadSdkRelease -Name "mocstack-stable"chybné konfiguraci:

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

To znamená, že fyzický místní uzel Azure dokáže přeložit název adresy URL pro stažení, msk8s.api.cdp.microsoft.comale uzel se nemůže připojit k cílovému serveru.

Pokud chcete tento problém vyřešit, musíte určit, kde došlo k rozpisu v toku připojení. Tady je několik kroků, jak problém vyřešit z fyzického uzlu clusteru:

1. Příkaz ping cílového názvu DNS: ping msk8s.api.cdp.microsoft.com.
2. Pokud se vám vrátí odpověď a žádný časový limit, základní síťová cesta funguje.
3. Pokud vyprší časový limit připojení, může dojít k přerušení cesty k datům. Další informace najdete v tématu kontrola nastavení proxy serveru. Nebo může dojít k přerušení návratové cesty, takže byste měli zkontrolovat pravidla brány firewall.

Aplikace, které jsou závislé na čase NTP, mohou aktivovat stovky falešných výstrah, když jsou mimo čas synchronizace. Pokud je cluster spuštěný v proxy prostředí, vaše fondy uzlů nemusí být schopné komunikovat s výchozím serverem NTP, time.windows.com přes proxy server nebo bránu firewall.

Alternativní řešení

Chcete-li tento problém vyřešit, aktualizujte konfiguraci serveru NTP na každém uzlu fondu uzlů, aby se synchronizovaly hodiny. Tím nastavíte také hodiny v každém z podů aplikace.

Požadavky

• Adresa serveru NTP, který je přístupný v každém uzlu fondu uzlů.
• Přístup k souboru kubeconfig clusteru úloh
• Přístup ke clusteru pro správu kubeconfig.

Kroky

1. Spuštěním následujícího kubectl příkazu pomocí kubeconfig clusteru úloh získejte seznam uzlů:

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

2. Spuštěním následujícího kubectl příkazu korelujte názvy uzlů z předchozího příkazu k uzlům fondu uzlů clusteru úloh. Poznamenejte si relevantní IP adresy z výstupu předchozího příkazu.

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

3. Pomocí výstupu z předchozích kroků spusťte následující kroky pro každý uzel fondu uzlů, který potřebuje aktualizaci konfigurace NTP:

   1. Připojení SSH k virtuálnímu počítači uzlu fondu uzlů:

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

   2. Ověřte, že je nakonfigurovaný server NTP nedostupný:

      sudo timedatectl timesync-status
      

      Pokud výstup vypadá takto, server NTP je nedostupný a je potřeba ho změnit:

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

   3. Pokud chcete aktualizovat server NTP, spusťte následující příkazy pro nastavení serveru NTP v konfiguračním souboru timesync na server, který je přístupný z virtuálního počítače fondu uzlů:

      # 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. Restartujte službu timesync:

      sudo systemctl restart systemd-timesyncd.service
      

   5. Ověřte, že je server NTP přístupný:

      sudo timedatectl timesync-status
      

   6. Ověřte, že hodiny zobrazují správný čas:

      date
      

4. Spuštěním příkazu z kroku 3.f se ujistěte, že každý uzel fondu uzlů zobrazuje stejný čas.

5. Pokud vaše aplikace automaticky neaktualizuje čas, restartujte jeho pody.

Další kroky

• Přehled řešení potíží
• Problémy s instalací a chyby
• Známé problémy s úložištěm