Container Service for Kubernetes:Troubleshooting node exceptions

Diagnóstico de fallas en nodos

Si un nodo falla, utilice la función Diagnóstico de excepciones de ACK para diagnosticarlo.

1. Inicie sesión en la consola de ACK. En el panel de navegación izquierdo, haga clic en Clusters.

2. En la página Clusters, haga clic en el nombre de su clúster. En el panel de navegación izquierdo, haga clic en Node Pools > Nodes.

3. En la página Nodes, localice el nodo objetivo y seleccione More > Exception Diagnosis en la columna Actions.

4. En el panel que aparece, haga clic en Create Diagnosis. A continuación, consulte los resultados del diagnóstico y las sugerencias de corrección en la consola.

Consulta de detalles del nodo

1. Inicie sesión en la consola de ACK. En el panel de navegación izquierdo, haga clic en Clusters.

2. En la página Clusters, haga clic en el nombre de su clúster. En el panel de navegación izquierdo, haga clic en Node Pools > Nodes.

3. En la página Nodes, haga clic en el nombre del nodo objetivo o en Details dentro de la columna Actions para ver sus detalles.

Verificación del estado del nodo

1. Inicie sesión en la consola de ACK. En el panel de navegación izquierdo, haga clic en Clusters.

2. En la página Clusters, haga clic en el nombre de su clúster. En el panel de navegación izquierdo, haga clic en Node Pools > Nodes.

3. En la página Nodes, consulte el estado del nodo.

   • Si el estado del nodo es Ready, significa que el nodo funciona correctamente.

   • Si el estado del nodo no es Ready, haga clic en el nombre del nodo objetivo o en Details dentro de su columna Actions para ver sus detalles.

     Nota

     Para recopilar información sobre condiciones como InodesPressure, DockerOffline y RuntimeOffline, debe instalar node-problem-detector en su clúster y crear un K8s Event Center. La opción para crear un K8s Event Center está seleccionada de forma predeterminada durante la creación del clúster. Para obtener más información, consulte Create and use K8s event center.

Revisión de eventos del nodo

1. Inicie sesión en la consola de ACK. En el panel de navegación izquierdo, haga clic en Clusters.

2. En la página Clusters, haga clic en el nombre de su clúster. En el panel de navegación izquierdo, haga clic en Node Pools > Nodes.

3. En la página Nodes, haga clic en el nombre del nodo objetivo o en Details dentro de la columna Actions para ver sus detalles.

   Los eventos del nodo se muestran en la parte inferior de la página de detalles.

Recopilación de registros de diagnóstico del nodo

• Utilice Container Intelligence Service en la consola para recopilar registros de diagnóstico. Para obtener más información, consulte Node diagnostics.

• Utilice un script para recopilar registros de diagnóstico. Para obtener más información, consulte How do I collect the diagnostic information of a Kubernetes cluster?.

Verificación de componentes clave del nodo

• kubelet

  • Comprobación del estado de kubelet

    Inicie sesión en el nodo y ejecute el siguiente comando para comprobar el estado de kubelet:

    systemctl status kubelet

    Salida esperada:

    [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)

  • Revisión de los registros de kubelet

    Inicie sesión en el nodo y ejecute el siguiente comando para ver los registros de kubelet. Para obtener más información sobre cómo visualizar los registros de kubelet, consulte Collect node diagnostic logs.

    journalctl -u kubelet

  • Verificación de la configuración de kubelet

    Inicie sesión en el nodo y ejecute el siguiente comando para ver la configuración de kubelet:

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

• Runtime

  • Comprobación de dockerd

    • Verificación del estado de dockerd

      Inicie sesión en el nodo y ejecute el siguiente comando para comprobar el estado de dockerd:

      systemctl status docker

      Salida esperada:

      #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

    • Revisión de los registros de dockerd

      Inicie sesión en el nodo y ejecute el siguiente comando para ver los registros de dockerd. Para obtener más información sobre cómo visualizar los registros de dockerd, consulte Collect node diagnostic logs.

      journalctl -u docker

    • Verificación de la configuración de dockerd

      Inicie sesión en el nodo y ejecute el siguiente comando para ver la configuración de dockerd:

      cat /etc/docker/daemon.json

  • Comprobación de containerd

    • Verificación del estado de containerd

      Inicie sesión en el nodo y ejecute el siguiente comando para comprobar el estado de containerd:

      systemctl status containerd

      Salida esperada:

      [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)

    • Revisión de los registros de containerd

      Inicie sesión en el nodo y ejecute el siguiente comando para ver los registros de containerd. Para obtener más información sobre cómo visualizar los registros de containerd, consulte Collect node diagnostic logs.

      journalctl -u containerd

