Container Service for Kubernetes:Troubleshoot pod issues

Mensaje de error

Descripción

Solución

no nodes available to schedule pods.

El clúster no tiene nodos disponibles para programar el pod.

1. Compruebe si algún nodo del clúster está en estado NotReady. Si un nodo está en NotReady, inspecciónelo y repárelo.

2. Compruebe si el pod define un nodeSelector, nodeAffinity o tolerancias a taints. Si no se definieron estas restricciones de programación, considere agregar más nodos al node pool.

• 0/x nodes are available: x Insufficient cpu.

• 0/x nodes are available: x Insufficient memory.

Ningún nodo disponible en el clúster satisface las solicitudes de CPU o memoria del pod.

Un nodo no permite programación cuando el total de requests asignados alcanza su capacidad, incluso si la utilización real es baja.

En la página de detalles del clúster correspondiente, vaya a Nodes > Nodes y compruebe la tasa de asignación de requests de CPU o memoria del nodo correspondiente. Pase el cursor sobre la tasa de asignación para ver los valores específicos de asignación de recursos.

Para ver el uso detallado de recursos del nodo, consulte Use kubectl to view node resource usage.

• Optimice la configuración de recursos:

  • Si el uso de recursos de un nodo es siempre inferior a sus requests, se están desperdiciando recursos. Reduzca la configuración de requests de la carga de trabajo. Consulte Set CPU and memory resource limits for a container.

    Habilite resource profiling para obtener la configuración recomendada de requests.

  • Habilite Horizontal Pod Autoscaler (HPA) para reducir las réplicas durante las horas de menor demanda.

• Elimine las cargas de trabajo innecesarias: dé de baja o reduzca los pods que no sean esenciales.

• Escale horizontalmente el node pool: si el uso de recursos en los nodos correspondientes es constantemente alto, los nodos están saturados. Puede scale out the node pool.

x node(s) didn't match pod's node affinity/selector.

Los nodos existentes no coinciden con la política de afinidad de nodo del pod (nodeAffinity/nodeSelector). Consulte Assigning Pods to Nodes.

1. Consulte todas las etiquetas de un nodo.

   Console

   1. En la página de detalles del clúster correspondiente, vaya a Nodes > Nodes.

   2. En la página Nodes, busque el nodo correspondiente y, en la columna Actions, haga clic en More > Manage Labels and Taints para ver sus etiquetas.

   Kubectl

   Reemplace <YOUR_NODE_NAME> con el nombre real de su nodo.

   kubectl get node <YOUR_NODE_NAME> --show-labels

2. Compruebe y ajuste la regla de afinidad de nodo de la carga de trabajo (deployment).

   Console

   Al crear una nueva carga de trabajo:

   1. En la página Advanced para crear un Deployment (Create), busque Node Affinity en la sección Scheduling y haga clic en Add.

   2. Configure Required (afinidad estricta) u Optional (afinidad flexible) según sus necesidades de negocio. Varios elementos Selector tienen una relación lógica AND, mientras que varios elementos Rule tienen una relación lógica OR.

   Para cargas de trabajo existentes:

   1. En la página Nodes > Nodes, haga clic en > Node Affinity en la columna Actions del Deployment correspondiente.

   2. El método de configuración es el mismo que se describió anteriormente.

   Ejemplo de YAML

   NodeAffinity

   Las políticas de afinidad incluyen la afinidad estricta (requiredDuringSchedulingIgnoredDuringExecution), que debe cumplirse, y la afinidad flexible (preferredDuringSchedulingIgnoredDuringExecution), que expresa una preferencia. A continuación se muestra un ejemplo con afinidad estricta.

   apiVersion: apps/v1
       kind: Deployment
       metadata:
         name: app-demo-node-affinity-deploy
         labels:
           app: demo-node-affinity
       spec:
         replicas: 2
         selector:
           matchLabels:
             app: demo-node-affinity
         template:
           metadata:
             labels:
               app: demo-node-affinity
           spec:
             containers:
             - name: nginx
               image: anolis-registry.cn-zhangjiakou.cr.aliyuncs.com/openanolis/nginx:1.14.1-8.6
             affinity:
               nodeAffinity:
                 # Hard affinity: The rule must be met.
                 requiredDuringSchedulingIgnoredDuringExecution:
                   nodeSelectorTerms:
                   - matchExpressions:
                     - key: disktype
                       operator: In
                       values:
                       - ssd
                       - nvme  # Logic: The node's 'disktype' label must be either 'ssd' or 'nvme'.

   NodeSelector

   Proporciona una coincidencia exacta simple. El pod se programa únicamente si las etiquetas del nodo cumplen las condiciones.

   apiVersion: apps/v1
       kind: Deployment
       metadata:
         name: app-demo-node-selector-deploy
         labels:
           app: demo-node-selector
       spec:
         replicas: 2  
         selector:
           matchLabels:
             app: demo-node-selector  
         template:
           metadata:
             labels:
               app: demo-node-selector
           spec:
             containers:
             - name: nginx
               image: anolis-registry.cn-zhangjiakou.cr.aliyuncs.com/openanolis/nginx:1.14.1-8.6
             # The pod is scheduled only if the node has the label disktype=ssd.
             nodeSelector:
               disktype: ssd

