Risolvere i problemi noti e gli errori durante la configurazione di una rete in AKS Arc

È possibile che l'agente cloud non venga avviato correttamente quando si usano nomi di percorso con spazi in essi contenuti.

Quando si usa Set-AksHciConfig per specificare -imageDiri parametri , -workingDir, -cloudConfigLocationo -nodeConfigLocation con un nome di percorso contenente un carattere di spazio, ad esempio D:\Cloud Share\AKS HCI, il servizio cluster dell'agente cloud non inizierà con il messaggio di errore seguente (o simile):

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'

Per risolvere questo problema, usare un percorso che non include spazi, ad esempio C:\CloudShare\AKS-HCI.

I cluster connessi ad Azure Arc per Kubernetes possono avere il valore per la proprietà distribution JSON impostato su una stringa vuota. Per i cluster connessi ad Arc del servizio Azure Kubernetes, questo valore viene impostato durante l'installazione iniziale e non viene mai modificato per la durata della distribuzione.

Per riprodurre il problema, aprire una finestra Azure PowerShell ed eseguire i comandi seguenti:

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

Di seguito è riportato l'output di esempio di questo comando:

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

Per risolvere il problema

Se l'output per la proprietà JSON distribution restituisce una stringa vuota, seguire queste istruzioni per applicare patch al cluster:

1. Copiare la configurazione seguente in un file denominato patchBody.json:

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

   Importante

   Se il cluster è un cluster di gestione del servizio Azure Kubernetes, il valore deve essere impostato su aks_management. Se si tratta di un cluster del carico di lavoro, deve essere impostato su aks_workload.

2. Dall'output JSON ottenuto in precedenza copiare l'ID cluster connesso. Dovrebbe essere visualizzato come stringa lunga nel formato seguente:

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

3. Eseguire il comando seguente per applicare patch al cluster. Il <cc_arm_id> valore deve essere l'ID ottenuto nel passaggio 2:

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

4. Verificare che il cluster sia stato corretto eseguendo az connectedk8s show -g <rg_name> -n <cc_name> per assicurarsi che la proprietà distribution JSON sia stata impostata correttamente.

Sintomi:

• Proxy abilitato in AKS Arc. Il servizio WSSDAgent è bloccato nello starting stato. Viene visualizzato come segue:
• Test-NetConnection -ComputerName <computer IP/Name> -Port <port> dal nodo in cui l'agente del nodo non riesce verso l'agente cloud funziona correttamente nel sistema (anche quando l'agente wssdagent non viene avviato)
• Curl.exe dal nodo in cui l'agente non riesce verso l'agente cloud riproduce il problema ed è bloccato: curl.exe https://<computerIP>:6500
• Per risolvere il problema, passare il --noproxy flag a curl.exe. Curl restituisce un errore da wssdcloudagent. Questo comportamento è previsto perché curl non è un client GRPC. Curl non si blocca in attesa quando si invia il --noproxy flag. Pertanto, la restituzione di un errore è considerata un esito positivo in questo caso:

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

È probabile che le impostazioni proxy siano state modificate in un proxy difettoso nell'host. Le impostazioni proxy per AKS Arc sono variabili di ambiente ereditate dal processo padre nell'host. Queste impostazioni vengono propagate solo all'avvio di un nuovo servizio o al riavvio di uno precedente. È possibile che le impostazioni proxy difettose siano state impostate nell'host e che siano state propagate a WSSDAgent dopo un aggiornamento o un riavvio, che ha causato l'esito negativo di WSSDAgent.

Sarà necessario correggere le impostazioni proxy modificando le variabili di ambiente nel computer. Nel computer modificare le variabili con i comandi seguenti:

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

Riavviare il computer in modo che gestione servizi e WSSDAgent rilevino il proxy fisso.

Questo errore si verifica perché ogni volta che viene avviato il pod CAPH, viene eseguito un tentativo di accesso a cloudagent e il certificato viene archiviato nel volume di archiviazione temporaneo, che verrà rimosso al riavvio del pod. Pertanto, ogni volta che un pod viene riavviato, il certificato viene eliminato definitivamente e viene effettuato un nuovo tentativo di accesso.

Un tentativo di accesso avvia una routine di rinnovo, che rinnova il certificato alla scadenza. Il pod CAPH decide se è necessario un account di accesso se il certificato è disponibile o meno. Se il certificato è disponibile, l'account di accesso non viene tentato, presupponendo che la routine di rinnovo sia già presente.

Tuttavia, in un riavvio del contenitore, la directory temporanea non viene pulita, quindi il file è ancora persistente e il tentativo di accesso non viene eseguito, causando l'avvio della routine di rinnovo. Ciò comporta la scadenza del certificato.

Per attenuare questo problema, riavviare il pod CAPH usando il comando seguente:

kubectl delete pod pod-name

Quando si esegue Set-AksHciConfig, è possibile che venga visualizzato l'errore seguente:

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.

Nella maggior parte dei casi, questo errore si verifica in seguito a una modifica del token di sicurezza dell'utente (a causa di una modifica dell'appartenenza al gruppo), di una modifica della password o di una password scaduta. Nella maggior parte dei casi, è possibile risolvere il problema disconnettendosi dal computer ed eseguendo di nuovo l'accesso. Se l'errore persiste, è possibile creare un ticket di supporto tramite il portale di Azure.

