Container Service for Kubernetes:Troubleshooting node exceptions

Diagnostiquer les défaillances de nœud

En cas de défaillance d'un nœud, utilisez la fonctionnalité de diagnostic des exceptions d'ACK pour diagnostiquer le nœud.

1. Connectez-vous à la console ACK. Dans le volet de navigation de gauche, cliquez sur Clusters.

2. Sur la page Clusters, cliquez sur le nom de votre cluster. Dans le volet de navigation de gauche, cliquez sur Node Pools > Nodes.

3. Sur la page Nodes, localisez le nœud cible, puis choisissez More > Exception Diagnosis dans la colonne Actions.

4. Dans le panneau qui s'affiche, cliquez sur Create Diagnosis. Consultez ensuite les résultats du diagnostic et les suggestions de correction dans la console.

Consulter les détails du nœud

1. Connectez-vous à la console ACK. Dans le volet de navigation de gauche, cliquez sur Clusters.

2. Sur la page Clusters, cliquez sur le nom de votre cluster. Dans le volet de navigation de gauche, cliquez sur Node Pools > Nodes.

3. Sur la page Nodes, cliquez sur le nom du nœud cible ou sur Details dans la colonne Actions pour afficher ses détails.

Vérifier l'état du nœud

1. Connectez-vous à la console ACK. Dans le volet de navigation de gauche, cliquez sur Clusters.

2. Sur la page Clusters, cliquez sur le nom de votre cluster. Dans le volet de navigation de gauche, cliquez sur Node Pools > Nodes.

3. Sur la page Nodes, consultez l'état du nœud.

   • Si l'état du nœud est Ready, le nœud fonctionne comme prévu.

   • Si l'état du nœud n'est pas Ready, cliquez sur le nom du nœud cible ou sur Details dans sa colonne Actions pour afficher ses détails.

     Remarque

     Pour collecter des informations sur les conditions telles que InodesPressure, DockerOffline et RuntimeOffline, vous devez installer node-problem-detector dans votre cluster et créer un K8s Event Center. L'option de création d'un K8s Event Center est sélectionnée par défaut lors de la création du cluster. Pour plus d'informations, consultez Créer et utiliser K8s Event Center.

Consulter les événements du nœud

1. Connectez-vous à la console ACK. Dans le volet de navigation de gauche, cliquez sur Clusters.

2. Sur la page Clusters, cliquez sur le nom de votre cluster. Dans le volet de navigation de gauche, cliquez sur Node Pools > Nodes.

3. Sur la page Nodes, cliquez sur le nom du nœud cible ou sur Details dans la colonne Actions pour afficher ses détails.

   Les événements du nœud s'affichent en bas de la page des détails.

Collecter les journaux de diagnostic du nœud

• Utilisez le Container Intelligence Service dans la console pour collecter les journaux de diagnostic. Pour plus d'informations, consultez Diagnostic de nœud.

• Utilisez un script pour collecter les journaux de diagnostic. Pour plus d'informations, consultez Comment collecter les informations de diagnostic d'un cluster Kubernetes ?.

Vérifier les composants clés du nœud

