Résoudre les problèmes de cluster de gestion et de charge de travail Kubernetes dans AKS Arc

Pendant l’exécution de la commande Remove-ClusterNode, le nœud est évincé du cluster de basculement, mais si Remove-AksHciNode n’est pas exécuté par la suite, le nœud existe toujours dans CloudAgent.

Étant donné que le nœud a été supprimé du cluster, mais pas de CloudAgent, si vous utilisez le disque dur virtuel pour créer un nœud, une erreur « Fichier introuvable » s’affiche. Ce problème se produit parce que le disque dur virtuel se trouve dans le stockage partagé et que le nœud supprimé n’a pas accès à celui-ci.

Pour résoudre ce problème, supprimez un nœud physique du cluster, puis procédez comme suit :

1. Exécutez Remove-AksHciNode pour annuler l’inscription du nœud auprès de CloudAgent.
2. Effectuez une maintenance de routine, par exemple réimagez l’ordinateur.
3. Ajoutez le nœud au cluster.
4. Exécutez Add-AksHciNode pour inscrire le nœud auprès de CloudAgent.

Avec des clusters de grande taille, la commande Get-AksHciLogs peut lever une exception, échouer dans l’énumération des nœuds, ou ne pas générer de fichier de sortie c:\wssd\wssdlogs.zip.

Cela est dû au fait que la commande PowerShell pour compresser un fichier, « Compress-Archive », a une limite de taille de fichier de sortie de 2 Go.

Après la mise à niveau ou le scale-up du cluster de charge de travail, le pod de renouvellement de certificat est alors dans un état de boucle d’incident, car le pod attend le fichier YAML de marquage de certificat à partir de l’emplacement de fichier /etc/Kubernetes/pki.

Ce problème peut être lié à un fichier de configuration présent dans les machines virtuelles du plan de contrôle, mais pas dans les machines virtuelles du nœud worker.

Pour résoudre ce problème, copiez manuellement le fichier YAML de marquage de certificat à partir du nœud de plan de contrôle sur tous les nœuds worker.

1. Copiez le fichier YAML à partir de la machine virtuelle du plan de contrôle sur le cluster de charge de travail dans le répertoire actuel de votre machine hôte :

ssh clouduser@<comtrol-plane-vm-ip> -i (get-mocconfig).sshprivatekey
sudo cp /etc/kubernetes/pki/cert-tattoo-kubelet.yaml ~/
sudo chown clouduser cert-tattoo-kubelet.yaml
sudo chgrp clouduser cert-tattoo-kubelet.yaml
(Change file permissions here, so that `scp` will work)
scp -i (get-mocconfig).sshprivatekey clouduser@<comtrol-plane-vm-ip>:~/cert*.yaml .\

1. Copiez le fichier YAML de la machine hôte vers la machine virtuelle du nœud worker. Avant de copier le fichier, vous devez remplacer le nom de la machine dans le fichier YAML par le nom du nœud vers lequel vous effectuez la copie (il s’agit du nom du nœud pour le plan de contrôle du cluster de charge de travail).

scp -i (get-mocconfig).sshprivatekey .\cert-tattoo-kubelet.yaml clouduser@<workernode-vm-ip>:~/cert-tattoo-kubelet.yaml

3. Si les informations de propriétaire et de groupe figurant dans le fichier YAML ne sont pas déjà définies sur la racine, définissez-les sur la racine :

ssh clouduser@<workernode-vm-ip> -i (get-mocconfig).sshprivatekey
sudo cp ~/cert-tattoo-kubelet.yaml /etc/kubernetes/pki/cert-tattoo-kubelet.yaml (copies the certificate file to the correct location)
sudo chown root cert-tattoo-kubelet.yaml
sudo chgrp root cert-tattoo-kubelet.yaml

4. Répétez les étapes 2 et 3 pour tous les nœuds Worker.

Les commandes PowerShell Aks-Hci ne valident pas la mémoire disponible sur le serveur hôte avant de créer des nœuds Kubernetes. Ce problème peut entraîner un épuisement de la mémoire et empêcher le démarrage des machines virtuelles.

Cette défaillance n’étant actuellement pas gérée correctement, le déploiement cessera de répondre sans retourner de message d’erreur explicite. Si le déploiement cesse de répondre, ouvrez Observateur d'événements et recherchez un message d’erreur relatif à Hyper-V, indiquant que la mémoire est insuffisante pour démarrer la machine virtuelle.