• x node(s) didn't match pod affinity rules.

• x node(s) didn't match pod anti-affinity rules.

• Desajuste en la regla de afinidad. El pod tiene una regla de pod affinity (por ejemplo, requiere una etiqueta específica), pero ningún nodo aloja un pod con esa etiqueta, lo que impide la programación.

• Conflicto de antiafinidad. El pod tiene una regla de pod anti-affinity (por ejemplo, no puede coexistir con otra aplicación), pero todos los nodos disponibles ya alojan un pod en conflicto, lo que impide la programación.

1. Consulte las etiquetas de los pods en un nodo.

   Console

   1. En la página de detalles del clúster correspondiente, vaya a Nodes > Nodes.

   2. En la página Nodes, haga clic en el nombre del nodo correspondiente para ver su página de detalles. Desplácese hasta la sección Pods para ver los valores de etiqueta de distintos pods en la columna Label.

   Kubectl

   • Consulte los pods y sus etiquetas en un nodo específico: reemplace <YOUR_NAMESPACE> con el nombre de su namespace y <YOUR_NODE_NAME> con el nombre real de su nodo.

     kubectl get pods -n <YOUR_NAMESPACE> --field-selector spec.nodeName=<YOUR_NODE_NAME> -o custom-columns=NAME:.metadata.name,LABELS:.metadata.labels

   • Consulte pods por etiqueta: reemplace <LABEL> con el par clave-valor real de la etiqueta, como app=nginx.

     kubectl get pods -A -l <LABEL> -o wide

2. Compruebe y ajuste la regla de afinidad de pod de la carga de trabajo (deployment).

   Console

   1. Cuando cree una nueva carga de trabajo, en la página Advanced de creación de un Deployment (Create), busque Pod Affinity/Pod Anti-affinity en la sección Scheduling y haga clic en Add.

   2. Configure Required (afinidad estricta) u Optional (afinidad flexible) según sus necesidades de negocio. Varios elementos Selector tienen una relación lógica AND, mientras que varios elementos Add Rule tienen una relación lógica OR.

   Ejemplo de YAML

   Las políticas de afinidad se clasifican en afinidad estricta (requiredDuringSchedulingIgnoredDuringExecution) y afinidad flexible (preferredDuringSchedulingIgnoredDuringExecution). Las reglas de afinidad estricta deben cumplirse, mientras que las de afinidad flexible son preferentes. A continuación se muestra un ejemplo de configuración para una pod affinity obligatoria.

   Para configurar una antiafinidad de pod, simplemente reemplace podAffinity por podAntiAffinity.

   apiVersion: apps/v1
       kind: Deployment
       metadata:
         name: app-demo-podaffinity-deploy
       spec:
         replicas: 2
         selector:
           matchLabels:
             app: demo-podaffinity
         template:
           metadata:
             labels:
               app: demo-podaffinity
           spec:
             containers:
             - name: nginx
               image: anolis-registry.cn-zhangjiakou.cr.aliyuncs.com/openanolis/nginx:1.14.1-8.6
             affinity:
               podAffinity:
                 # Hard affinity: Pod must be co-located with a pod that has the 'app: nginx' label.
                 requiredDuringSchedulingIgnoredDuringExecution:
                 - labelSelector:
                     matchExpressions:
                     - key: app
                       operator: In
                       values:
                       - nginx
                   # Topology domain scope: host-level isolation.
                   topologyKey: kubernetes.io/hostname

