Container Service for Kubernetes:Troubleshooting node exceptions

Cause

Les causes typiques incluent un processus Kubelet anormal, une exception du runtime de conteneur ou une configuration Kubelet incorrecte.

Symptômes

Le statut de Kubelet est inactive.

Solution

1. Exécutez la commande suivante pour redémarrer Kubelet. Cette action n'affecte pas les conteneurs en cours d'exécution.

   systemctl restart kubelet

2. Une fois Kubelet redémarré, connectez-vous au nœud et exécutez la commande suivante pour vérifier son statut.

   systemctl status kubelet

3. Si le statut de Kubelet reste anormal, connectez-vous au nœud et exécutez la commande suivante pour afficher ses journaux.

   journalctl -u kubelet

   • Si les journaux contiennent des messages d'erreur spécifiques, utilisez les mots-clés de ces messages pour résoudre le problème.

   • Si la configuration de Kubelet est incorrecte, exécutez les commandes suivantes pour la corriger.

     vi /etc/systemd/system/kubelet.service.d/10-kubeadm.conf   # Modify the Kubelet configuration.
     systemctl daemon-reload;systemctl restart kubelet         # Reload the configuration and restart Kubelet.

Cause

Les causes courantes incluent une configuration dockerd non valide, une charge de processus élevée ou une charge de nœud élevée.

Symptômes

• Le statut de dockerd est inactive.

• Le statut de dockerd est active (running), mais le daemon fonctionne mal, ce qui provoque une exception de nœud. Des commandes telles que docker ps et docker exec peuvent échouer.

• La condition RuntimeOffline du nœud est True.

• Une exception dockerd déclenche une alerte si vous avez configuré l'alerting pour les exceptions de nœud de cluster. Pour plus d'informations sur la configuration des règles d'alerte, consultez Gestion des alertes ACK.

Solution

1. Exécutez la commande suivante pour redémarrer dockerd :

   systemctl restart docker

2. Connectez-vous au nœud et exécutez la commande suivante pour vérifier le statut de dockerd :

   systemctl status docker

3. Si le statut reste anormal, vérifiez les journaux de dockerd :

   journalctl -u docker

Cause

Ce problème est souvent causé par une configuration containerd non valide, une charge de processus élevée ou une charge de nœud élevée.

• Le statut de containerd est inactive.

• La condition RuntimeOffline du nœud est True.

• Si l'alerting est configuré pour les exceptions de nœud de cluster, vous serez notifié lorsqu'une exception containerd se produit. Pour plus d'informations, consultez Gestion des alertes ACK.

Solution

1. Exécutez la commande suivante pour redémarrer containerd :

   systemctl restart containerd

2. Une fois containerd redémarré, connectez-vous au nœud et exécutez la commande suivante pour vérifier son statut :

   systemctl status containerd

3. Si le statut reste anormal après le redémarrage, connectez-vous au nœud et exécutez la commande suivante pour afficher les journaux de containerd :

   journalctl -u containerd

Cause

Un processus NTP anormal cause généralement ce problème.

Symptômes

• Le statut de chronyd est inactive.

• La condition de nœud NTPProblem est True.

• Si vous avez configuré des alertes pour les exceptions de nœud de cluster, vous recevrez une alerte lorsque le service de temps d'un nœud est anormal. Pour plus d'informations sur la configuration des alertes, consultez Gestion des alertes ACK.

Solution

1. Exécutez la commande suivante pour redémarrer chronyd :

   systemctl restart chronyd

2. Une fois chronyd redémarré, connectez-vous au nœud et exécutez la commande suivante pour vérifier que son statut est normal :

   systemctl status chronyd

3. Si le statut est toujours anormal après le redémarrage, connectez-vous au nœud et exécutez la commande suivante pour afficher les journaux de chronyd :

   journalctl -u chronyd

Cause

Le Pod Lifecycle Event Generator (PLEG) enregistre les événements tout au long du cycle de vie du pod, tels que les démarrages et les terminaisons de conteneurs. L'exception PLEG is not healthy est généralement causée par des problèmes avec le runtime de conteneur sur le nœud ou un défaut dans la version systemd du nœud.

