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

Le démarrage de l’agent cloud peut échouer lors de l’utilisation de noms de chemin avec des espaces.

Quand vous utilisez Set-AksHciConfig pour spécifier des paramètres , -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 lors de 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 sur aks_management. 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é. Elle doit apparaître sous la forme d’une chaîne longue 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é à l’état starting . S’affiche comme suit :
• Test-NetConnection -ComputerName <computer IP/Name> -Port <port> 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 à partir de wssdcloudagent. Cela est attendu, car curl n’est pas un client GRPC. Curl ne reste pas bloqué en attendant quand 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 aient é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 sont propagés uniquement lorsqu’un nouveau service démarre ou qu’un ancien est mis à jour ou redémarre. Il est possible que des paramètres de proxy défectueux aient été définis sur l’hôte et qu’ils aient é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 du 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 et le WSSDAgent récupèrent 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, qui propre lors du redémarrage 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 approche de l’expiration. Le pod CAPH détermine 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 existe déjà.

Toutefois, lors du redémarrage d’un conteneur, le répertoire temporaire n’est pas nettoyé. Le fichier est donc toujours conservé et la tentative de connexion n’est pas effectuée, ce qui entraîne le 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 le maintien d’un cluster AKS Arc à l’état ScalingControlPlane pendant une période prolongée.

Pour 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 les status des nœuds du plan de contrôle afin de supprimer la condition MachineOwnerRemediatedCondition de la machine status via kubectl.

Il se peut que le cluster de charges de travail soit introuvable si les pools d’adresses IP de deux déploiements d’AKS sur Azure Stack HCI sont identiques ou se chevauchent. Si vous déployez deux hôtes AKS et utilisez la même AksHciNetworkSetting configuration pour les deux, PowerShell et Windows Admin Center risquent de ne pas trouver le cluster de charge de travail, car le serveur d’API se voit attribuer 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 nouveau 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 s’affiche comme « Échec » lors de la pré-vérification. Cette pré-vérification vérifie 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, effectuez les étapes suivantes :

1. Exécutez la commande suivante :

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

2. Assurez-vous que tous les noms réseau et 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 Stack HCI, le déploiement peut expirer à différents points du processus en fonction de l’emplacement où la configuration incorrecte s’est produite. 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 Azure Stack HCI peut résoudre le nom de l’URL de téléchargement (msk8s.api.cdp.microsoft.com), mais 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 qui dépendent du temps NTP peuvent déclencher des centaines de fausses alertes quand 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 nodepool pour synchroniser les horloges. Cela permet également de définir 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 qu’il contient :

   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 avec les nœuds nodepool 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 de pool de nœuds qui a besoin que sa configuration NTP soit mise à jour :

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

      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 indique l’heure correcte :

      date
      

4. Assurez-vous que chaque nœud nodepool affiche la même heure en exécutant la commande de l’étape 3.f.

5. Si votre application ne met pas à jour automatiquement son heure, 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