Lors de l’exécution de Get-AksHciCluster pour vérifier l’état d’une installation d’AKS Arc dans Windows Admin Center, la sortie affiche une erreur : « Une version avec la version 1.0.3.10818 n’a pas été trouvée ». Toutefois, lors de l’exécution de Get-AksHciVersion, la même version a été installée. Cette erreur indique que la build a expiré.

Pour résoudre ce problème, exécutez Uninstall-AksHci, puis exécutez une nouvelle build AKS Arc.

Lorsque vous utilisez l’outil d’administration du cluster pour déplacer une machine virtuelle d’un nœud (Nœud A) vers un autre nœud (Nœud B) dans le cluster local Azure, la machine virtuelle peut échouer à démarrer sur le nouveau nœud. Lorsque vous replacez la machine virtuelle sur le nœud d’origine, elle ne démarre pas non plus.

Ce problème se produit parce que la logique de nettoyage de la première migration s’exécute de façon asynchrone. Par conséquent, la logique de « mise à jour de l’emplacement de la machine virtuelle » d’Azure Kubernetes Service trouve la machine virtuelle sur le Hyper-V d’origine sur le nœud A et la supprime au lieu d’annuler son inscription.

Pour contourner ce problème, vérifiez que la machine virtuelle a démarré correctement sur le nouveau nœud avant de la replacer sur le nœud d’origine.

Lorsque vous utilisez PowerShell pour créer un cluster avec des adresses IP statiques, puis tentez d’augmenter le nombre de nœuds Worker dans le cluster de charge de travail, l’installation est bloquée à « Nombre de plans de contrôle à 2, toujours en attente de l’état souhaité : 3 ». Après une période de temps, un autre message d’erreur s’affiche : « Erreur : délai d’attente de la condition ».

Quand la commande Get-AksHciCluster a été exécutée, vous avez vu que les nœuds de plan de contrôle avaient été créés et provisionnés, et que leur état était Ready (Prêt). Toutefois, lorsque kubectl get nodes a été exécuté, vous avez vu que les nœuds de plan de contrôle avaient été créés mais pas provisionnés, et que leur état n’était pas Ready (Prêt).

Si vous recevez cette erreur, vérifiez que les adresses IP ont bien été affectées aux nœuds créés à l’aide du Gestionnaire Hyper-V ou de PowerShell :

(Get-VM |Get-VMNetworkAdapter).IPAddresses |fl

Ensuite, vérifiez les paramètres réseau pour être sûr qu’il reste suffisamment d’adresses IP dans le pool pour créer des machines virtuelles supplémentaires.

Les commandes telles que Update-AksHci, , Update-AksHciCertificatesUpdate-AksHciClusterCertificateset toutes les interactions avec le cluster de gestion peuvent retourner « Erreur : Vous devez être connecté au serveur (non autorisé). »

Cette erreur peut se produire lorsque le fichier kubeconfig a expiré. Pour vérifier s’il a expiré, exécutez le script suivant :

$kubeconfig= $(get-kvaconfig).kubeconfig
$certDataRegex = '(?ms).*client-certificate-data:\s*(?<CertData>[^\n\r]+)'
$certDataMatch = Select-String -Path $kubeconfig -Pattern $certDataRegex
$certData = $certDataMatch.Matches[0].Groups['CertData'].Value
$certObject = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2
$certObject.Import([System.Convert]::FromBase64String($certData))
$expiryDate = $certObject.GetExpirationDateString()
$expiryDate

Si ce script affiche une date antérieure à la date actuelle, le fichier kubeconfig a expiré.

Pour atténuer le problème, copiez le fichier admin.conf , qui se trouve à l’intérieur de la machine virtuelle du plan de contrôle de gestion, sur l’hôte local Azure :

• Ssh vers la machine virtuelle du plan de contrôle de gestion :

  • Obtenez l’adresse IP de machine virtuelle du plan de contrôle de gestion :

    get-clusternode | % {Get-vm -computerName $_ } | get-vmnetworkadapter | select Name, IPAddresses
    

  • Ssh dans celui-ci :

    ssh -o StrictHostKeyChecking=no -i (Get-MocConfig).sshPrivateKey clouduser@<mgmt-control-plane-ip>
    

• Copiez le fichier à l’emplacement clouduser :

  cp /etc/kubernetes/admin.conf /home/clouduser/admin.conf
  

• Accordez l’accès à clouduser :

  sudo chown clouduser:clouduser admin.conf
  