Symptômes

• Le statut du nœud est NotReady.

• Les journaux de kubelet contiennent l'entrée suivante.

  I0729 11:20:59.245243    9575 kubelet.go:1823] skipping pod synchronization - PLEG is not healthy: pleg was last seen active 3m57.138893648s ago; threshold is 3m0s.

• Si vous avez configuré des alertes pour les exceptions de nœud de cluster, vous recevez une alerte lorsqu'une exception PLEG se produit. Pour configurer les alertes, consultez Gestion des alertes ACK.

Solution

1. Redémarrez séquentiellement les composants clés du nœud dockerd/containerd et kubelet, puis vérifiez si le nœud a récupéré.

2. Si le redémarrage des composants clés ne résout pas le problème, redémarrez le nœud. Consultez redémarrer une instance pour obtenir des instructions.

   Avertissement

   Le redémarrage du nœud peut interrompre vos charges de travail. Procédez avec prudence.

3. Si le nœud exécute CentOS 7.6, consultez ["Erreur \"PLEG is not healthy\" dans les journaux kubelet sur CentOS 7.6"]()Erreur "Reason:KubeletNotReady Message:PLEG is not healthy:" dans les journaux kubelet sur CentOS 7.6.

Cause

Ce problème survient généralement lorsque les nœuds du cluster disposent de ressources insuffisantes.

Symptômes

Un pod ne sera pas planifié sur un nœud si ses demandes totales de ressources dépassent les ressources disponibles du nœud (allouables moins allouées).

kubectl describe node [$nodeName]

Allocatable:
  cpu:                3900m
  ephemeral-storage:  114022843818
  hugepages-1Gi:      0
  hugepages-2Mi:      0
  memory:             12601Mi
  pods:               60
Allocated resources:
  (Total limits may be over 100 percent, i.e., overcommitted.)
  Resource           Requests    Limits
  --------           --------    ------
  cpu                725m (18%)  6600m (169%)
  memory             977Mi (7%)  16640Mi (132%)
  ephemeral-storage  0 (0%)      0 (0%)
  hugepages-1Gi      0 (0%)      0 (0%)
  hugepages-2Mi      0 (0%)      0 (0%)

Solution

Pour résoudre ce problème, réduisez la charge du nœud en utilisant l'une des méthodes suivantes :

• Supprimez les pods inutiles pour réduire la charge du nœud. Pour plus d'informations, consultez Gérer les pods.

• Ajustez la configuration des ressources pour vos pods en fonction de vos besoins métier. Pour plus d'informations, consultez Définir les demandes et limites de CPU et de mémoire pour un conteneur.

• Vous pouvez utiliser la fonctionnalité de profilage des ressources fournie par ACK pour obtenir des suggestions de configuration des ressources pour les conteneurs basées sur les données historiques d'utilisation des ressources. Cela simplifie la configuration des demandes et des limites de ressources pour les conteneurs. Pour plus d'informations, consultez Profilage des ressources.

• Ajoutez de nouveaux nœuds au cluster. Pour plus d'informations, consultez Créer et gérer des pools de nœuds.

• Mettez à niveau les configurations des nœuds. Pour plus d'informations, consultez Mettre à niveau ou rétrograder les configurations d'un nœud de travail.

Pour plus d'informations, consultez CPU de nœud insuffisant, Mémoire de nœud insuffisante - MemoryPressure et Espace disque de nœud insuffisant - DiskPressure.

Cause

Les conteneurs qui consomment des ressources CPU excessives sur un nœud causent généralement ce problème.

Symptômes

• Des ressources CPU insuffisantes peuvent entraîner un statut anormal du nœud.

• Si des alertes sont configurées pour les exceptions de nœud de cluster, une alerte est déclenchée lorsque l'utilisation du CPU du nœud atteint ou dépasse 85 %. Pour plus d'informations sur la configuration des alertes, consultez Gestion des alertes ACK.