• kubelet

  • Vérifiez l'état de kubelet

    Connectez-vous au nœud et exécutez la commande suivante pour vérifier l'état de kubelet :

    systemctl status kubelet

    Sortie attendue :

    [root@iZm5eali3mx0qwqo68eobrZ ~]# systemctl status kubelet
    ● kubelet.service - kubelet: The Kubernetes Node Agent
       Loaded: loaded (/etc/systemd/system/kubelet.service; enabled; vendor preset: disabled)
      Drop-In: /etc/systemd/system/kubelet.service.d
               └─10-kubeadm.conf
       Active: active (running) since Thu 2025-06-12 13:18:45 CST; 28min ago
         Docs: http://kubernetes.io/docs/
     Main PID: 6171 (kubelet)
        Tasks: 12 (limit: 98626)
       Memory: 88.2M
       CGroup: /system.slice/kubelet.service
               └─6171 /usr/bin/kubelet --bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf --kubeconfig=/etc/kubernetes/kubelet.conf --pod-manifest-path=/etc/kubernetes/manifests --v=3 --authorization
    Jun 12 13:47:12                kubelet[6171]: I0612 13:47:12.250117    6171 prober.go:116] "Probe succeeded" probeType="Liveness" pod="kube-system/coredns-5b97654649-jkbtq" podUID="0530c82c-a012-4f
    Jun 12 13:47:12                kubelet[6171]: I0612 13:47:12.250144    6171 prober.go:116] "Probe succeeded" probeType="Readiness" pod="kube-system/coredns-5b97654649-jkbtq" podUID="0530c82c-a012-4
    Jun 12 13:47:12                kubelet[6171]: I0612 13:47:12.716032    6171 prober.go:116] "Probe succeeded" probeType="Liveness" pod="kube-system/csi-plugin-bqdjr" podUID="33fd9325-c75d-458d-adc3-
    Jun 12 13:47:13                kubelet[6171]: I0612 13:47:13.574947    6171 kubelet_pods.go:1151] "Clean up pod workers for terminated pods"
    Jun 12 13:47:13                kubelet[6171]: I0612 13:47:13.575713    6171 kubelet_pods.go:1201] "Clean up probes for terminated pods"
    Jun 12 13:47:13                kubelet[6171]: I0612 13:47:13.575724    6171 kubelet_pods.go:1205] "Clean up orphaned pod statuses"
    Jun 12 13:47:13                kubelet[6171]: I0612 13:47:13.575731    6171 kubelet_pods.go:1209] "Clean up orphaned pod user namespace allocations"
    Jun 12 13:47:13                kubelet[6171]: I0612 13:47:13.575736    6171 kubelet_pods.go:1221] "Clean up orphaned pod directories"
    Jun 12 13:47:13                kubelet[6171]: I0612 13:47:13.575775    6171 kubelet_pods.go:1232] "Clean up mirror pods"
    Jun 12 13:47:13                kubelet[6171]: I0612 13:47:13.575807    6171 kubelet_pods.go:1374] "Clean up orphaned pod cgroups"
    lines 1-22/22 (END)

  • Vérifiez les journaux de kubelet

    Connectez-vous au nœud et exécutez la commande suivante pour consulter les journaux de kubelet. Pour plus d'informations sur la consultation des journaux de kubelet, consultez Collecter les journaux de diagnostic du nœud.

    journalctl -u kubelet

  • Vérifiez la configuration de kubelet

    Connectez-vous au nœud et exécutez la commande suivante pour afficher la configuration de kubelet :

    cat /etc/systemd/system/kubelet.service.d/10-kubeadm.conf

