Partager via

Résoudre les problèmes de modification d’un nœud sain en état Non prêt

  • Article

Cet article décrit un scénario dans lequel l’état d’un nœud de cluster Azure Kubernetes Service (AKS) passe à Not Ready une fois que le nœud est dans un état sain pendant un certain temps. Cet article décrit la cause particulière et fournit une solution possible.

Prerequisites

Symptômes

L’état d’un nœud de cluster qui a un état sain (tous les services en cours d’exécution) change de façon inattendue sur Not Ready. Pour afficher l’état d’un nœud, exécutez la commande kubectl suivante :

kubectl describe nodes

Cause

Le kubelet a cessé de publier son état Prêt .

Examinez la sortie de la kubectl describe nodes commande pour rechercher le champ Conditions et les blocs Capacité et Allocatable . Le contenu de ces champs apparaît-il comme prévu ? (Par exemple, dans le Champ Conditions , la propriété contient-elle message la chaîne « kubelet affiche l’état prêt » ?) Dans ce cas, si vous avez directement accès à Secure Shell (SSH) au nœud, vérifiez les événements récents pour comprendre l’erreur. Examinez le fichier /var/log/messages . Vous pouvez également générer les fichiers journaux kubelet et conteneur en exécutant les commandes shell suivantes :

# To check messages file,
cat /var/log/messages

# To check kubelet and containerd daemon logs,
journalctl -u kubelet > kubelet.log
journalctl -u containerd > containerd.log

Après avoir exécuté ces commandes, examinez les messages et les fichiers journaux du démon pour plus d’informations sur l’erreur.

Solution

Étape 1 : Rechercher les modifications au niveau du réseau

Si tous les nœuds de cluster sont régressés à un état Non prêt , vérifiez si des modifications se sont produites au niveau du réseau. Voici quelques exemples de modifications au niveau du réseau :

  • Modifications du DNS (Domain Name System)
  • La règle de pare-feu change, comme le port, les noms de domaine complets (FQDN), etc.
  • Ajout de groupes de sécurité réseau (NSG)
  • Configurations de table de routage appliquées ou modifiées pour le trafic AKS

S’il y a eu des modifications au niveau du réseau, apportez les corrections nécessaires. Si vous disposez d’un accès SSH direct au nœud, vous pouvez utiliser la ou telnet la curl commande pour vérifier la connectivité aux exigences de trafic sortant AKS. Une fois que vous avez résolu les problèmes, arrêtez et redémarrez les nœuds. Si les nœuds restent dans un état sain après ces correctifs, vous pouvez ignorer en toute sécurité les étapes restantes.

Étape 2 : Arrêter et redémarrer les nœuds

Si seuls quelques nœuds sont régressés à un état Non prêt , arrêtez et redémarrez les nœuds. Cette action seule pourrait ramener les nœuds à un état sain. Vérifiez ensuite la vue d’ensemble des diagnostics Azure Kubernetes Service pour déterminer s’il existe des problèmes, tels que les problèmes suivants :

  • Erreurs de nœud
  • Échecs de traduction d’adresse réseau source (SNAT)
  • Problèmes de performance des opérations d’entrée/sortie des nœuds par seconde (IOPS)
  • Autres problèmes

Si les diagnostics ne détectent aucun problème sous-jacent et que les nœuds retournés à l’état Prêt, vous pouvez ignorer en toute sécurité les étapes restantes.

Étape 3 : Résoudre les problèmes SNAT pour les clusters d’API AKS publics

Les diagnostics AKS ont-ils détecté des problèmes SNAT ? Si c’est le cas, effectuez certaines des actions suivantes, le cas échéant :

  • Vérifiez si vos connexions restent inactives pendant un certain temps et s’appuient sur le délai d’inactivité par défaut pour libérer son port. Si les connexions présentent ce comportement, vous devrez peut-être réduire le délai d’expiration par défaut de 30 minutes.

  • Déterminez comment votre application crée une connectivité sortante. Par exemple, utilise-t-il la révision de code ou la capture de paquets ?

  • Déterminez si cette activité représente le comportement attendu ou, à la place, elle indique que l’application se comporte mal. Utilisez des métriques et des journaux d’activité dans Azure Monitor pour justifier vos découvertes. Par exemple, vous pouvez utiliser la catégorie Échec en tant que métrique Connexions SNAT.

  • Évaluez si les modèles appropriés sont suivis.

  • Évaluez si vous devez atténuer l’épuisement des ports SNAT en utilisant des adresses IP sortantes supplémentaires et plus de ports de sortie alloués. Pour plus d’informations, consultez Mettre à l’échelle le nombre d’adresses IP publiques sortantes gérées et configurer les ports sortants alloués.