Solution

• Examinez la courbe d'utilisation du CPU du nœud pour identifier quand l'exception s'est produite et quels processus sur le nœud consomment des ressources CPU excessives. Pour plus d'informations, consultez Vérifier les données de surveillance d'un nœud.

• Réduisez la charge sur le nœud. Pour plus d'informations, consultez Ressources de nœud insuffisantes pour la planification.

• Si nécessaire, redémarrez le nœud affecté. Pour plus d'informations, consultez Redémarrer une instance.

  Avertissement

  Le redémarrage du nœud peut interrompre vos services. Procédez avec prudence.

Cause

Ce problème survient généralement lorsque les conteneurs sur un nœud consomment une mémoire excessive, laissant le nœud avec une mémoire disponible insuffisante.

Symptômes

• Lorsque la mémoire disponible d'un nœud tombe en dessous du seuil spécifié par memory.available, la condition MemoryPressure du nœud est définie sur True et les conteneurs sur le nœud sont expulsés. Pour plus d'informations sur l'expulsion des nœuds, consultez Expulsion sous pression de nœud.

• Lorsqu'un nœud manque de mémoire, vous pouvez observer les symptômes courants suivants :

  • La condition MemoryPressure du nœud est True.

  • Lorsque les conteneurs sur le nœud sont expulsés :

    • Les événements pour les conteneurs expulsés incluent le message The node was low on resource: memory.

    • Les événements du nœud incluent le message attempting to reclaim memory.

  • Un OOM système peut également se produire, ce qui est indiqué par le message System OOM dans les événements du nœud.

• Vous pouvez configurer des alertes pour être notifié lorsque l'utilisation de la mémoire d'un nœud atteint ou dépasse 85 %. Consultez Gestion des alertes ACK pour savoir comment faire.

Solution

• Analysez la courbe d'utilisation de la mémoire dans les données de surveillance du nœud pour identifier précisément quand le problème s'est produit, et inspectez les processus en cours d'exécution pour détecter des fuites de mémoire. Pour plus d'informations, consultez Vérifier les données de surveillance d'un nœud.

• Réduisez la charge sur le nœud. Pour plus d'informations, consultez Ressources de nœud insuffisantes pour la planification.

• Si nécessaire, redémarrez le nœud affecté. Pour plus d'informations, consultez Redémarrer une instance.

  Avertissement

  Attention : Le redémarrage d'un nœud peut interrompre vos services.

Cause

Ce problème survient généralement lorsque les conteneurs d'un nœud consomment un nombre excessif d'inodes.

Symptômes

• Lorsque le nombre d'inodes disponibles sur un nœud descend en dessous du seuil inodesFree, la condition InodesPressure est définie sur True et les conteneurs du nœud sont expulsés. Pour plus d'informations, consultez node-pressure eviction.

• En cas de pénurie d'inodes sur un nœud, vous pouvez observer les messages d'erreur courants suivants :

  • La condition de nœud InodesPressure est définie sur True.

  • Lors de l'expulsion des conteneurs du nœud :

    • Les événements liés aux conteneurs expulsés contiennent le message : The node was low on resource: inodes.

    • Les événements du nœud contiennent le message : attempting to reclaim inodes.

• Si vous avez configuré des alertes pour les exceptions de nœud dans votre cluster, vous recevez une notification lorsqu'un nœud manque d'inodes. Pour savoir comment configurer ces alertes, consultez la rubrique ACK alert management.

Solution

• Examinez la courbe d'utilisation des inodes dans les données de surveillance du nœud afin d'identifier le moment où l'exception s'est produite et de détecter les processus consommant un nombre excessif d'inodes. Pour plus d'informations, consultez la section Vérification des données de surveillance des nœuds.

• Pour résoudre d'autres problèmes connexes, reportez-vous à la rubrique Résolution des problèmes « no space left » sous Linux.

Cause

Ce problème se produit lorsque les conteneurs d'un nœud consomment trop de PIDs, épuisant ainsi les PIDs disponibles du nœud.

Symptômes