• Comprobación de NTP

  • Verificación del estado del servicio NTP

    Inicie sesión en el nodo y ejecute el siguiente comando para comprobar el estado del proceso chronyd:

    systemctl status chronyd

    Salida esperada:

    [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

  • Revisión de los registros del servicio NTP

    Inicie sesión en el nodo y ejecute el siguiente comando para ver los registros de NTP:

    journalctl -u chronyd

Consulta de datos de monitoreo del nodo

• Cloud Monitor

  ACK se integra con CloudMonitor. Consulte los datos básicos de monitoreo de las instancias ECS correspondientes en la consola de CloudMonitor. Para obtener más información sobre el monitoreo de nodos con CloudMonitor, consulte Monitor nodes.

• Managed Service for Prometheus

  1. Inicie sesión en la consola de ACK. En el panel de navegación izquierdo, haga clic en Clusters.

  2. En la página Clusters, haga clic en el nombre de su clúster. En el panel de navegación izquierdo, haga clic en Operations > Prometheus Monitoring.

  3. En la página Prometheus Monitoring, haga clic en la pestaña Node Monitoring y luego en la pestaña Nodes.

  4. En la página Nodes, seleccione un nodo para ver sus métricas de monitoreo, como el uso de CPU, memoria y disco.

Verificación de security groups del nodo

Para obtener más información sobre cómo verificar los security groups del nodo, consulte Security group overview y Configure cluster security groups.

Causa

Las causas típicas incluyen un proceso Kubelet anómalo, una excepción en el runtime de contenedores o una configuración incorrecta de Kubelet.

Síntomas

El estado de Kubelet es inactive.

Solución

1. Ejecute el siguiente comando para reiniciar Kubelet. Esta acción no afecta a los contenedores en ejecución.

   systemctl restart kubelet

2. Una vez que Kubelet se reinicie, inicie sesión en el nodo y ejecute el siguiente comando para comprobar su estado.

   systemctl status kubelet

3. Si el estado de Kubelet sigue siendo anómalo, inicie sesión en el nodo y ejecute el siguiente comando para ver sus registros.

   journalctl -u kubelet

   • Si los registros contienen mensajes de error específicos, utilice palabras clave de dichos mensajes para solucionar el problema.

   • Si la configuración de Kubelet es incorrecta, ejecute los siguientes comandos para corregirla.

     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.

Causa

Las causas más frecuentes incluyen una configuración de dockerd no válida, una carga alta de procesos o una carga elevada en el nodo.

Síntomas

• El estado de dockerd es inactive.

• El estado de dockerd es active (running), pero el daemon presenta un funcionamiento incorrecto que provoca una excepción en el nodo. Es posible que comandos como docker ps y docker exec fallen.

• La condición RuntimeOffline del nodo es True.

• Una excepción de dockerd activa una alerta si configuró alertas para excepciones de nodos del clúster. Para obtener más información sobre cómo configurar reglas de alerta, consulte ACK alert management.

Solución

1. Ejecute el siguiente comando para reiniciar dockerd:

   systemctl restart docker

2. Inicie sesión en el nodo y ejecute el siguiente comando para comprobar el estado de dockerd:

   systemctl status docker

3. Si el estado sigue siendo anómalo, revise los registros de dockerd:

   journalctl -u docker

Causa

Este problema suele deberse a una configuración de containerd no válida, una carga alta de procesos o una carga elevada en el nodo.

• El estado de containerd es inactive.

• La condición RuntimeOffline del nodo es True.

• Si configuró alertas para excepciones de nodos del clúster, recibirá una notificación cuando ocurra una excepción de containerd. Para obtener más información, consulte ACK alert management.

Solución

1. Ejecute el siguiente comando para reiniciar containerd:

   systemctl restart containerd

2. Después de que containerd se reinicie, inicie sesión en el nodo y ejecute el siguiente comando para comprobar su estado:

   systemctl status containerd

3. Si el estado sigue siendo anómalo después del reinicio, inicie sesión en el nodo y ejecute el siguiente comando para consultar los registros de containerd:

   journalctl -u containerd

Causa

Por lo general, este problema se debe a un proceso NTP anómalo.

Síntomas

• El estado de chronyd es inactive.

• La condición de nodo NTPProblem es True.

• Si configuró alertas para excepciones de nodos del clúster, recibirá una alerta cuando el servicio de hora de un nodo presente anomalías. Para obtener más información sobre la configuración de alertas, consulte ACK alert management.

Solución

1. Ejecute el siguiente comando para reiniciar chronyd:

   systemctl restart chronyd

2. Después de que chronyd se reinicie, inicie sesión en el nodo y ejecute el siguiente comando para comprobar que su estado sea normal:

   systemctl status chronyd

3. Si el estado sigue siendo anómalo después del reinicio, inicie sesión en el nodo y ejecute el siguiente comando para consultar los registros de chronyd:

   journalctl -u chronyd

Causa

El Generador de Eventos del Ciclo de Vida del Pod (PLEG) registra eventos durante todo el ciclo de vida del pod, como inicios y finalizaciones de contenedores. La excepción PLEG is not healthy generalmente se debe a problemas con el entorno de ejecución de contenedores en el nodo o a un defecto en la versión de systemd del nodo.

Síntomas

• El estado del nodo es NotReady.

• Los registros de kubelet contienen la siguiente entrada.

  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 configuró alertas para excepciones de nodos del clúster, recibirá una alerta cuando ocurra una excepción de PLEG. Para configurar alertas, consulte ACK alert management.

Solución

1. Reinicie secuencialmente los componentes clave del nodo (dockerd/containerd y kubelet) y compruebe si el nodo se recuperó.

2. Si reiniciar los componentes clave no resuelve el problema, reinicie el nodo. Consulte restart an instance para ver las instrucciones.

   Aviso

   Reiniciar el nodo puede interrumpir sus cargas de trabajo. Proceda con precaución.

3. Si el nodo ejecuta CentOS 7.6, consulte Error "PLEG is not healthy" en registros de kubelet en CentOS 7.6Error "Reason:KubeletNotReady Message:PLEG is not healthy:" en registros de kubelet en CentOS 7.6.

Causa

Este problema suele ocurrir cuando los nodos del clúster tienen recursos insuficientes.

Síntomas

Un pod no se programará en un nodo si sus solicitudes totales de recursos superan los recursos disponibles del nodo (asignables menos asignados).

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%)

