Résoudre les problèmes connus et les erreurs lors de la configuration d’un réseau dans AKS Arc

L’agent cloud peut ne pas démarrer correctement lors de l’utilisation des noms de chemins d’accès avec des espaces.

Quand vous utilisez Set-AksHciConfig pour spécifier des paramètres -imageDir, -workingDir, -cloudConfigLocation ou -nodeConfigLocation avec un nom de chemin contenant un espace (par exemple D:\Cloud Share\AKS HCI), le service de cluster de l’agent cloud ne parvient pas à démarrer et produit le message d’erreur suivant (ou similaire) :

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'

Pour contourner ce problème, utilisez un chemin sans espaces, par exemple, C:\CloudShare\AKS-HCI.

Les clusters connectés à Azure Arc pour Kubernetes peuvent avoir la valeur de la propriété distribution JSON définie sur une chaîne vide. Pour les clusters connectés à AKS Arc, cette valeur est définie pendant l’installation initiale et n’est jamais modifiée pendant la durée de vie du déploiement.

Pour reproduire le problème, ouvrez une fenêtre Azure PowerShell et exécutez les commandes suivantes :

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

Voici un exemple de sortie de cette commande :

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

Pour résoudre le problème

Si la sortie de la propriété JSON distribution retourne une chaîne vide, suivez ces instructions pour corriger votre cluster :

1. Copiez la configuration suivante dans un fichier appelé patchBody.json :

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

   Important

   Si votre cluster est un cluster de gestion AKS, la valeur doit être définie aks_managementsur . S’il s’agit d’un cluster de charge de travail, il doit être défini sur aks_workload.

2. À partir de la sortie JSON que vous avez obtenue ci-dessus, copiez votre ID de cluster connecté. Il doit apparaître sous la forme d’une longue chaîne au format suivant :

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

3. Exécutez la commande suivante pour corriger votre cluster. La <cc_arm_id> valeur doit être l’ID obtenu à l’étape 2 :

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

4. Vérifiez que votre cluster a été correctement corrigé en exécutant az connectedk8s show -g <rg_name> -n <cc_name> pour vous assurer que la propriété distribution JSON a été correctement définie.

Symptômes :

• Proxy activé dans AKS Arc. Le service WSSDAgent est bloqué dans l’état starting . S’affiche comme suit :
• Test-NetConnection -ComputerName <computer IP/Name> -Port <port> à partir du nœud où l’agent de nœud échoue vers l’agent cloud fonctionne correctement sur le système (même lorsque le wssdagent ne démarre pas)
• Curl.exe du nœud sur lequel l’agent échoue vers l’agent cloud reproduit le problème et se bloque : curl.exe https://<computerIP>:6500
• Pour résoudre le problème, passez l’indicateur --noproxy à curl.exe. Curl retourne une erreur de wssdcloudagent. Ceci est attendu, car curl n’est pas un client GRPC. Curl ne se bloque pas lorsque vous envoyez l’indicateur --noproxy . Par conséquent, le retour d’une erreur est considéré comme un succès ici :

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

Il est probable que les paramètres du proxy ont été modifiés en proxy défectueux sur l’hôte. Les paramètres de proxy pour AKS Arc sont des variables d’environnement héritées du processus parent sur l’hôte. Ces paramètres ne sont propagés qu’au démarrage d’un nouveau service ou à un ancien redémarrage ou mise à jour. Il est possible que les paramètres de proxy défectueux aient été définis sur l’hôte et qu’ils ont été propagés au WSSDAgent après une mise à jour ou un redémarrage, ce qui a provoqué l’échec du WSSDAgent.

Vous devez corriger les paramètres de proxy en modifiant les variables d’environnement sur l’ordinateur. Sur l’ordinateur, modifiez les variables avec les commandes suivantes :

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

Redémarrez l’ordinateur afin que le gestionnaire de services, ainsi que WSSDAgent, récupère le proxy fixe.