• Lorsque les PIDs disponibles d'un nœud descendent en dessous du seuil pid.available, la condition NodePIDPressure est définie sur True et les pods du nœud sont expulsés. Pour plus d'informations sur l'expulsion des nœuds, consultez Node-pressure Eviction.

• Si vous avez configuré des alertes pour les exceptions de nœud dans votre cluster, vous recevez une alerte lorsqu'un nœud manque de PIDs. Pour savoir comment configurer ces alertes, consultez la rubrique ACK alert management.

Solution

1. Exécutez les commandes suivantes pour vérifier le nombre maximal de PIDs sur le nœud et le PID le plus élevé actuellement utilisé.

   sysctl kernel.pid_max  # Check the maximum number of PIDs.
   ps -eLf|awk '{print $2}' | sort -rn| head -n 1   # Check the current highest PID in use.

2. Exécutez la commande suivante pour identifier les cinq processus consommant le plus de PIDs.

   ps -elT | awk '{print $4}' | sort | uniq -c | sort -k1 -g | tail -5

   Sortie attendue :

   # The first column shows the number of PIDs used by a process. The second column shows the process ID.
   73 9743
   75 9316
   76 2812
   77 5726
   93 5691

3. Utilisez l'ID de processus pour trouver le processus et le pod correspondants. Analysez les raisons pour lesquelles le processus consomme trop de PIDs et optimisez le code de l'application.

4. Réduisez la charge sur le nœud. Pour plus d'informations, consultez la section Ressources de nœud insuffisantes pour la planification.

5. Si nécessaire, redémarrez le nœud concerné. Pour plus d'informations, consultez la rubrique Redémarrage d'une instance.

   Avertissement

   Le redémarrage du nœud peut interrompre vos services. Procédez avec prudence.

Cause

En général, un nœud manque d'espace disque parce que les conteneurs consomment trop d'espace ou que les images de conteneur sont trop volumineuses.

Symptômes

• Lorsque l'espace disque disponible pour les images de conteneur sur un nœud descend en dessous du seuil imagefs.available, la condition DiskPressure du nœud devient True.

• Lorsque l'espace disque disponible sur le système de fichiers racine du nœud descend en dessous du seuil nodefs.available, tous les pods de ce nœud sont expulsés. Pour plus d'informations sur l'expulsion due à la pression du nœud, consultez node-pressure eviction.

• Lorsqu'un nœud manque d'espace disque, vous observez généralement les messages d'erreur suivants :

  • La condition DiskPressure du nœud est définie sur True.

  • Après l'exécution du garbage collection des images, si l'espace disque reste inférieur au seuil de santé (par défaut : 80 %), vous pouvez trouver le mot-clé failed to garbage collect required amount of images dans les événements du nœud.

  • Lors de l'expulsion des pods du nœud :

    • Dans les événements des pods expulsés, vous pouvez trouver le mot-clé The node was low on resource: [DiskPressure].

    • Dans les événements du nœud, vous pouvez trouver des mots-clés tels que attempting to reclaim ephemeral-storage ou attempting to reclaim nodefs.

• Si vous avez configuré des alertes pour les exceptions de nœud, vous recevez une alerte si l'utilisation du disque d'un nœud atteint 85 % ou plus. Pour savoir comment configurer ces alertes, consultez la rubrique ACK alert management.

Solution

• Consultez les données de surveillance du nœud pour afficher la courbe d'utilisation du disque. Cela vous aide à identifier le moment où l'utilisation a augmenté brusquement et à déterminer si des processus consomment un espace disque excessif. Pour plus d'informations, consultez la section Vérification des données de surveillance des nœuds.

• Supprimez les fichiers inutiles du disque pour libérer de l'espace. Pour obtenir des instructions, consultez la rubrique Résolution des problèmes « no space left » sous Linux.

• Selon les exigences de votre charge de travail, définissez les demandes et les limites de ressources pour ephemeral-storage dans les spécifications de vos pods. Pour plus d'informations, consultez la rubrique Définition des limites de ressources CPU et mémoire pour un conteneur.