Solución

Para resolver este problema, reduzca la carga del nodo mediante uno de los siguientes métodos:

• Elimine los pods innecesarios para reducir la carga del nodo. Para obtener más información, consulte Manage pods.

• Ajuste la configuración de recursos de sus pods según sus requisitos empresariales. Para obtener más información, consulte Set CPU and memory requests and limits for a container.

• Utilice la función de perfilado de recursos proporcionada por ACK para obtener sugerencias de configuración de recursos para contenedores basadas en datos históricos de uso de recursos. Esto simplifica la configuración de solicitudes y límites de recursos para los contenedores. Para obtener más información, consulte Resource profiling.

• Agregue nuevos nodos al clúster. Para obtener más información, consulte Create and manage node pools.

• Actualice las configuraciones del nodo. Para obtener más información, consulte Upgrade or downgrade the configurations of a worker node.

Para obtener más información, consulte Insufficient node CPU, Insufficient node memory - MemoryPressure y Insufficient node disk space - DiskPressure.

Causa

Este problema suele ser causado por contenedores que consumen recursos de CPU excesivos en un nodo.

Síntomas

• La insuficiencia de recursos de CPU puede provocar que el estado del nodo se vuelva anómalo.

• Si hay alertas configuradas para excepciones de nodos del clúster, se activará una alerta cuando la utilización de CPU del nodo alcance o supere el 85%. Para obtener más información sobre cómo configurar alertas, consulte ACK alert management.

Solución

• Revise la curva de utilización de CPU del nodo para identificar cuándo ocurrió la excepción y qué procesos en el nodo están consumiendo recursos de CPU excesivos. Para obtener más información, consulte Check the monitoring data of a node.