Cette erreur se produit car chaque fois que le pod CAPH est démarré, une connexion à cloudagent est tentée et le certificat est stocké dans le volume de stockage temporaire, ce qui va nettoyer les redémarrages du pod. Par conséquent, chaque fois qu’un pod est redémarré, le certificat est détruit et une nouvelle tentative de connexion est effectuée.

Une tentative de connexion démarre une routine de renouvellement, qui renouvelle le certificat lorsqu’il arrive à expiration. Le pod CAPH décide si une connexion est nécessaire si le certificat est disponible ou non. Si le certificat est disponible, la connexion n’est pas tentée, en supposant que la routine de renouvellement est déjà là.

Toutefois, lors d’un redémarrage d’un conteneur, le répertoire temporaire n’est pas nettoyé. Par conséquent, le fichier est toujours conservé et la tentative de connexion n’est pas effectuée, ce qui entraîne le non-démarrage de la routine de renouvellement. Cela entraîne l’expiration du certificat.

Pour atténuer ce problème, redémarrez le pod CAPH à l’aide de la commande suivante :

kubectl delete pod pod-name

Lors de l’exécution de la commande Set-AksHciConfig, vous pouvez rencontrer l’erreur suivante :

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.

La plupart du temps, cette erreur résulte d’une modification du jeton de sécurité de l’utilisateur (en raison d’une modification d’appartenance de groupe), d’un changement de mot de passe ou de l’expiration d’un mot de passe. Dans la plupart des cas, vous pouvez corriger le problème en vous déconnectant de l’ordinateur, puis en vous reconnectant. Si l’erreur persiste, vous pouvez créer un ticket de support via le Portail Azure.

Ce problème entraîne la persistance d’un cluster AKS Arc dans l’état ScaleControlPlane pendant une période prolongée.

Opérations à reproduire

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>

Ce problème a été résolu dans les versions récentes d’AKS Arc. Nous vous recommandons de mettre à jour vos clusters AKS Arc vers la dernière version.

Pour atténuer ce problème, contactez le support technique pour corriger manuellement l’état des nœuds du plan de contrôle pour supprimer la condition MachineOwnerRemediatedCondition de l’état de l’ordinateur via kubectl.

Le cluster de charge de travail peut ne pas être trouvé si les pools d’adresses IP de deux déploiements AKS sur Azure Local sont identiques ou chevauchent. Si vous déployez deux hôtes AKS et utilisez la même AksHciNetworkSetting configuration pour les deux, PowerShell et Windows Admin Center ne trouveront pas le cluster de charge de travail, car le serveur d’API reçoit la même adresse IP dans les deux clusters, ce qui entraîne un conflit.

Le message d’erreur que vous recevez doit ressembler à l’exemple ci-dessous.

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.

Pour résoudre le problème, supprimez l’un des clusters et créez un paramètre réseau de cluster AKS qui a un réseau qui ne se chevauche pas avec les autres clusters.

L’exécution de la commande Get-AksHciClusterNetwork fournit la liste de toutes les configurations de réseau virtuel. Toutefois, la commande n’affiche pas l’allocation actuelle des adresses IP.

Pour déterminer les adresses IP actuellement utilisées dans un réseau virtuel, procédez comme suit :

1. Pour récupérer le groupe, exécutez la commande suivante :

Get-MocGroup -location MocLocation

2. Pour récupérer la liste des adresses IP en cours d’utilisation, ainsi que la liste des adresses IP virtuelles disponibles ou utilisées, exécutez la commande suivante :

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

3. Utilisez la commande suivante pour afficher la liste des adresses IP virtuelles en cours d’utilisation :

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

Une adresse IP de cluster indique « Échec » pendant la vérification préalable. Cette vérification préalable teste que toutes les adresses IPv4 et les noms de réseau DNS sont en ligne et accessibles. Par exemple, un nom IPv4 ou réseau ayant échoué peut entraîner l’échec de ce test.

Pour résoudre ce problème, procédez comme suit :

1. Exécutez la commande suivante :

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

