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

Spuštění cloudového agenta se nemusí podařit při použití názvů cest s mezerami.

Pokud použijete Set-AksHciConfig k zadání -imageDirparametrů , -workingDir, -cloudConfigLocationnebo -nodeConfigLocation s názvem cesty, který obsahuje znak mezery, například D:\Cloud Share\AKS HCI, služba clusteru cloudového agenta se nespustí s následující (nebo podobnou) chybovou zprávou:

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'

Pokud chcete tento problém obejít, 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 distribution JSON nastavenou na prázdný řetězec. U clusterů připojených ke službě AKS Arc se tato hodnota nastavuje během počáteční instalace a po celou dobu nasazení se nemění.

Pokud chcete problém reprodukovat, otevřete okno Azure PowerShell 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í tohoto 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, hodnota by měla být 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. Hodnotou <cc_arm_id> by mělo 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. Spuštěním příkazu az connectedk8s show -g <rg_name> -n <cc_name> zkontrolujte, že se cluster úspěšně opravil, abyste se ujistili, že je vlastnost distribution JSON správně nastavená.

Příznaky:

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

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

Je pravděpodobné, že nastavení proxy serveru bylo na hostiteli změněno na vadný proxy server. Nastavení proxy serveru pro AKS Arc jsou proměnné prostředí, které jsou zděděné z nadřazeného procesu na hostiteli. Tato nastavení se rozšíří jenom při spuštění nové služby nebo aktualizaci nebo restartování staré služby. Je možné, že na hostiteli byla nastavena chybná nastavení proxy serveru a po aktualizaci nebo restartování byla rozšířena do agenta WSSDAgent, 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č, aby správce služeb a WSSDAgent získali 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 cloudagent a certifikát se uloží na svazek dočasného úložiště, který se při restartování podu vyčistí. Proto se při každém restartování podu certifikát zničí a provede se nový pokus o přihlášení.

Při pokusu o přihlášení se spustí rutina prodlužování platnosti, která certifikát obnoví, jakmile se blíží vypršení jeho platnosti. Pod CAPH rozhodne, jestli je potřeba přihlášení, pokud je certifikát dostupný, nebo ne. Pokud je certifikát k dispozici, pokus o přihlášení se nepokusí za předpokladu, že rutina prodlužování platnosti už existuje.

Při restartování kontejneru se ale dočasný adresář nevyčistí, takže soubor zůstane zachovaný a pokus o přihlášení neproběhl, 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í rutiny 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.

K této chybě většinou 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 Azure Portal.

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

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 nedávný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 nasazení AKS ve službě Azure Stack HCI stejné nebo se překrývají. Pokud nasadíte dva hostitele AKS a pro oba použijete stejnou AksHciNetworkSetting konfiguraci, PowerShell a Windows Admin Center cluster úloh pravděpodobně nenajdou, protože serveru rozhraní API se v obou clusterech přiřadí stejná IP adresa, což způsobí konflikt.

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ě s clustery AKS, které má nepřekrývající se síť s ostatními clustery.

Spuštěním příkazu Get-AksHciClusterNetwork získáte 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, použijte následující postup:

1. Pokud chcete získat skupinu, spusťte následující příkaz:

Get-MocGroup -location MocLocation

2. Pokud chcete získat seznam aktuálně používaných IP adres 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 zobrazte 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 zobrazí jako neúspěšná. Tato předběžná kontrola otestuje, jestli jsou všechny adresy IPv4 a názvy sítí DNS online a dostupné. Selhání tohoto testu může způsobit například selhání protokolu IPv4 nebo názvu sítě.

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 síťové názvy 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 Stack HCI, 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 si projít chybovou zprávu, abyste zjistili 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 chybné konfiguraci, v 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"}

To znamená, že fyzický uzel Azure Stack HCI může přeložit název adresy URL pro stahování, 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 zjistit, kde v toku připojení došlo k rozpisu. Tady je několik kroků, jak se pokusit problém vyřešit z uzlu fyzického clusteru:

1. Příkazem Ping zadejte název cílového DNS: ping msk8s.api.cdp.microsoft.com.
2. Pokud se vám vrátí odpověď a časový limit nevypadá, 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 synchronizované mimo čas. Pokud je cluster spuštěný v proxy prostředí, je možné, že vaše fondy uzlů nebudou moct 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ů a synchronizujte hodiny. Tím nastavíte také hodiny v každém podu vaší 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 k clusteru pro správu kubeconfig.

Postup

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

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

2. Spuštěním následujícího kubectl příkazu porovnejte názvy uzlů z předchozího příkazu s uzly 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 aktualizovat konfiguraci NTP:

   1. SSH do virtuálního počítače uzlu fondu uzlů:

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

   2. Ověřte, že nakonfigurovaný server NTP není dostupný:

      sudo timedatectl timesync-status
      

      Pokud výstup vypadá takto, je server NTP 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 a nastavte server NTP v konfiguračním souboru časovéhosync 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 stejnou dobu.

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

Další kroky

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