• [Facultatif] Créez une sauvegarde du fichier kubeconfig :

  mv $(Get-KvaConfig).kubeconfig "$((Get-KvaConfig).kubeconfig).backup"
  

• Copiez le fichier :

  scp -i (get-mocconfig).sshPrivateKey clouduser@10.64.92.14:~/admin.conf $(Get-KvaConfig).kubeconfig
  

Lorsque vous vérifiez le gestionnaire Hyper-V, les demandes élevées d’UC et de mémoire pour le cluster de gestion peuvent être ignorées en toute sécurité. Elles sont dues à des pics d’utilisation des ressources de calcul lors du provisionnement des clusters de charge de travail.

L’augmentation de la taille de la mémoire ou du processeur pour le cluster de gestion n’ayant pas révélé d’amélioration significative, vous pouvez l’ignorer.

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

1. Créez un cluster Kubernetes.
2. Mettez à l’échelle le cluster en l’étendant à plus de deux nœuds.
3. Supprimez un nœud en exécutant la commande suivante :

kubectl delete node <node-name>

4. Retournez une liste des nœuds en exécutant la commande suivante :

kubectl get nodes

Le nœud supprimé n’est pas répertorié dans la sortie. 5. Ouvrez une fenêtre PowerShell avec des privilèges d’administration et exécutez la commande suivante :

get-vm

Le nœud supprimé est encore répertorié.

À cause de cette défaillance, le système ne détecte pas l’absence du nœud, et aucun nouveau nœud n’est mis en place.

Si vous n’utilisez pas de cluster de gestion ou de charge de travail pendant plus de 60 jours, les certificats expirent et vous devez les renouveler avant de pouvoir mettre à niveau AKS Arc. Lorsqu’un cluster AKS n’est pas mis à niveau dans les 60 jours, le jeton de plug-in KMS et les certificats expirent tous les deux dans les 60 jours. Le cluster est toujours fonctionnel. Toutefois, étant donné qu’il dépasse 60 jours, vous devez appeler le support Microsoft pour effectuer une mise à niveau. Si le cluster est redémarré après cette période, il reste dans un état non fonctionnel.

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

1. Réparez le certificat de cluster de gestion en pivotant manuellement le jeton, puis redémarrez le plug-in kmS et le conteneur.
2. Réparez les certificats mocctl en exécutant Repair-MocLogin.
3. Réparez les certificats de cluster de charge de travail en pivotant manuellement le jeton, puis redémarrez le plug-in et le conteneur KMS.

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 configuration AksHciNetworkSetting pour les deux, PowerShell et Windows Admin Center risquent de ne pas trouver le cluster de charge de travail, car la même adresse IP est attribuée au serveur API 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.

Le déploiement d’un cluster volumineux peut expirer après deux heures. Toutefois, il s’agit d’un délai d’attente statique.

Vous pouvez ignorer cette occurrence de délai d’attente lorsque l’opération est en cours d’exécution en arrière-plan. Utilisez la commande kubectl get nodes pour accéder à votre cluster et superviser la progression.

Lorsque vous tentez d’afficher un déploiement AKS sur Azure Local après quelques jours, Kubectl aucune de ses commandes n’a été exécutée. Le journal de plug-in du service de gestion de clés (KMS) affiche le message d’erreur rpc error:code = Unauthenticated desc = Valid Token Required_. After running [Repair-AksHciCerts](./reference/ps/repair-akshcicerts.md) to try to fix the issue, a different error appeared: _failed to repair cluster certificates.

L’applet de commande Repair-AksHciClusterCerts échoue si le serveur d’API est arrêté. Si AKS sur Azure Local n’a pas été mis à niveau pendant 60 jours ou plus, lorsque vous essayez de redémarrer le plug-in KMS, il ne démarre pas. Cela entraîne également l’échec du serveur d’API.

Pour résoudre ce problème, vous devez effectuer manuellement la rotation du jeton, puis redémarrer le plug-in et le conteneur KMS pour que le serveur d’API soit à nouveau opérationnel. Pour ce faire, exécutez les étapes suivantes :

1. Effectuez la rotation du jeton en exécutant la commande suivante :

   $ mocctl.exe security identity rotate --name "KMSPlugin-<cluster-name>-moc-kms-plugin" --encode=false --cloudFqdn (Get-AksHciConfig).Moc.cloudfqdn > cloudlogin.yaml
   