• Runtime

  • Vérifiez dockerd

    • Vérifiez l'état de dockerd

      Connectez-vous au nœud et exécutez la commande suivante pour vérifier l'état de dockerd :

      systemctl status docker

      Sortie attendue :

      #systemctl status docker
      ● docker.service - Docker Application Container Engine
         Loaded: loaded (/etc/systemd/system/docker.service; enabled; vendor preset: disabled)
         Active: active (running) since Wed 2022-03-02 15:11:46 CST; 5 days ago
           Docs: https://docs.docker.com
       Main PID: 4330 (dockerd)
          Tasks: 75
         Memory: 8.3G
         CGroup: /system.slice/docker.service
                 └─4330 /usr/bin/dockerd -H fd:// --containerd=/run/containerd/containerd.sock
      Mar 02 15:19:29 xxx                    dockerd[4330]: time="2022-03-02T15:19:29.418689546+08:00" level=info msg="Attempting next endpoint for pull a...eaders
      Mar 02 15:22:20 xxx                    dockerd[4330]: time="2022-03-02T15:22:20.888769038+08:00" level=warning msg="Error getting v2 registry: Get h...eaders
      Mar 02 15:22:20 xxx                    dockerd[4330]: time="2022-03-02T15:22:20.888912991+08:00" level=info msg="Attempting next endpoint for pull a...eaders
      Mar 02 15:23:25 xxx                    dockerd[4330]: time="2022-03-02T15:23:25.487947465+08:00" level=warning msg="Seccomp is not enabled in your k...rofile

    • Vérifiez les journaux de dockerd

      Connectez-vous au nœud et exécutez la commande suivante pour consulter les journaux de dockerd. Pour plus d'informations sur la consultation des journaux de dockerd, consultez Collecter les journaux de diagnostic du nœud.

      journalctl -u docker

    • Vérifiez la configuration de dockerd

      Connectez-vous au nœud et exécutez la commande suivante pour afficher la configuration de dockerd :

      cat /etc/docker/daemon.json

  • Vérifiez containerd

    • Vérifiez l'état de containerd

      Connectez-vous au nœud et exécutez la commande suivante pour vérifier l'état de containerd :

      systemctl status containerd

      Sortie attendue :

      [root@iZm5eali3mx0qwqo68eobrZ ~]# systemctl status containerd
      ● containerd.service - containerd container runtime
         Loaded: loaded (/etc/systemd/system/containerd.service; enabled; vendor preset: disabled)
         Active: active (running) since Thu 2025-06-12 13:18:44 CST; 29min ago
           Docs: https://containerd.io
       Main PID: 5994 (containerd)
          Tasks: 153
         Memory: 3.5G
         CGroup: /system.slice/containerd.service
                 ├─ 5994 /usr/bin/containerd
                 ├─ 6589 /usr/bin/containerd-shim-runc-v2 -namespace k8s.io -id b4ad8b28c61fa573e04bc641901bd64b15adb1d4a... xxx -address /run/containerd/containerd.sock
                 ├─ 6592 /usr/bin/containerd-shim-runc-v2 -namespace k8s.io -id eb828cfb114bd404d7781f72b55ed4ee1e9743b7d... xxx -address /run/containerd/containerd.sock
                 ├─ 6666 /usr/bin/containerd-shim-runc-v2 -namespace k8s.io -id 92bf24db851fcaf65ed9c3ddc9210b61169623158... xxx -address /run/containerd/containerd.sock
                 ├─ 6726 /usr/bin/containerd-shim-runc-v2 -namespace k8s.io -id 96d44ff7503b876227e7d287a730cac5b50b5183f1... xxx -address /run/containerd/containerd.sock
                 ├─ 6727 /usr/bin/containerd-shim-runc-v2 -namespace k8s.io -id 3707c088fec2d14f9ec2c78beccf5f3e1f0a18a6b... xxx -address /run/containerd/containerd.sock
                 ├─ 6766 /usr/bin/containerd-shim-runc-v2 -namespace k8s.io -id b390b71290b772958626a0cc943fb678c7fec4ef5... xxx -address /run/containerd/containerd.sock
                 ├─ 9501 /usr/bin/containerd-shim-runc-v2 -namespace k8s.io -id 40c0f850c4c003144bbc5a17bcb5b7f15ad121862... xxx -address /run/containerd/containerd.sock
                 ├─ 9567 /usr/bin/containerd-shim-runc-v2 -namespace k8s.io -id 3b07c32bf4fe84fde20177efdcffabd2cd93ac02a... xxx -address /run/containerd/containerd.sock
                 ├─ 9633 /usr/bin/containerd-shim-runc-v2 -namespace k8s.io -id d181fcabeebca990b1298072f91da4fbb251b666c... xxx -address /run/containerd/containerd.sock
                 └─11643 /usr/bin/containerd-shim-runc-v2 -namespace k8s.io -id f3744bcb95b522bc64a5a88dd4c49a231c082f5d79... xxx -address /run/containerd/containerd.sock
      Jun 12 13:19:53  containerd[5994]: time="2025-06-12T13:19:53.013508035+08:00" level=error msg="ContainerStatus for \"f3744bcb95b522bc64a5a88dd4c49a231c082f5d790e64e6f835760b83e7b280\""
      Jun 12 13:19:54  containerd[5994]: time="2025-06-12T13:19:54.708151565+08:00" level=info msg="ImageCreate event &ImageCreate{Name:registry-cn-qingdao-vpc.ack.aliyuncs.com/acs/loongcol..."
      Jun 12 13:19:54  containerd[5994]: time="2025-06-12T13:19:54.710172874+08:00" level=info msg="ImageCreate event &ImageCreate{Name:sha256:e705a85d376f9fdecd0f1b2ebce63d85f8392de70a9636..."
      Jun 12 13:19:54  containerd[5994]: time="2025-06-12T13:19:54.713591809+08:00" level=info msg="PullImage \"registry-cn-qingdao-vpc.ack.aliyuncs.com/acs/loongcollector:v3.0.11.0-915c655..."
      Jun 12 13:19:54  containerd[5994]: time="2025-06-12T13:19:54.713969883+08:00" level=info msg="ImageCreate event &ImageCreate{Name:registry-cn-qingdao-vpc.ack.aliyuncs.com/acs/loongcol..."
      Jun 12 13:19:54  containerd[5994]: time="2025-06-12T13:19:54.717628440+08:00" level=info msg="CreateContainer within sandbox \"f3744bcb95b522bc64a5a88dd4c49a231c082f5d790e64e6f835760b..."
      Jun 12 13:19:54  containerd[5994]: time="2025-06-12T13:19:54.732237135+08:00" level=info msg="CreateContainer within sandbox \"f3744bcb95b522bc64a5a88dd4c49a231c082f5d790e64e6f835760b..."
      Jun 12 13:19:54  containerd[5994]: time="2025-06-12T13:19:54.735512597+08:00" level=info msg="StartContainer for \"e7c6a20368f9c20900848fbcec81d5145d73caa8c4decaae660e0ea89dd64c28\""
      Jun 12 13:19:54  containerd[5994]: time="2025-06-12T13:19:54.771464238+08:00" level=info msg="StartContainer for \"e7c6a20368f9c20900848fbcec81d5145d73caa8c4decaae660e0ea89dd64c28\"..."
      Jun 12 13:20:47  containerd[5994]: time="2025-06-12T13:20:47.246563467+08:00" level=error msg="ContainerStatus for \"f3744bcb95b522bc64a5a88dd4c49a231c082f5d790e64e6f835760b83e7b280\""
      lines 1-30/30 (END)

    • Vérifiez les journaux de containerd

      Connectez-vous au nœud et exécutez la commande suivante pour consulter les journaux de containerd. Pour plus d'informations sur la consultation des journaux de containerd, consultez Collecter les journaux de diagnostic du nœud.

      journalctl -u containerd