• Utilisez les services de stockage Alibaba Cloud au lieu des volumes hostPath. Pour plus d'informations, consultez la rubrique Stockage.

• Augmentez la taille du disque du nœud.

• Réduisez la charge du nœud. Pour plus d'informations, consultez la section Ressources de nœud insuffisantes pour la planification.

Cause

Ce problème se produit lorsqu'un nombre excessif de conteneurs sur un nœud épuise les adresses IP disponibles.

Symptômes

• Les pods ne parviennent pas à démarrer et restent bloqués dans l'état ContainerCreating. Les journaux du pod affichent un message d'erreur contenant le mot-clé InvalidVSwitchId.IpNotEnough. Pour savoir comment afficher les journaux des pods, consultez la rubrique Dépannage des exceptions de pod.

  time="2020-03-17T07:03:40Z" level=warning msg="Assign private ip address failed: Aliyun API Error: RequestId: 2095E971-E473-4BA0-853F-0C41CF52651D Status Code: 403 Code: InvalidVSwitchId.IpNotEnough Message: The specified VSwitch \"vsw-AAA\" has not enough IpAddress., retrying"

• Si vous avez configuré des alertes pour votre cluster, vous recevez une alerte lorsqu'un nœud manque d'adresses IP. Pour savoir comment configurer ces alertes, consultez la rubrique ACK alert management.

Solution

Réduisez le nombre de conteneurs sur le nœud. Pour plus d'informations, consultez la section Ressources de nœud insuffisantes pour la planification. Pour d'autres solutions connexes, consultez Adresses IP de vSwitch insuffisantes dans un environnement réseau TerwayQue faire si un vSwitch fournit des adresses IP insuffisantes dans un cluster Terway et la rubrique J'ai étendu les plages CIDR des vSwitch en mode Terway mais je ne peux toujours pas allouer d'adresses IP aux pods. Que faire ?.

Cause

Ce problème résulte généralement d'un état anormal du nœud, d'une mauvaise configuration des groupes de sécurité ou d'une charge réseau élevée.

Symptômes

• Vous ne pouvez pas vous connecter au nœud.

• L'état du nœud est Unknown.

• Si vous avez configuré des alertes pour les exceptions de nœud du cluster, vous recevez une alerte lorsque l'utilisation de la bande passante Internet sortante du nœud atteint 85 % ou plus. Pour plus d'informations, consultez la rubrique ACK alert management.

Solution

• Si vous ne pouvez pas vous connecter au nœud, procédez comme suit :

  • Vérifiez si l'instance de nœud est dans l'état Running.

  • Vérifiez la configuration du groupe de sécurité du nœud. Pour plus d'informations, consultez la section Vérification des groupes de sécurité des nœuds.

• Si la charge réseau du nœud est élevée, procédez comme suit :

  • Examinez la courbe d'utilisation du réseau du nœud dans les données de surveillance pour identifier les pods consommant une bande passante réseau excessive. Pour plus d'informations, consultez la section Vérification des données de surveillance des nœuds.

  • Utilisez des politiques réseau pour contrôler le trafic des pods. Pour plus d'informations, consultez la rubrique Politiques réseau dans les clusters ACK.

Cause

Ce problème est généralement causé par une charge anormale du nœud.

Symptômes

• Pendant le redémarrage du nœud, son état est NotReady.

• Si vous avez configuré des alertes pour les exceptions de nœud du cluster, vous recevez une alerte lorsqu'un nœud redémarre de manière inattendue. Pour plus d'informations, consultez la rubrique ACK alert management.

Solution

1. Exécutez la commande suivante pour vérifier l'heure de redémarrage du nœud.

   last reboot

   Sortie attendue :

   [root@iZoj203tgmxxx /root]
   #last reboot
   reboot   system boot  xxx  Tue Mar 22 06:26 - 11:49 (1+05:22)
   reboot   system boot  xxx  Fri Oct 15 05:27 - 11:49 (159+06:22)
   wtmp begins Fri Oct 15 05:27:03 2021