0/x nodes are available: x node(s) had volume node affinity conflict.

La programación falla debido a un conflicto de afinidad de nodo del volumen. Esto suele ocurrir porque un disco en la nube no se puede montar en zonas distintas.

• Para un PV aprovisionado de forma estática, configure la afinidad de nodo del pod para asegurar que se programe en un nodo de la misma zona que el PV.

• Para un PV aprovisionado de forma dinámica, establezca el volumeBindingMode de StorageClass en WaitForFirstConsumer. Así se garantiza que el PV se cree únicamente después de programar el pod en un nodo, lo que asegura que el disco en la nube se cree en la misma zona que el nodo del pod.

InvalidInstanceType.NotSupportDiskCategory

La instancia ECS no es compatible con el tipo de disco en la nube especificado.

Consulte Instance families para confirmar los tipos de disco en la nube compatibles con su instancia ECS. Al montar, actualice el tipo de disco en la nube a uno que admita la instancia ECS.

0/x nodes are available: x node(s) had taints that the pod didn't tolerate.

El pod no se puede programar en un nodo porque le falta una tolerancia para uno de los taints del nodo.

• Si el taint se agregó manualmente, elimínelo o configure una tolerancia para el pod. Consulte Taints and Tolerations y Manage node labels and taints.

• Si el sistema agregó el taint, resuelva el problema subyacente que se indica a continuación y espere a que se reprograme.

  Ver los taints agregados por el sistema

  • node.kubernetes.io/not-ready: el nodo está en estado NotReady.

  • node.kubernetes.io/unreachable: el controlador de nodos no puede alcanzar el nodo. Equivale a que el estado Ready del nodo sea Unknown.

  • node.kubernetes.io/memory-pressure: el nodo tiene presión de memoria.

  • node.kubernetes.io/disk-pressure: el nodo tiene presión de disco.

  • node.kubernetes.io/pid-pressure: el nodo tiene presión de PID.

  • node.kubernetes.io/network-unavailable: la red del nodo no está disponible.

  • node.kubernetes.io/unschedulable: el nodo está marcado como no programable.

0/x nodes are available: x Insufficient ephemeral-storage.

El nodo no tiene suficiente almacenamiento efímero.

1. Compruebe la solicitud de almacenamiento efímero del pod, que corresponde al valor de spec.containers.resources.requests.ephemeral-storage en el YAML del pod. Si el valor es demasiado alto y supera la capacidad real disponible del nodo, el pod no se programará.

2. Compruebe la capacidad total de almacenamiento efímero de cada nodo con kubectl describe node | grep -A10 Capacity. Si es insuficiente, amplíe el disco del nodo o agregue más nodos.

0/x nodes are available: pod has unbound immediate persistent volume claims.

El pod no logró vincularse a una persistent volume claim (PVC).

Compruebe si se creó la PVC o el PV que especifica el pod. Ejecute kubectl describe pvc <pvc-name> o kubectl describe pv <pv-name> para ver los eventos de la PVC y del PV, y continuar con el diagnóstico. Consulte Storage FAQ - CSI.

Mensaje de error

Descripción

Solución sugerida

Failed to pull image "xxx": rpc error: code = Unknown desc = Error response from daemon: Get xxx: denied:

Se denegó el acceso al repositorio de imágenes porque no se especificó un elemento imagePullSecret al crear el pod.

Compruebe que exista el Secret indicado en el campo spec.imagePullSecrets del archivo YAML de la carga de trabajo.

Si utiliza ACR, emplee un asistente de credenciales para descargar imágenes sin contraseña. Consulte Pull images from the same account.

Failed to pull image "xxxx:xxx": rpc error: code = Unknown desc = Error response from daemon: Get https://xxxxxx/xxxxx/: dial tcp: lookup xxxxxxx.xxxxx: no such host

No se pudo resolver la dirección del repositorio de imágenes durante una descarga por HTTPS.

1. Compruebe que la dirección del repositorio de imágenes en spec.containers.image del archivo YAML del pod sea correcta. Si no lo es, actualícela.

2. Si la dirección es correcta, compruebe la conectividad de red desde el nodo donde se ejecuta el pod hacia el repositorio de imágenes. Inicie sesión en el nodo (para más información, consulte Choose an ECS remote connection method) y ejecute el comando curl -kv https://xxxxxx/xxxxx/ para comprobar si puede acceder a la dirección. Si ocurre un error, investigue posibles problemas de red, como una configuración de red incorrecta, reglas de firewall o problemas de resolución DNS.

Failed create pod sandbox: rpc error: code = Unknown desc = failed to create a sandbox for pod "xxxxxxxxx": Error response from daemon: mkdir xxxxx: no space left on device

El nodo no tiene suficiente espacio en disco.

Inicie sesión en el nodo (consulte Choose an ECS remote connection method) y ejecute df -h para revisar el espacio en disco. Si el disco está lleno, cambie su tamaño. Consulte Step 1: Resize a cloud disk.

Failed to pull image "xxx": rpc error: code = Unknown desc = error pulling image configuration: xxx x509: certificate signed by unknown authority

El repositorio de imágenes de terceros usa un certificado firmado por una autoridad certificadora (CA) desconocida o insegura.

1. El repositorio de terceros debe usar un certificado emitido por una CA de confianza.

2. Si utiliza un repositorio de imágenes privado, consulte Create an application from a private image repository.

3. Si no puede cambiar el certificado, configure el nodo para permitir la descarga y el envío de imágenes desde un repositorio que use un certificado inseguro. Se recomienda usar este método solo en entornos de prueba, ya que podría afectar a otros pods del nodo.

Failed to pull image "XXX": rpc error: code = Unknown desc = context canceled

La operación se canceló, posiblemente porque el archivo de imagen es demasiado grande. Kubernetes tiene un tiempo de espera predeterminado para descargar imágenes. Si la descarga no avanza durante un periodo determinado, Kubernetes asume que la operación falló o no responde, y cancela la tarea.

1. Compruebe que imagePullPolicy esté establecido en IfNotPresent en el archivo YAML del pod.

2. Inicie sesión en el nodo donde se ejecuta el pod (para más información, consulte Choose an ECS remote connection method) y ejecute docker pull o crictl pull para comprobar si se puede descargar la imagen.

Failed to pull image "xxxxx": rpc error: code = Unknown desc = Error response from daemon: Get https://xxxxxxx: xxxxx/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)

No se puede conectar al repositorio de imágenes debido a problemas de red.

1. Inicie sesión en el nodo donde se ejecuta el pod (para más información, consulte Choose an ECS remote connection method) y ejecute el comando curl https://xxxxxx/xxxxx/ para comprobar si puede acceder a la dirección. Si ocurre un error, investigue posibles problemas de red, como una configuración de red incorrecta, reglas de firewall o problemas de resolución DNS.

2. Compruebe la política de red pública del nodo, incluidas las configuraciones de las entradas SNAT y las direcciones IP elásticas (EIP) vinculadas.

Failed to pull image "xxxx:xxx": failed to pull and unpack image "xxxx:xxx": failed to resolve reference "xxxx:xxx": failed to do request: Head "xxxx:xxx": dial tcp xxx.xxx.xx.x:xxx: i/o timeout