• Vérifier NTP

  • Vérifiez l'état du service NTP

    Connectez-vous au nœud et exécutez la commande suivante pour vérifier l'état du processus chronyd :

    systemctl status chronyd

    Sortie attendue :

    [root@iZm5eali3mx0qwqo68eobrZ ~]# systemctl status chronyd
    ● chronyd.service - NTP client/server
       Loaded: loaded (/usr/lib/systemd/system/chronyd.service; enabled; vendor preset: enabled)
       Active: active (running) since Thu 2025-06-12 13:18:22 CST; 20min ago
         Docs: man:chronyd(8)
               man:chrony.conf(5)
     Main PID: 1603 (chronyd)
        Tasks: 1 (limit: 98626)
       Memory: 732.0K
       CGroup: /system.slice/chronyd.service
               └─1603 /usr/sbin/chronyd
    Jun 12 13:18:22 iZm5eali3mx0qwqo68eobrZ systemd[1]: chronyd.service: Succeeded.
    Jun 12 13:18:22 iZm5eali3mx0qwqo68eobrZ systemd[1]: Stopped NTP client/server.
    Jun 12 13:18:22 iZm5eali3mx0qwqo68eobrZ systemd[1]: Starting NTP client/server...
    Jun 12 13:18:22 iZm5eali3mx0qwqo68eobrZ chronyd[1603]: chronyd version 4.5 starting (+CMDMON +NTP +REFCLOCK +RTC +PRIVDROP +SCFILTER +SIGND +ASYNCDNS +NTS +SECHASH +IPV6 +DEBUG)
    Jun 12 13:18:22 iZm5eali3mx0qwqo68eobrZ chronyd[1603]: Frequency -35.639 +/- 2.058 ppm read from /var/lib/chrony/drift
    Jun 12 13:18:22 iZm5eali3mx0qwqo68eobrZ systemd[1]: Started NTP client/server.
    Jun 12 13:18:23 iZm5eali3mx0qwqo68eobrZ chronyd[1603]: System clock was stepped by 0.000000 seconds
    Jun 12 13:18:27 iZm5eali3mx0qwqo68eobrZ chronyd[1603]: Selected source 100.100.61.88 (ntp.cloud.aliyuncs.com)
    Jun 12 13:18:27 iZm5eali3mx0qwqo68eobrZ chronyd[1603]: System clock wrong by 1.476188 seconds
    xxx

  • Vérifiez les journaux du service NTP

    Connectez-vous au nœud et exécutez la commande suivante pour consulter les journaux NTP :

    journalctl -u chronyd

