Partager via

Résoudre les problèmes d’status non prêt d’un nœud sain

  • Article

Cet article décrit un scénario dans lequel l’status d’un nœud de cluster Azure Kubernetes Service (AKS) passe à Non prêt 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.

Conditions préalables

Symptômes

Le status d’un nœud de cluster dont l’état est sain (tous les services en cours d’exécution) passe de façon inattendue à Non prêt. Pour afficher les status d’un nœud, exécutez la commande kubectl describe suivante :

kubectl describe nodes

Cause

Kubelet a cessé de publier son status 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 s’affiche-t-il comme prévu ? (Par exemple, dans le champ Conditions, la message propriété contient-elle la chaîne « kubelet is posting ready status » ?) Dans ce cas, si vous disposez d’un accès SSH (Secure Shell) direct au nœud, case activée les événements récents pour comprendre l’erreur. Recherchez dans le fichier /var/log/messages . Vous pouvez également générer les fichiers journaux kubelet et conteneur daemon en exécutant les commandes de l’interpréteur de commandes suivantes :

journalctl --directory=. --unit=kubelet > kubelet.log
journalctl --directory=. --unit=docker > docker.log

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

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

Si tous les nœuds de cluster ont régressé à un status Non prêt, case activée si des modifications ont eu lieu au niveau du réseau. Voici quelques exemples de modifications au niveau du réseau :

  • Modifications du système DNS (Domain Name System)
  • Modifications des ports de pare-feu
  • Ajout de groupes de sécurité réseau (NSG)

Si des modifications ont été apportées au niveau du réseau, apportez les corrections nécessaires. Arrêtez et redémarrez les nœuds en cours d’exécution une fois que vous avez résolu les problèmes. 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 status Non prêt, arrêtez et redémarrez simplement les nœuds. Cette action seule peut retourner les nœuds à un état sain. Ensuite, case activée Azure Kubernetes Service diagnostics vue d’ensemble pour déterminer s’il existe des problèmes, tels que les problèmes suivants :

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

Si le diagnostics ne détecte aucun problème sous-jacent, vous pouvez ignorer les étapes restantes en toute sécurité.

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

AKS a-t-il diagnostics découvert 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 une longue période et comptez 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’attente par défaut de 30 minutes.

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

  • Déterminez si cette activité représente le comportement attendu ou, à la place, si elle montre que l’application se comporte mal. Utilisez des métriques et des journaux dans Azure Monitor pour étayer vos résultats. Par exemple, vous pouvez utiliser la catégorie Échec comme métrique SNAT Connections.

  • Évaluer 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 davantage de ports sortants 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.

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

Si AKS diagnostics découvrir des problèmes qui réduisent les performances d’IOPS, effectuez certaines des actions suivantes, le cas échéant :

  • Pour augmenter les IOPS sur les groupes de machines virtuelles identiques, modifiez la taille du disque en déployant un nouveau pool de nœuds.

  • Augmentez la taille de la référence SKU du nœud pour augmenter la mémoire et la capacité de traitement du processeur.

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

  • Limitez l’utilisation du processeur et de la mémoire pour les pods. Ces limites permettent d’éviter 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 répartir la charge entre les nœuds. Pour plus d’informations, consultez Contraintes de propagation de topologie de pod.

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

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

  • Le nœud status passe à Non prêt, mais il est redémarré par un correcteur 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 a échoué : Ressource temporairement indisponible par différents processus

    Les processus cités incluent containerd et éventuellement kubelet.

  • Le nœud status passe à Non prêt peu de temps après l’écriture pthread_create des entrées d’échec dans les fichiers journaux.

Les ID de processus (PID) représentent des threads. Le nombre par défaut de PID qu’un pod peut utiliser peut dépendre du système d’exploitation. Toutefois, le nombre par défaut est 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 ? Si ce n’est pas le cas, même une augmentation de huit fois à 262 144 PID peut ne pas être suffisante pour prendre en charge une application à ressources élevées.

Au lieu de cela, identifiez l’application en infraction, 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 temporairement le problème, 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 premiers 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 des PID au niveau du nœud :

  1. Configurez le nombre maximal de PID autorisés sur un pod dans 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 --system-reserved paramètres et --kube-reserved pour configurer les limites système et kubelet, respectivement.

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

Remarque

Par défaut, aucune de ces méthodes n’est configurée. En outre, vous ne pouvez actuellement pas configurer 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é en utilisant un niveau de service supérieur. Pour plus d’informations, consultez le contrat SLA de durée de fonctionnement Azure Kubernetes Service (AKS).

Informations supplémentaires