2. Copiez le jeton sur la machine virtuelle à l’aide de la commande suivante. Le paramètre ip dans la commande ci-dessous fait référence à l’adresse IP du plan de contrôle de l’hôte AKS.

   $ scp -i (Get-AksHciConfig).Moc.sshPrivateKey .\cloudlogin.yaml clouduser@<ip>:~/cloudlogin.yaml $ ssh -i (Get-AksHciConfig).Moc.sshPrivateKey clouduser@<ip> sudo mv cloudlogin.yaml /opt/wssd/k8s/cloudlogin.yaml
   

3. Redémarrez le plug-in KMS et le conteneur.

   Pour obtenir l’ID du conteneur, exécutez la commande suivante :

   $ ssh -i (Get-AksHciConfig).Moc.sshPrivateKey clouduser@<ip> "sudo docker container ls | grep 'kms'"
   

   La sortie doit contenir les champs suivants :

   CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
   

   La sortie doit être semblable à l’exemple qui suit :

   4169c10c9712 f111078dbbe1 "/kms-plugin" 22 minutes ago Up 22 minutes k8s_kms-plugin_kms-plugin-moc-lll6bm1plaa_kube-system_d4544572743e024431874e6ba7a9203b_1
   

4. Enfin, redémarrez le conteneur en exécutant la commande suivante :

   $ ssh -i (Get-AksHciConfig).Moc.sshPrivateKey clouduser@<ip> "sudo docker container kill <Container ID>"
   

Sur une installation AKS sur Azure Local avec l’extension Windows Admin Center version 1.82.0, le cluster de gestion a été configuré à l’aide de PowerShell et une tentative a été effectuée pour déployer un cluster de charge de travail à l’aide de Windows Admin Center. Le module PowerShell version 1.0.2 est installé sur l’une des machines, tandis que le module PowerShell 1.1.3 est installé sur les autres. La tentative de déploiement du cluster de charge de travail a échoué avec l’erreur « Impossible de trouver un paramètre correspondant au nom du paramètre « nodePoolName ». Cette erreur peut s’être produite en raison d’une incompatibilité de version. À compter de PowerShell version 1.1.0, l’applet de commande New-AksHciCluster comprend le paramètre -nodePoolName <String>, lequel est désormais obligatoire lors de l’utilisation de l’extension Windows Admin Center version 1.82.0.

Pour résoudre ce problème, effectuez l’une des opérations suivantes :

• Utilisez PowerShell pour mettre à jour manuellement le cluster de charge de travail vers la version 1.1.0 ou ultérieure.
• Utilisez Windows Admin Center pour mettre à jour le cluster vers la version 1.1.0 ou la dernière version de PowerShell.

Ce problème ne se produit pas si le cluster de gestion est déployé avec Windows Admin Center, car les derniers modules PowerShell sont déjà installés.

Lorsque vous déployez AKS sur Azure Local, puis exécutez kubectl get pods, les pods dans le même nœud sont bloqués dans l’état de fin . La machine rejette les connexions SSH, car le nœud rencontre probablement une forte demande de mémoire. Si ce problème se produit, c’est parce que les nœuds Windows sont sur-provisionnés et qu’il n’y a pas réserve pour les composants de base.

Pour éviter cette situation, ajoutez les limites de ressources et les demandes en ressources processeur et mémoire à la spécification des pods pour éviter un sur-provisionnement des nœuds. Les nœuds Windows ne prennent pas en charge l'éviction basée sur les limites de ressources. Vous devez donc estimer les quantités de ressources que les conteneurs utiliseront, puis vous assurer que les nœuds disposent de quantités suffisantes pour le processeur et la mémoire. Pour plus d’informations, consultez Configuration requise.

La mise à l’échelle automatique du cluster peut échouer lorsque vous utilisez la stratégie Azure suivante sur votre cluster de gestion d’hôte AKS : « Les clusters Kubernetes ne doivent pas utiliser l’espace de noms par défaut ». Cela se produit parce que la stratégie, lorsqu’elle est implémentée sur le cluster de gestion de l’hôte AKS, bloque la création de profils de mise à l’échelle automatique dans l’espace de noms par défaut. Pour résoudre ce problème, choisissez l’une des options suivantes :

• Désinstallez l’extension Azure Policy sur le cluster de gestion de l’hôte AKS. En savoir plus sur la désinstallation des extensions Azure Policy ici.
• Modifiez l’étendue de la stratégie Azure pour exclure les clusters de gestion d’hôtes AKS. En savoir plus sur les étendues Azure Policy ici.
• Définissez le mode d’application de stratégie sur « Désactivé » pour le cluster de gestion de l’hôte AKS. En savoir plus sur le mode d’application ici.