2. Examinez les données de surveillance du nœud et investigatez toute anomalie de ressource en fonction de l'heure de redémarrage. Pour plus d'informations, consultez la section Vérification des données de surveillance des nœuds.

3. Vérifiez les journaux du noyau du nœud et recherchez les journaux d'erreur correspondant à l'heure de redémarrage. Pour plus d'informations, consultez la section Collecte des journaux de diagnostic des nœuds.

Cause

Par défaut, certains nœuds existants d'un cluster sont configurés avec des règles auditd qui surveillent les opérations Docker. Lorsque ces nœuds utilisent le runtime de conteneur Docker, les règles déclenchent l'enregistrement par le système des journaux d'audit pour les activités liées à Docker. Dans certaines conditions, telles que des redémarrages fréquents de conteneurs, des applications écrivant un grand volume de fichiers en peu de temps ou des bugs du noyau, le système peut générer un nombre excessif de journaux d'audit. Cela peut occasionnellement provoquer des E/S disque élevées pour le processus auditd ou une erreur audit: backlog limit exceeded dans le journal système.

Symptômes

Ce problème affecte uniquement les nœuds utilisant le runtime de conteneur Docker. Un nœud concerné peut présenter les symptômes suivants :

• Lorsque vous exécutez la commande iotop -o -d 1, la sortie indique que la valeur DISK WRITE pour le processus auditd reste constamment à 1 Mo/s ou plus.

• Lorsque vous exécutez la commande dmesg -d, la sortie contient des journaux avec le mot-clé audit_printk_skb, tel que audit_printk_skb: 100 callbacks suppressed.

• Lorsque vous exécutez la commande dmesg -d, la sortie contient le mot-clé audit: backlog limit exceeded.

Solution

Suivez ces étapes pour vérifier que la configuration auditd est la cause du problème :

1. Connectez-vous à un nœud du cluster.

2. Exécutez la commande suivante pour vérifier les règles d'audit.

   sudo auditctl -l | grep -- ' -k docker'

   Si la sortie contient la ligne suivante, la configuration auditd est la cause du problème.

   -w /var/lib/docker -k docker

Si la vérification confirme que ce problème affecte les nœuds de votre cluster, choisissez l'une des solutions suivantes.

• Mettre à niveau le cluster

  Mettez à niveau votre cluster pour résoudre ce problème. Pour plus d'informations, consultez la rubrique Mise à niveau manuelle d'un cluster.

• Utiliser le runtime de conteneur containerd

  Pour les clusters que vous ne pouvez pas mettre à niveau, vous pouvez contourner ce problème en changeant le runtime de conteneur du nœud de Docker à containerd. Effectuez les étapes suivantes pour chaque pool de nœuds utilisant le runtime de conteneur Docker :

  1. Créez un nouveau pool de nœuds utilisant containerd en clonant le pool de nœuds existant. La configuration du nouveau pool de nœuds doit être identique à celle d'origine, à l'exception du runtime de conteneur.

  2. Pendant les heures creuses, videz les nœuds du pool de nœuds d'origine un par un.

• Mettre à jour la configuration auditd sur les nœuds

  Si vous ne pouvez pas mettre à niveau le cluster ou passer à containerd, contournez le problème en mettant à jour manuellement la configuration auditd sur chaque nœud concerné.

  1. Connectez-vous au nœud concerné.

  2. Exécutez les commandes suivantes pour supprimer les règles d'audit liées à Docker.

     sudo test -f /etc/audit/rules.d/audit.rules && sudo sed -i.bak '/ -k docker/d' /etc/audit/rules.d/audit.rules
     sudo test -f /etc/audit/audit.rules && sudo sed -i.bak '/ -k docker/d' /etc/audit/audit.rules

  3. Exécutez la commande suivante pour appliquer les nouvelles règles d'audit.

     if service auditd status |grep running || systemctl status auditd |grep running; then
         sudo service auditd restart || sudo systemctl restart auditd
         sudo service auditd status || sudo systemctl status auditd
     fi