• Reduzca la carga en el nodo. Para obtener más información, consulte Insufficient node resources for scheduling.

• Si es necesario, reinicie el nodo afectado. Para obtener más información, consulte Restart an instance.

  Aviso

  Reiniciar el nodo puede interrumpir sus servicios. Proceda con precaución.

Causa

Este problema suele ocurrir cuando los contenedores en un nodo consumen demasiada memoria, lo que deja al nodo con memoria disponible insuficiente.

Síntomas

• Cuando la memoria disponible de un nodo cae por debajo del umbral especificado por memory.available, la condición MemoryPressure del nodo se establece en True y los contenedores del nodo se desalojan. Para obtener más información sobre el desalojo de nodos, consulte Node-pressure Eviction.

• Cuando un nodo tiene poca memoria, puede observar los siguientes síntomas comunes:

  • La condición MemoryPressure del nodo es True.

  • Cuando se desalojan contenedores en el nodo:

    • Los eventos de los contenedores desalojados incluyen el mensaje The node was low on resource: memory.

    • Los eventos del nodo incluyen el mensaje attempting to reclaim memory.

  • También puede ocurrir un OOM del sistema, indicado por el mensaje System OOM en los eventos del nodo.

• Configure alertas para recibir notificaciones cuando el uso de memoria de un nodo alcance o supere el 85%. Consulte ACK alert management para saber cómo hacerlo.

Solución

• Analice la curva de uso de memoria en los datos de monitoreo del nodo para determinar cuándo ocurrió el problema e inspeccione los procesos en ejecución en busca de fugas de memoria. Para obtener más información, consulte Check the monitoring data of a node.

• Reduzca la carga en el nodo. Para obtener más información, consulte Insufficient node resources for scheduling.

• Si es necesario, reinicie el nodo afectado. Para obtener más información, consulte Restart an instance.

  Aviso

  Precaución: Reiniciar un nodo puede interrumpir sus servicios.

Causa

Este problema suele ocurrir cuando los contenedores en un nodo consumen una cantidad excesiva de inodos.

Síntomas

• Cuando el número de inodos disponibles en un nodo cae por debajo del umbral de inodesFree, su condición InodesPressure se establece en True y los contenedores del nodo se desalojan. Para obtener más información, consulte node-pressure eviction.

• Cuando un nodo tiene pocos inodos, puede ver los siguientes mensajes de error comunes:

  • La condición del nodo InodesPressure es True.

  • Cuando se desalojan contenedores en el nodo:

    • Los eventos de los contenedores desalojados contienen el mensaje: The node was low on resource: inodes.

    • Los eventos del nodo contienen el mensaje: attempting to reclaim inodes.

• Si configuró alertas para excepciones de nodos en su clúster, recibirá una alerta cuando un nodo tenga pocos inodos. Para obtener más información sobre cómo configurar alertas, consulte ACK alert management.

Solución

• Consulte la curva de uso de inodos en los datos de monitoreo del nodo para identificar cuándo ocurrió la excepción y detectar cualquier proceso que esté consumiendo inodos en exceso. Para obtener más información, consulte Check the monitoring data of nodes.

• Para solucionar otros problemas relacionados, consulte Resolve "no space left" issues on Linux.

Causa

Este problema ocurre cuando los contenedores en un nodo consumen demasiados PIDs, agotando los PIDs disponibles del nodo.

Síntomas

• Cuando los PIDs disponibles de un nodo caen por debajo del umbral de pid.available, su condición NodePIDPressure se establece en True y los pods del nodo se desalojan. Para obtener más información sobre el desalojo de nodos, consulte Node-pressure Eviction.

• Si configuró alertas para excepciones de nodos en su clúster, recibirá una alerta cuando un nodo tenga pocos PIDs. Para obtener más información sobre cómo configurar alertas, consulte ACK alert management.

Solución

1. Ejecute los siguientes comandos para comprobar el número máximo de PIDs en el nodo y el PID más alto actualmente en uso.

   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. Ejecute el siguiente comando para identificar los cinco procesos que consumen más PIDs.

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

   Salida esperada:

   # 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. Utilice el ID del proceso para encontrar el proceso y el pod correspondientes. Analice por qué el proceso consume demasiados PIDs y optimice el código de la aplicación.