Questo problema fa sì che un cluster Arc del servizio Azure Kubernetes rimanga nello stato ScalingControlPlane per un lungo periodo di tempo.

Per riprodurre

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>

Questo problema è stato risolto nelle versioni recenti di AKS Arc. È consigliabile aggiornare i cluster arc del servizio Azure Kubernetes alla versione più recente.

Per attenuare questo problema, contattare il supporto tecnico per applicare manualmente patch allo stato dei nodi del piano di controllo per rimuovere la condizione MachineOwnerRemediatedCondition dallo stato del computer tramite kubectl.

Il cluster del carico di lavoro potrebbe non essere trovato se i pool di indirizzi IP di due servizio Azure Kubernetes nelle distribuzioni di Azure Stack HCI sono uguali o si sovrappongono. Se si distribuiscono due host del servizio Azure Kubernetes e si usa la stessa AksHciNetworkSetting configurazione per entrambi, PowerShell e Windows Admin Center potrebbero non riuscire a trovare il cluster del carico di lavoro perché al server API verrà assegnato lo stesso indirizzo IP in entrambi i cluster, causando un conflitto.

Il messaggio di errore visualizzato sarà simile all'esempio illustrato di seguito.

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.

Per risolvere il problema, eliminare uno dei cluster e creare una nuova impostazione di rete del cluster del servizio Azure Kubernetes con una rete non sovrapposta con gli altri cluster.

L'esecuzione del comando Get-AksHciClusterNetwork fornisce un elenco di tutte le configurazioni di rete virtuale. Tuttavia, il comando non mostra l'allocazione corrente degli indirizzi IP.

Per scoprire quali indirizzi IP sono attualmente in uso in una rete virtuale, seguire questa procedura:

1. Per ottenere il gruppo, eseguire il comando seguente:

Get-MocGroup -location MocLocation

2. Per ottenere l'elenco degli indirizzi IP attualmente in uso e l'elenco degli indirizzi IP virtuali disponibili o usati, eseguire il comando seguente:

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

3. Usare il comando seguente per visualizzare l'elenco di indirizzi IP virtuali attualmente in uso:

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

Un indirizzo IP del cluster viene visualizzato come "Non riuscito" durante la verifica preliminare. Questa verifica preliminare verifica che tutti gli indirizzi IPv4 e i nomi di rete DNS siano online e raggiungibili. Ad esempio, un nome di rete o IPv4 non riuscito può causare l'esito negativo del test.

Per risolvere il problema, seguire questa procedura:

1. Eseguire il comando seguente:

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

2. Assicurarsi che tutti i nomi di rete e gli indirizzi IP siano in uno stato online.

3. Eseguire questi due comandi:

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

   E poi

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

Quando si distribuisce il servizio Azure Kubernetes in Azure Stack HCI, la distribuzione può verificarsi in momenti diversi del processo a seconda della posizione in cui si è verificata la configurazione errata. È consigliabile esaminare il messaggio di errore per determinare la causa e la posizione in cui si è verificata.

Nell'errore seguente, ad esempio, il punto in cui si è verificata la configurazione errata è :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"}

Ciò indica che il nodo fisico di Azure Stack HCI può risolvere il nome dell'URL di download, msk8s.api.cdp.microsoft.com, ma il nodo non può connettersi al server di destinazione.

Per risolvere questo problema, è necessario determinare dove si è verificata la suddivisione nel flusso di connessione. Ecco alcuni passaggi per provare a risolvere il problema dal nodo del cluster fisico:

1. Effettuare il ping del nome DNS di destinazione: ping msk8s.api.cdp.microsoft.com.
2. Se si riceve una risposta e non si verifica alcun timeout, il percorso di rete di base funziona.
3. Se si verifica il timeout della connessione, potrebbe verificarsi un'interruzione nel percorso dati. Per altre informazioni, vedere Controllare le impostazioni proxy. In alternativa, potrebbe esserci un'interruzione nel percorso restituito, quindi è consigliabile controllare le regole del firewall.

Le applicazioni dipendenti dal tempo NTP possono attivare centinaia di falsi avvisi quando non sono sincronizzati in tempo. Se il cluster è in esecuzione in un ambiente proxy, i pool di nodi potrebbero non essere in grado di comunicare con il server NTP predefinito, time.windows.com, tramite il proxy o il firewall.

Soluzione alternativa

Per risolvere questo problema, aggiornare la configurazione del server NTP in ogni nodo nodepool per sincronizzare gli orologi. In questo modo verranno impostati anche gli orologi in ognuno dei pod dell'applicazione.

Prerequisiti

• Indirizzo di un server NTP accessibile in ogni nodo del pool di nodi.
• Accesso al file kubeconfig del cluster del carico di lavoro.
• Accesso al cluster di gestione kubeconfig.

Passaggi

1. Eseguire il comando seguente kubectl usando il cluster del carico di lavoro kubeconfig per ottenere un elenco di nodi al suo interno:

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

2. Eseguire il comando seguente kubectl per correlare i nomi dei nodi dal comando precedente ai nodi del pool di nodi del cluster del carico di lavoro. Prendere nota degli indirizzi IP pertinenti dell'output del comando precedente.

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

3. Usando l'output dei passaggi precedenti, eseguire i passaggi seguenti per ogni nodo nodepool che richiede l'aggiornamento della configurazione NTP:

   1. SSH in una macchina virtuale del nodo nodepool:

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

   2. Verificare che il server NTP configurato non sia raggiungibile:

      sudo timedatectl timesync-status
      

      Se l'output è simile al seguente, il server NTP non è raggiungibile e deve essere modificato:

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

   3. Per aggiornare il server NTP, eseguire i comandi seguenti per impostare il server NTP nel file di configurazione timesync su uno accessibile dalla macchina virtuale nodepool:

      # 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. Riavviare il servizio timesync:

      sudo systemctl restart systemd-timesyncd.service
      

   5. Verificare che il server NTP sia accessibile:

      sudo timedatectl timesync-status
      

   6. Verificare che l'orologio mostri l'ora corretta:

      date
      

4. Assicurarsi che ogni nodo nodepool mostri la stessa volta eseguendo il comando del passaggio 3.f.

5. Se l'applicazione non aggiorna automaticamente il tempo, riavviare i pod.

Passaggi successivi

• Panoramica della risoluzione dei problemi
• Problemi di installazione ed errori
• Problemi noti dell'archiviazione