Consulter les données de surveillance du nœud

• Cloud Monitor

  ACK s'intègre à CloudMonitor. Consultez les données de surveillance de base des instances ECS correspondantes dans la console CloudMonitor. Pour plus d'informations sur la surveillance des nœuds avec CloudMonitor, consultez Surveiller les nœuds.

• Managed Service for Prometheus

  1. Connectez-vous à la console ACK. Dans le volet de navigation de gauche, cliquez sur Clusters.

  2. Sur la page Clusters, cliquez sur le nom de votre cluster. Dans le volet de navigation de gauche, cliquez sur Operations > Prometheus Monitoring.

  3. Sur la page Prometheus Monitoring, cliquez sur l'onglet Node Monitoring, puis sur l'onglet Nodes.

  4. Sur la page Nodes, sélectionnez un nœud pour afficher ses métriques de surveillance, telles que l'utilisation du CPU, de la mémoire et du disque.

Vérifier les groupes de sécurité du nœud

Pour plus d'informations sur la vérification des groupes de sécurité des nœuds, consultez Présentation des groupes de sécurité et Configurer les groupes de sécurité du cluster.

Cause

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

Symptômes

L'état 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 état.

   systemctl status kubelet

3. Si l'état de Kubelet reste anormal, connectez-vous au nœud et exécutez la commande suivante pour consulter 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 élevée du processus ou une charge élevée du nœud.

Symptômes

• L'état de dockerd est inactive.

• L'état de dockerd est active (running), mais le daemon fonctionne mal, ce qui provoque une anomalie du nœud. Les 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é des alertes pour les anomalies de nœud du 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 l'état de dockerd :

   systemctl status docker

3. Si l'état 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 élevée du processus ou une charge élevée du nœud.

• L'état de containerd est inactive.

• La condition RuntimeOffline du nœud est True.

• Si des alertes sont configurées pour les anomalies de nœud du 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 état :

   systemctl status containerd

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

   journalctl -u containerd

Cause

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

Symptômes

• L'état de chronyd est inactive.

• La condition de nœud NTPProblem est True.

• Si vous avez configuré des alertes pour les anomalies de nœud du cluster, vous recevrez une alerte lorsque le service de temps d'un nœud sera 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 état est normal :

   systemctl status chronyd

3. Si l'état reste anormal après le redémarrage, connectez-vous au nœud et exécutez la commande suivante pour consulter 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 des pods, 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 liés au runtime de conteneur sur le nœud ou par un défaut dans la version systemd du nœud.

Symptômes

• L'état 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 anomalies de nœud du 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 la section 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 la section Erreur « PLEG is not healthy » dans les journaux kubelet sur CentOS 7.6Erreur « 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 de vos pods en fonction de vos besoins métier. Pour plus d'informations, consultez Définir les requêtes 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 requêtes 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 worker.

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

Cause

Des conteneurs consommant excessivement les ressources CPU sur un nœud causent généralement ce problème.

Symptômes

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

• Si des alertes sont configurées pour les anomalies de nœud du 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'anomalie s'est produite et quels processus sur le nœud consomment excessivement les ressources CPU. Pour plus d'informations, consultez Consulter les données de surveillance d'un nœud.

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

• Si nécessaire, redémarrez le nœud concerné. 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 excessivement la mémoire, laissant au nœud 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 Node-pressure Eviction.

• 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 des 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, 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 procéder.

Solution

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

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

• Si nécessaire, redémarrez le nœud concerné. 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 sur un nœud consomment excessivement les inodes.

Symptômes

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

• Lorsqu'un nœud manque d'inodes, vous pouvez voir les messages d'erreur courants suivants :

  • La condition du nœud InodesPressure est True.

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

    • Les événements des 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 anomalies de nœud dans votre cluster, vous êtes alerté lorsqu'un nœud manque d'inodes. Pour plus d'informations sur la configuration des alertes, consultez Gestion des alertes ACK.