La conexión agotó el tiempo de espera por problemas de red al descargar una imagen desde un repositorio en el extranjero.

Las descargas de imágenes desde repositorios en el extranjero, como Docker Hub, pueden fallar en los clústeres ACK debido a la inestabilidad de las redes de los proveedores. Para solucionarlo, considere las siguientes opciones:

• Suscríbase a imágenes de origen en el extranjero mediante Container Registry. Para ver las instrucciones, consulte Sync images by using artifact subscription.

• Cree una instancia de Global Accelerator (GA) para descargar imágenes directamente mediante su red de aceleración global. Para obtener más detalles, consulte Accelerate cross-region ACK image pulls with GA.

Too Many Requests.

Docker Hub impone límites de velocidad a las solicitudes de descarga de imágenes.

Cargue la imagen en Container Registry (ACR) y descárguela desde un repositorio de imágenes de ACR.

El estado Pulling image se muestra de forma continua

Es posible que se haya activado el mecanismo de limitación de velocidad de descarga de imágenes del kubelet.

Ajuste registryPullQPS (QPS máximo para el repositorio de imágenes) y registryBurst (número máximo de descargas simultáneas de imágenes) con la función Customize node pool kubelet configurations.

Mensaje de error

Descripción

Solución

Atascado en el estado Init:N/M

El pod tiene M contenedores init; N finalizaron, pero los M-N restantes no pudieron iniciarse.

1. Revise los eventos del pod y los problemas de los contenedores init con kubectl describe pod -n <ns> <pod name>.

2. Revise los registros de los contenedores init que no se iniciaron con kubectl logs -n <ns> <pod name> -c <container name>.

3. Revise la configuración del pod, como los ajustes de comprobación de estado, para asegurarse de que los contenedores init estén configurados correctamente.

Consulte Depurar contenedores init.

Atascado en el estado Init:Error

Un contenedor init del pod no pudo iniciarse.

Atascado en el estado Init:CrashLoopBackOff

Un contenedor init del pod no pudo iniciarse y se encuentra en un bucle de reinicio.

Mensaje de error

Descripción

Solución

failed to allocate for range 0: no IP addresses available in range set: xx.xxx.xx.xx-xx.xx.xx.xx

Este comportamiento es esperado debido al diseño del plugin de red Flannel.

Actualice el componente Flannel a la versión v0.15.1.11-7e95fe23-aliyun o posterior. Consulte Flannel.

En clústeres con una versión de Kubernetes anterior a la 1.20, puede producirse una fuga de direcciones IP si un pod se reinicia repetidamente o si los pods de un CronJob terminan sus tareas y salen rápidamente.

Actualice el clúster a Kubernetes 1.20 o posterior (se recomienda la más reciente). Consulte Manually upgrade a cluster.

Defectos en containerd y runC provocan este problema.

Para aplicar una corrección de emergencia, consulte Why does my pod fail to start with the error "no IP addresses available in range"?

error parse config, can't found dev by mac 00:16:3e:01:c2:e8: not found

El plugin de red Terway mantiene una base de datos interna en el nodo para rastrear y gestionar las interfaces de red elásticas (ENI). Este error ocurre cuando el estado de la base de datos no coincide con la configuración real del dispositivo de red, lo que provoca que falle la asignación de ENI.

1. Las interfaces de red se cargan de forma asíncrona. Es posible que la interfaz aún se esté cargando durante la configuración de CNI, lo que activa un reintento automático de CNI. Este proceso no afecta la asignación final de ENI. Compruebe el estado final del pod para confirmar que fue exitoso.

2. Si la creación del pod sigue fallando y este error persiste, es probable que el controlador no haya podido cargar la ENI por falta de memoria de orden superior. Restart the ECS instance para solucionarlo.

• cmdAdd: error alloc ip rpc error: code = DeadlineExceeded desc = context deadline exceeded

• cmdAdd: error alloc ip rpc error: code = Unknown desc = error wait pod eni info, timed out waiting for the condition