4. Reduzca la carga en el nodo. Para obtener más información, consulte Insufficient node resources for scheduling.

5. Si es necesario, reinicie el nodo afectado. Para obtener más información, consulte Restart an instance.

   Aviso

   Reiniciar el nodo puede interrumpir sus servicios. Proceda con precaución.

Causa

Por lo general, un nodo se queda sin espacio en disco porque los contenedores consumen demasiado espacio o las imágenes de contenedor son muy grandes.

Síntomas

• Cuando el espacio en disco disponible para imágenes de contenedor en un nodo cae por debajo del umbral de imagefs.available, la condición DiskPressure del nodo se vuelve True.

• Cuando el espacio en disco disponible en el sistema de archivos raíz del nodo cae por debajo del umbral de nodefs.available, todos los Pods en ese nodo se desalojan. Para obtener más información sobre el desalojo por presión del nodo, consulte node-pressure eviction.

• Cuando un nodo se queda sin espacio en disco, normalmente verá los siguientes mensajes de error:

  • La condición DiskPressure del nodo es True.

  • Después de que se ejecuta la recolección de basura de imágenes, si el espacio en disco permanece por debajo del umbral de salud (predeterminado: 80%), encontrará la palabra clave failed to garbage collect required amount of images en los eventos del nodo.

  • Cuando los Pods se desalojan del nodo:

    • En los eventos de los Pods desalojados, encontrará la palabra clave The node was low on resource: [DiskPressure].

    • En los eventos del nodo, encontrará palabras clave como attempting to reclaim ephemeral-storage o attempting to reclaim nodefs.

• Si configuró alertas para excepciones de nodos, recibirá una alerta si el uso de disco de un nodo alcanza el 85% o más. Para obtener más información sobre cómo configurar alertas, consulte ACK alert management.

Solución

• Consulte los datos de monitoreo del nodo para ver la curva de uso de disco. Esto le ayuda a identificar cuándo aumentó el uso y determinar si algún proceso está consumiendo espacio en disco excesivo. Para obtener más información, consulte Check the monitoring data of nodes.

• Elimine los archivos innecesarios del disco para liberar espacio. Para ver las instrucciones, consulte Resolve "no space left" issues on Linux.

• Según los requisitos de su carga de trabajo, establezca solicitudes y límites de recursos para ephemeral-storage en las especificaciones de sus Pods. Para obtener más información, consulte Set CPU and memory resource limits for a container.

• Utilice servicios de almacenamiento de Alibaba Cloud en lugar de volúmenes hostPath. Para obtener más información, consulte Storage.

• Aumente el tamaño del disco del nodo.

• Reduzca la carga del nodo. Para obtener más información, consulte Insufficient node resources for scheduling.

Causa

Este problema ocurre cuando un número excesivo de contenedores en un nodo agota las direcciones IP disponibles.

Síntomas

• Los pods no se inician y se quedan atascados en el estado ContainerCreating. Los registros del Pod muestran un mensaje de error que contiene la palabra clave InvalidVSwitchId.IpNotEnough. Para obtener más información sobre cómo consultar los registros de Pod, consulte Troubleshoot Pod exceptions.

  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 configuró alertas para su clúster, recibirá una alerta cuando un nodo se quede sin direcciones IP. Para obtener más información sobre cómo configurar alertas, consulte ACK alert management.

Solución

Reduzca el número de contenedores en el nodo. Para obtener más información, consulte Insufficient node resources for scheduling. Para otras soluciones relacionadas, consulte Direcciones IP de VSwitch insuficientes en un entorno de red TerwayQué hacer si un VSwitch proporciona direcciones IP insuficientes en un clúster que usa Terway y I expanded the VSwitch CIDR blocks in Terway mode but still cannot allocate Pod IPs. What do I do?.

Causa

Este problema suele ser resultado de un estado anómalo del nodo, security groups mal configurados o una carga de red alta.

Síntomas

• No puede iniciar sesión en el nodo.

• El estado del nodo es Unknown.

• Si configuró alertas para excepciones de nodos del clúster, recibirá una alerta cuando la utilización del ancho de banda de Internet de salida del nodo alcance el 85% o más. Para obtener más información, consulte ACK alert management.

Solución