Solution

• Vérifiez la courbe d'utilisation des inodes dans les données de surveillance du nœud pour identifier quand l'anomalie s'est produite et repérer tous les processus consommant excessivement les inodes. Pour plus d'informations, consultez Consulter les données de surveillance des nœuds.

• Pour résoudre d'autres problèmes connexes, consultez Résoudre les problèmes « no space left » sur Linux.

Cause

Ce problème survient lorsque les conteneurs sur un nœud consomment trop de PIDs, épuisant les PIDs disponibles du nœud.

Symptômes

• Lorsque les PIDs disponibles d'un nœud tombent en dessous du seuil pid.available, sa condition NodePIDPressure est définie sur True et les pods sur le 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 anomalies de nœud dans votre cluster, vous recevez une alerte lorsqu'un nœud manque de PIDs. Pour plus d'informations sur la configuration des alertes, consultez Gestion des alertes ACK.

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 du processus pour trouver le processus et le pod correspondants. Analysez pourquoi 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 Ressources insuffisantes sur le nœud pour la planification.

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

   Avertissement

   Le redémarrage du nœud peut interrompre vos services. Faites preuve de prudence.

Cause

Généralement, un nœud manque d'espace disque parce que les conteneurs consomment excessivement l'espace disque 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 tombe 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 tombe en dessous du seuil nodefs.available, tous les Pods sur 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 voyez généralement les messages d'erreur suivants :

  • La condition DiskPressure du nœud est True.

  • Après l'exécution de la collecte des ordures d'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.

  • Lorsque les Pods sont expulsés 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 anomalies de nœud, vous recevrez une alerte si l'utilisation du disque d'un nœud atteint 85 % ou plus. Pour plus d'informations sur la configuration des alertes, consultez Gestion des alertes ACK.

Solution

• Vérifiez les données de surveillance du nœud pour afficher la courbe d'utilisation du disque. Cela vous aide à identifier quand l'utilisation a augmenté et à déterminer si des processus consomment excessivement l'espace disque. Pour plus d'informations, consultez Consulter les données de surveillance des nœuds.

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

• Selon les exigences de votre charge de travail, définissez les requêtes et les limites de ressources pour ephemeral-storage dans les spécifications de votre Pod. Pour plus d'informations, consultez Définir les 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 Stockage.

• Augmentez la taille du disque du nœud.

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

Cause

Ce problème survient 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 plus d'informations sur la consultation des journaux des Pods, consultez Dépanner les anomalies 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 recevrez une alerte lorsqu'un nœud manquera d'adresses IP. Pour plus d'informations sur la configuration des alertes, consultez Gestion des alertes ACK.

Solution

Réduisez le nombre de conteneurs sur le nœud. Pour plus d'informations, consultez Ressources insuffisantes sur le nœud 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 utilisant Terway et J'ai étendu les blocs CIDR de VSwitch en mode Terway mais je ne peux toujours pas allouer d'adresses IP de Pod. Que faire ?.

Cause

Ce problème résulte généralement d'un état de nœud anormal, d'une configuration incorrecte 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 anomalies de nœud du cluster, vous recevrez une alerte lorsque l'utilisation de la bande passante Internet sortante du nœud atteindra 85 % ou plus. Pour plus d'informations, consultez Gestion des alertes ACK.

Solution

• Si vous ne pouvez pas vous connecter au nœud, suivez ces étapes :

  • Vérifiez si l'instance du nœud se trouve dans l'état Running.

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

• Si la charge réseau du nœud est élevée, suivez ces étapes :

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

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

Cause

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

Symptômes

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

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

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. Vérifiez les données de surveillance du nœud et enquêtez sur toute anomalie de ressource en fonction de l'heure de redémarrage. Pour plus d'informations, consultez Consulter les 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 Collecter les journaux de diagnostic des nœuds.

Cause

Par défaut, certains nœuds existants dans 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 bogues 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 du 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 montre 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 :

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.

   -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 Mettre à niveau manuellement 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 de l'original, à l'exception du runtime de conteneur.

  2. Pendant les heures creuses, videz les nœuds du pool de nœuds original 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