Es posible que el plugin de red Terway no haya podido solicitar una dirección IP al vSwitch.

1. Consulte los registros del contenedor Terway dentro del pod del componente Terway en el nodo para revisar el proceso de asignación de ENI.

2. Consulte la información de ENI del pod de Terway con kubectl logs -n kube-system <terwayPodName > -c terway | grep <podName>. Obtenga el Request ID y el mensaje de error de OpenAPI.

3. Use el Request ID y el mensaje de error para investigar la causa del fallo.

Mensaje de error

Descripción

Solución

El registro contiene exit(0).

1. Inicie sesión en el nodo donde se despliega la carga de trabajo con errores.

2. Use docker ps -a | grep $podName para comprobarlo. Si el contenedor no tiene un proceso persistente, sale con el código de estado 0.

Los eventos del pod muestran Liveness probe failed: ....

La comprobación de actividad falló, lo que provocó el reinicio de la aplicación.

• Configuración de la comprobación de actividad: en la página Edit de la carga de trabajo (Workloads) de destino, compruebe que la ruta de solicitud de la comprobación de estado (por ejemplo, /healthz) y el puerto coincidan con los que proporciona la aplicación. Aumente Initial Delay (s) para garantizar que la comprobación de actividad comience solo después de que la aplicación se haya iniciado por completo.

  Puede deshabilitar temporalmente Liveness. Luego, acceda a la terminal del pod o a su nodo host y use un comando, como curl, para comprobar que el método de comprobación de estado funciona correctamente.

• Solucione los problemas de la aplicación: investigue el problema revisando los elementos Events y Logs del pod. Seleccione Show the log of the last container exit.

Los eventos del pod muestran Startup probe failed: ....

La comprobación de inicio falló, lo que provocó el reinicio de la aplicación.

• Configuración de la comprobación de inicio: en la página Edit de la carga de trabajo (Workloads) de destino, compruebe que la ruta de solicitud de la comprobación de estado (por ejemplo, /healthz) y el puerto coincidan con los que proporciona la aplicación. Si la aplicación tarda mucho en iniciar, aumente Unhealthy Threshold para evitar reinicios prematuros.

  Puede deshabilitar temporalmente Startup. Luego, acceda a la terminal del pod o a su nodo host y use un comando, como curl, para comprobar que el método de comprobación de estado funciona correctamente.

• Solucione los problemas de la aplicación: investigue el problema revisando los elementos Events y Logs del pod. Seleccione Show the log of the last container exit.

El registro del pod contiene no space left on device.

Espacio insuficiente en el disco en la nube.

• Resize the cloud disk.

• Elimine las imágenes innecesarias para liberar espacio en disco y configure imageGCHighThresholdPercent para establecer el umbral de recolección de basura de imágenes en el nodo.

El inicio falla sin información de eventos.

Este problema ocurre cuando un contenedor requiere más recursos que los límites declarados, lo que provoca su fallo.

Compruebe si la configuración de recursos del pod es correcta. Puede habilitar resource profiling para obtener las configuraciones recomendadas de Request y Limit del contenedor.

El registro del pod muestra Address already in use.

Existe un conflicto de puertos entre los contenedores del mismo pod.

1. Compruebe si el pod está configurado con hostNetwork: true. Esta configuración hace que los contenedores del pod compartan el espacio de nombres de red y el espacio de puertos del host. Si no es necesario, cámbielo a hostNetwork: false.

2. Si el pod requiere hostNetwork: true, configure la antiafinidad de pods para asegurar que los pods del mismo conjunto de réplicas se programen en nodos distintos.

3. Compruebe que ningún otro pod del mismo nodo esté usando el puerto.

El registro del pod muestra container init caused "setenv: invalid argument": unknown.

La carga de trabajo monta un Secret, pero el valor del Secret no está codificado en Base64.

• Cree el Secret en la consola (los valores se codifican automáticamente en Base64). Consulte Manage Secrets.