2. Vérifiez que tous les noms de réseau et toutes les adresses IP sont dans un état en ligne.

3. Exécutez les deux commandes suivantes :

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

   Et puis

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

Lorsque vous déployez AKS sur Azure Local, le déploiement peut expirer à différents points du processus en fonction de l’emplacement où la configuration est incorrecte. Vous devez examiner le message d’erreur pour déterminer la cause et l’endroit où celle-ci s’est produite.

Par exemple, dans l’erreur suivante, l’erreur de configuration s’est produite au niveau de 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"}

Cela indique que le nœud local Azure physique peut résoudre le nom de l’URL de téléchargement, msk8s.api.cdp.microsoft.commais que le nœud ne peut pas se connecter au serveur cible.

Pour résoudre ce problème, vous devez déterminer où la rupture s’est produite dans le processus de connexion. Voici quelques étapes à suivre pour tenter de résoudre le problème à partir du nœud de cluster physique :

1. Effectuez un test ping sur le nom DNS de destination : ping msk8s.api.cdp.microsoft.com.
2. Si vous recevez une réponse et que vous n’avez pas dépassé le délai d’attente, cela signifie que le chemin réseau de base fonctionne.
3. Si la connexion expire, il peut y avoir une rupture dans le chemin des données. Pour plus d’informations, consultez Vérifier les paramètres de proxy. Il est également possible qu’il y ait une rupture dans le chemin de retour. Vous devez donc vérifier les règles de pare-feu.

Les applications dépendantes du temps NTP peuvent déclencher des centaines de fausses alertes lorsqu’elles ne sont pas synchronisées. Si le cluster s’exécute dans un environnement proxy, vos pools de nœuds peuvent ne pas être en mesure de communiquer avec le serveur NTP par défaut, time.windows.com, via votre proxy ou votre pare-feu.

Solution de contournement

Pour contourner ce problème, mettez à jour la configuration du serveur NTP sur chaque nœud de pool de nœuds pour synchroniser les horloges. Cela définit également les horloges dans chacun de vos pods d’application.

Prérequis

• Adresse d’un serveur NTP accessible dans chaque nœud de pool de nœuds.
• Accès au fichier kubeconfig du cluster de charge de travail.
• Accès au cluster de gestion kubeconfig.

Étapes

1. Exécutez la commande suivante kubectl à l’aide du cluster de charge de travail kubeconfig pour obtenir la liste des nœuds dans celui-ci :

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

2. Exécutez la commande suivante kubectl pour mettre en corrélation les noms de nœuds de la commande précédente aux nœuds du pool de nœuds du cluster de charge de travail. Notez les adresses IP pertinentes de la sortie de la commande précédente.

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

3. À l’aide de la sortie des étapes précédentes, exécutez les étapes suivantes pour chaque nœud nodepool qui a besoin de sa configuration NTP mise à jour :

   1. SSH dans une machine virtuelle de nœud nodepool :

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

   2. Vérifiez que le serveur NTP configuré est inaccessible :

      sudo timedatectl timesync-status
      

      Si la sortie ressemble à ceci, le serveur NTP est inaccessible et doit être modifié :

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

   3. Pour mettre à jour le serveur NTP, exécutez les commandes suivantes pour définir le serveur NTP dans le fichier de configuration timesync sur un serveur accessible à partir de la machine virtuelle 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. Redémarrez le service timesync :

      sudo systemctl restart systemd-timesyncd.service
      

   5. Vérifiez que le serveur NTP est accessible :

      sudo timedatectl timesync-status
      

   6. Vérifiez que l’horloge affiche l’heure correcte :

      date
      

4. Assurez-vous que chaque nœud de pool de nœuds s’affiche en même temps en exécutant la commande à l’étape 3.f.

5. Si votre application ne met pas à jour son heure automatiquement, redémarrez ses pods.

Étapes suivantes

• Vue d’ensemble de la résolution des problèmes
• Problèmes et erreurs d’installation
• Problèmes de stockage connus