Pour plus d’informations sur la résolution des problèmes d’exhaution de port SNAT, consultez Résoudre les problèmes d’épuisement des ports SNAT sur les nœuds AKS.

Étape 4 : Résoudre les problèmes de performances d’IOPS

Si les diagnostics AKS découvrent des problèmes qui réduisent les performances des E/S par seconde, effectuez certaines des actions suivantes, le cas échéant :

  • Pour augmenter les E/S par seconde sur les groupes de machines virtuelles identiques, choisissez une taille de disque supérieure qui offre de meilleures performances d’E/S par seconde en déployant un nouveau pool de nœuds. Le redimensionnement direct de VMSS directement n’est pas pris en charge. Pour plus d’informations sur le redimensionnement des pools de nœuds, consultez Redimensionner les pools de nœuds dans Azure Kubernetes Service (AKS).

  • Augmentez la taille du SKU du nœud pour plus de capacité de traitement de la mémoire et du processeur.

  • Envisagez d’utiliser le système d’exploitation éphémère.

  • Limitez l’utilisation du processeur et de la mémoire pour les pods. Ces limites aident à prévenir la consommation du processeur du nœud et les situations de mémoire insuffisante.

  • Utilisez des méthodes de topologie de planification pour ajouter d’autres nœuds et distribuer la charge entre les nœuds. Pour plus d’informations, consultez contraintes de répartition de topologie de pod.

Étape 5 : Résoudre les problèmes de threading

Les composants Kubernetes tels que kubelets et les runtimes en conteneur s’appuient fortement sur le threading, et ils génèrent régulièrement de nouveaux threads. Si l’attribution de nouveaux threads échoue, cet échec peut affecter la disponibilité de maintenance, comme suit :

  • L’état du nœud passe à Not Ready, mais il est redémarré par un correctif et est en mesure de récupérer.

  • Dans les fichiers journaux /var/log/messages et /var/log/syslog , il existe des occurrences répétées des entrées d’erreur suivantes :

    pthread_create failed : Ressource temporairement indisponible par divers processus

    Les processus cités incluent le conteneur et éventuellement le kubelet.

  • L’état du nœud passe à Non Prêt peu après l’écriture pthread_create des entrées d’échec dans les fichiers journaux.

Les ID de processus (PIDs) représentent les threads. Le nombre par défaut de PID qu’un pod peut utiliser peut dépendre du système d’exploitation. Cependant, le nombre par défaut est d’au moins 32 768. Ce montant est plus que suffisant pour la plupart des situations. Existe-t-il des exigences d’application connues pour des ressources PID plus élevées ? S’il n’y en a pas, alors même une augmentation de huit fois à 262 144 PID pourrait ne pas être suffisante pour accueillir une application à ressources élevées.

Identifiez plutôt l’application fautive, puis prenez les mesures appropriées. Envisagez d’autres options, telles que l’augmentation de la taille de la machine virtuelle ou la mise à niveau d’AKS. Ces actions peuvent atténuer le problème temporairement, mais elles ne garantissent pas que le problème ne réapparaîtra pas.

Pour surveiller le nombre de threads pour chaque groupe de contrôle (cgroup) et imprimer les huit principaux cgroups, exécutez la commande shell suivante :

watch 'ps -e -w -o "thcount,cgname" --no-headers | awk "{a[\$2] += \$1} END{for (i in a) print a[i], i}" | sort --numeric-sort --reverse | head --lines=8'

Pour plus d’informations, consultez Limites et réservations d’ID de processus.

Kubernetes propose deux méthodes pour gérer l’épuisement du PID au niveau du nœud :

  1. Configurez le nombre maximal de PID autorisés sur un pod au sein d’un kubelet à l’aide du --pod-max-pids paramètre. Cette configuration définit le pids.max paramètre dans le groupe cgroup de chaque pod. Vous pouvez également utiliser les paramètres et --kube-reserved les --system-reserved paramètres pour configurer les limites système et kubelet, respectivement.

  2. Configurez l’expulsion basée sur PID.

Note

Par défaut, aucune de ces méthodes n’est configurée. En outre, vous ne pouvez pas configurer actuellement l’une ou l’autre méthode à l’aide de la configuration de nœud pour les pools de nœuds AKS.

Étape 6 : Utiliser un niveau de service supérieur

Vous pouvez vous assurer que le serveur d’API AKS dispose d’une haute disponibilité à l’aide d’un niveau de service supérieur. Pour plus d’informations, consultez le contrat SLA de temps d’activité d’Azure Kubernetes Service (AKS).

Plus d’informations