• Cree el Secret desde un archivo YAML y codifique manualmente el valor en Base64 ejecutando el comando echo -n "xxxxx" | base64.

Problema específico de la aplicación.

Revise los registros del pod para solucionar el problema.

Mensaje de error

Descripción

Solución

Los eventos del pod muestran Readiness probe failed: ....

La comprobación de disponibilidad falló, lo que impide que el pod de destino reciba tráfico.

• Configuración de la comprobación de disponibilidad: en la página Edit de la carga de trabajo (Workloads) de destino, compruebe que la ruta de comprobación de estado (por ejemplo, /healthz) y el puerto coincidan con los de la aplicación. Si la aplicación inicia lentamente, aumente Unhealthy Threshold para evitar fallos prematuros.

  Deshabilite temporalmente Readiness y luego use curl desde la terminal del pod o del host para comprobar el endpoint de la comprobación de estado.

• Solucione los problemas de la aplicación: investigue el problema revisando los elementos Events y Logs del pod. Seleccione Show the log of the last container exit.

El estado del pod es el mismo que el anterior. Los eventos del pod muestran Startup probe failed: ....

Una comprobación de inicio fallida provoca el reinicio del contenedor. Este error no debería generar un estado persistente de Running/NotReady, sino un estado CrashLoopBackOff.

Solucione este problema tal como se describe en la sección "El pod no se inicia (CrashLoopBackOff)" para las comprobaciones de tipo Startup.

Nivel de OOM

Descripción

Solución recomendada

Nivel del sistema operativo

Revise el registro del kernel en /var/log/messages del nodo donde se ejecuta el pod. Si el registro muestra un proceso finalizado pero no contiene registros de cgroup, el evento OOM ocurrió en el nivel del sistema operativo.

• Aumente la memoria del nodo o distribuya las cargas de trabajo en más nodos. Consulte Scale node resources y Schedule applications to specific nodes.

• Identifique los pods con alto consumo de memoria en el nodo y establezca límites de memoria adecuados.

Nivel de cgroup

Revise el registro del kernel en /var/log/messages del nodo donde se ejecuta el pod. Si el registro contiene un mensaje de error similar a Task in /kubepods.slice/xxxxx killed as a result of limit of /kubepods.slice/xxxx, el evento OOM ocurrió en el nivel de cgroup.

• Aumente los límites de memoria del pod. Mantenga el uso real por debajo del 80 % de los límites. Consulte Manage Pods y Scale node resources.

• Habilite resource profiling para obtener configuraciones recomendadas de solicitudes y límites del contenedor.

Causa posible

Descripción

Solución recomendada

El nodo se encuentra en estado NotReady.

El pod se elimina automáticamente después de que el nodo se recupera del estado NotReady.

El pod tiene finalizers configurados.

Si un pod tiene finalizers configurados, Kubernetes ejecuta las operaciones de limpieza especificadas por estos antes de eliminarlo. Si una operación de limpieza no responde, el pod permanece en estado Terminating.

Compruebe la configuración de finalizers del pod con kubectl get pod -n <ns> <pod name> -o yaml e investigue la causa.

El hook preStop del pod no es válido o está bloqueado.

Si el pod tiene configurado un hook preStop, Kubernetes lo ejecuta antes de finalizar el contenedor. El pod permanece en estado Terminating mientras el hook se ejecuta.

Compruebe la configuración del hook preStop del pod con kubectl get pod -n <ns> <pod name> -o yaml e investigue la causa.

El pod tiene configurado un periodo de apagado controlado.

Si un pod tiene configurado un periodo de apagado controlado (terminationGracePeriodSeconds), entra en estado Terminating después de recibir un comando de finalización, como kubectl delete pod <pod_name>. Kubernetes considera que el pod se apagó correctamente solo cuando transcurre el tiempo especificado en terminationGracePeriodSeconds o cuando el contenedor termina.

Kubernetes elimina automáticamente el pod después de que el contenedor completa el apagado controlado.

El contenedor no responde.