Il s’agit d’un problème connu avec akS sur la mise à jour de juillet local Azure (version 1.0.2.10723). L’erreur se produit, car le service CloudAgent expire pendant la distribution des machines virtuelles sur plusieurs volumes partagés de cluster dans le système.

Pour résoudre ce problème, vous devez effectuer une mise à niveau vers la dernière version d’AKS sur Azure Local.

Si vous approvisionnez un cluster AKS sur Azure Local avec zéro nœud Linux ou Windows, lorsque vous exécutez Get-AksHciCluster, la sortie est une chaîne vide ou une valeur null.

La valeur Null est un retour attendu pour zéro nœud.

Quand vous arrêtez un cluster de gestion ou de charge de travail pendant plus de quatre jours, les certificats expirent et le cluster est inaccessible. Les certificats expirent parce qu’ils sont permutés tous les 3 ou 4 jours pour des raisons de sécurité.

Pour redémarrer le cluster, vous devez réparer manuellement les certificats avant de pouvoir effectuer des opérations de cluster. Pour réparer les certificats, exécutez la commande Repair-AksHciClusterCerts suivante :

Repair-AksHciClusterCerts -Name <cluster-name> -fixKubeletCredentials

Lors du scale-out d’un cluster de charge de travail, les machines virtuelles Linux et Windows correspondantes ont été ajoutées en tant que nœuds Worker, mais elles n’ont pas été configurées comme des machines virtuelles hautement disponibles. Lors de l’exécution de la commande Get-ClusterGroup, la machine virtuelle Linux nouvellement créée n’a pas été configurée comme un groupe de clusters.

Il s’agit d’un problème connu. Après un redémarrage, la possibilité de configurer des machines virtuelles comme hautement disponibles est parfois perdue. La solution de contournement actuelle consiste à redémarrer wssdagent sur chacun des nœuds locaux Azure. Cela fonctionne uniquement pour les nouvelles machines virtuelles générées en créant des pools de nœuds lors de l’exécution d’une opération de scale-out ou lors de la création de clusters Kubernetes après le redémarrage des wssdagent nœuds. Toutefois, vous devez ajouter manuellement les machines virtuelles existantes au cluster de basculement.

Lorsque vous effectuez un scale-down d’un cluster, les ressources de cluster à haute disponibilité sont dans un état d’échec pendant que les machines virtuelles sont supprimées. Pour contourner ce problème, supprimez manuellement les ressources ayant échoué.

Un cluster AKS déployé sur une machine virtuelle Azure fonctionnait déjà correctement, mais après la désactivation de l’hôte AKS pendant plusieurs jours, la Kubectl commande ne fonctionnait pas. Après l’exécution de la commande Kubectl get nodes ou Kubectl get services, ce message d’erreur apparaît : Error from server (InternalError): an error on the server ("") has prevented the request from succeeding.

Ce problème se produit car l’hôte AKS a été désactivé pendant plus de quatre jours, ce qui a provoqué l’expiration des certificats. Les certificats font fréquemment l’objet d’une rotation au cours d’un cycle de quatre jours. Exécutez Repair-AksHciClusterCerts pour corriger le problème d’expiration des certificats.

Dans un cluster de charge de travail avec des adresses IP statiques et des nœuds Windows, tous les pods d’un nœud (y compris les daemonset pods) sont bloqués dans un état ContainerCreating . Lorsque vous tentez de vous connecter à ce nœud à l’aide de SSH, la connexion échoue avec une Connection timed out erreur.

Pour résoudre ce problème, utilisez le Gestionnaire Hyper-V ou le Gestionnaire du cluster de basculement pour désactiver la machine virtuelle de ce nœud. Après 5 à 10 minutes, le nœud doit avoir été recréé, avec tous les pods en cours d’exécution.

Lorsque kubelet est sous pression sur disque, il collecte des images conteneur inutilisées, qui peuvent inclure des images de pause, et quand cela se produit, ContainerD ne peut pas extraire l’image.

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

1. Connectez-vous au nœud concerné à l’aide de SSH et exécutez la commande suivante :

sudo su

2. Pour extraire l’image, exécutez la commande suivante :

crictl pull ecpacr.azurecr.io/kube-proxy:<Kubernetes version>

Étapes suivantes

• Vue d’ensemble de la résolution des problèmes
• Problèmes et erreurs de réseau
• Problèmes connus liés au stockage