• Si no puede iniciar sesión en el nodo, siga estos pasos:

  • Compruebe si la instancia del nodo está en el estado Running.

  • Verifique la configuración del security group del nodo. Para obtener más información, consulte Check the security groups of nodes.

• Si la carga de red del nodo es alta, siga estos pasos:

  • Consulte la curva de uso de red del nodo en los datos de monitoreo para identificar los pods que consumen ancho de banda de red excesivo. Para obtener más información, consulte Check the monitoring data of nodes.

  • Utilice directivas de red para controlar el tráfico de los pods. Para obtener más información, consulte Network policies in ACK clusters.

Causa

Este problema suele ser causado por una carga anómala en el nodo.

Síntomas

• Mientras el nodo se reinicia, su estado es NotReady.

• Si configuró alertas para excepciones de nodos del clúster, recibirá una alerta cuando un nodo se reinicie inesperadamente. Para obtener más información, consulte ACK alert management.

Solución

1. Ejecute el siguiente comando para comprobar la hora de reinicio del nodo.

   last reboot

   Salida esperada:

   [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. Consulte los datos de monitoreo del nodo e investigue cualquier anomalía de recursos basándose en la hora de reinicio. Para obtener más información, consulte Check the monitoring data of nodes.

3. Revise los registros del kernel del nodo y busque cualquier registro de error que corresponda a la hora de reinicio. Para obtener más información, consulte Collect the diagnostics logs of nodes.

Causa

De forma predeterminada, algunos nodos existentes en un clúster están configurados con reglas de auditd que monitorean operaciones de Docker. Cuando estos nodos utilizan el entorno de ejecución de contenedores Docker, las reglas activan el sistema para registrar registros de auditoría de actividades relacionadas con Docker. Bajo ciertas condiciones, como reinicios frecuentes de contenedores, aplicaciones que escriben un gran volumen de archivos en un corto período o errores del kernel, el sistema puede generar una cantidad excesiva de registros de auditoría. Esto ocasionalmente puede causar una E/S de disco alta por parte del proceso auditd o un error audit: backlog limit exceeded en el registro del sistema.

Síntomas

Este problema afecta solo a nodos que utilizan el entorno de ejecución de contenedores Docker. Un nodo afectado puede presentar los siguientes síntomas:

• Al ejecutar el comando iotop -o -d 1, la salida muestra que el valor DISK WRITE para el proceso auditd se mantiene consistentemente en 1 MB/s o más.

• Al ejecutar el comando dmesg -d, la salida contiene registros con la palabra clave audit_printk_skb, como audit_printk_skb: 100 callbacks suppressed.

• Al ejecutar el comando dmesg -d, la salida contiene la palabra clave audit: backlog limit exceeded.

Solución

Siga estos pasos para verificar que la configuración de auditd es la causa:

1. Inicie sesión en un nodo del clúster.

2. Ejecute el siguiente comando para comprobar las reglas de auditoría.

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

   Si la salida contiene la siguiente línea, la configuración de auditd es la causa.

   -w /var/lib/docker -k docker

Si la comprobación confirma que este problema afecta a los nodos de su clúster, elija una de las siguientes soluciones.

• Actualizar el clúster

  Actualice su clúster para corregir este problema. Para obtener más información, consulte Manually upgrade a cluster.

• Usar el entorno de ejecución de contenedores containerd

  Para clústeres que no pueda actualizar, puede solucionar este problema cambiando el entorno de ejecución de contenedores del nodo de Docker a containerd. Realice los siguientes pasos para cada node pool que utilice el entorno de ejecución de contenedores Docker:

  1. Cree un nuevo node pool que utilice containerd clonando el node pool existente. La configuración del nuevo node pool debe ser idéntica a la original, excepto por el entorno de ejecución de contenedores.

  2. Durante las horas de menor actividad, drene los nodos del node pool original uno por uno.

• Actualizar la configuración de auditd en los nodos

  Si no puede actualizar el clúster ni cambiar a containerd, resuelva el problema mediante la actualización manual de la configuración de auditd en cada nodo afectado.

  1. Inicie sesión en el nodo afectado.

  2. Ejecute los siguientes comandos para eliminar las reglas de auditoría relacionadas con 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. Ejecute el siguiente comando para aplicar las nuevas reglas de auditoría.

     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