Cuando usted solicita detener o eliminar un pod, Kubernetes envía una señal SIGTERM a los contenedores del pod. Si un contenedor no procesa correctamente la señal SIGTERM durante la finalización, el pod podría permanecer en estado Terminating.

1. Elimine el pod de forma forzada con kubectl delete pod <pod-name> --grace-period=0 --force.

2. Revise los registros de containerd o Docker en el nodo del pod para continuar la investigación.

Causa posible

Descripción

Solución recomendada

El nodo presenta presión de recursos debido a factores como el uso de memoria o de disco.

Es posible que el nodo experimente presión de memoria, de disco o de PID.

• Compruebe los taints del nodo con kubectl describe node <node name> | grep Taints. La salida podría incluir:

  • Presión de memoria: el nodo tiene el taint node.kubernetes.io/memory-pressure.

  • Presión de disco: el nodo tiene el taint node.kubernetes.io/disk-pressure.

  • Presión de PID: el nodo tiene el taint node.kubernetes.io/pid-pressure.

• El estado del pod es uno de los siguientes:

  • Evicted

  • ContainerStatusUnknown, y el campo reason en el archivo YAML del pod muestra Evicted.

• Presión de memoria:

  • Ajuste la configuración de recursos del pod según sus requisitos de negocio. Consulte Manage pods.

  • Actualice el nodo. Consulte Scale node resources.

• Presión de disco:

  • Limpie periódicamente los registros de aplicación de los pods en el nodo para liberar espacio en disco.

  • Expanda el disco del nodo. Consulte Step 1: Resize a cloud disk.

• Presión de PID: ajuste la configuración de recursos del pod. Consulte Límites y reservas de ID de proceso.

Ocurre una expulsión inesperada.

Un taint NoExecute agregado manualmente en el nodo del pod provocó una expulsión inesperada.

Compruebe si existe un taint NoExecute con kubectl describe node <node name> | grep Taints. Si existe, elimínelo.

La expulsión no avanza como se esperaba.

• --pod-eviction-timeout: los pods de un nodo con errores se expulsan después de este periodo de tiempo de espera. El valor predeterminado es 5 minutos.

• --node-eviction-rate: la cantidad de pods que se expulsan de un nodo por segundo. El valor predeterminado es 0.1, lo que significa que se expulsa como máximo un pod de un nodo cada 10 segundos.

• --secondary-node-eviction-rate: la tasa secundaria de expulsión de nodos. Si demasiados nodos de un clúster presentan errores, la tasa de expulsión se reduce a este valor. El valor predeterminado es 0.01.

• --unhealthy-zone-threshold: el umbral de zona de disponibilidad con estado incorrecto. El valor predeterminado es 0.55. Cuando la fracción de nodos con errores en una zona de disponibilidad supera este umbral, la zona se considera en estado incorrecto.

• --large-cluster-size-threshold: el umbral de tamaño de clúster grande. El valor predeterminado es 50. Un clúster se considera grande cuando tiene más de 50 nodos.

En un clúster pequeño (50 nodos o menos), si más del 55 % de los nodos presentan errores, la expulsión de pods se detiene. Consulte Límites de velocidad en la expulsión.

En un clúster grande (más de 50 nodos), si la fracción de nodos con estado incorrecto supera el valor de --unhealthy-zone-threshold (valor predeterminado 0.55), la tasa de expulsión disminuye a --secondary-node-eviction-rate (valor predeterminado 0.01 pods por segundo). Consulte Límites de velocidad en la expulsión.

Un pod se reprograma frecuentemente en su nodo original después de ser expulsado.

El kubelet expulsa pods según el uso real de recursos, mientras que el programador los ubica según las solicitudes de recursos. Como una expulsión libera recursos, el programador podría reprogramar un pod en el mismo nodo si sus solicitudes aún caben.

Ajuste las solicitudes de recursos del pod para que coincidan con los recursos asignables del nodo. Consulte Set CPU and memory resources for a container. Habilite resource profiling para obtener valores recomendados de solicitudes y límites.