Soluciona problemas de cargas de trabajo implementadas

En esta página, se muestra cómo resolver errores con tus cargas de trabajo implementadas en Google Kubernetes Engine (GKE).

Para obtener más consejos generales sobre la solución de problemas de tus aplicaciones, consulta Cómo solucionar problemas de aplicaciones en la documentación de Kubernetes.

Todos los errores: Verifica el estado del Pod

Si hay problemas con los Pods de una carga de trabajo, Kubernetes actualiza el estado del Pod con un mensaje de error. Para ver estos errores, verifica el estado de un Pod con la consola de Google Cloud o la herramienta de línea de comandos de kubectl.

Console

Sigue los siguientes pasos:

  1. En la consola de Google Cloud , ve a la página Cargas de trabajo.

    Ir a Cargas de trabajo

  2. Elige la carga de trabajo que deseas investigar. La pestaña Descripción general muestra el estado de la carga de trabajo.

  3. En la sección Pods administrados, haz clic en un mensaje de estado de error.

kubectl

Para ver todos los pods en ejecución en tu clúster, ejecuta el comando siguiente:

kubectl get pods

El resultado es similar a este:

NAME       READY  STATUS             RESTARTS  AGE
POD_NAME   0/1    CrashLoopBackOff   23        8d

Los posibles errores se indican en la columna Status.

Para obtener más información sobre un Pod específico, ejecuta el siguiente comando:

kubectl describe pod POD_NAME

Reemplaza POD_NAME por el nombre del Pod que quieres investigar.

En el resultado, el campo Events muestra más información sobre los errores.

Si quieres obtener más información, consulta los registros del contenedor:

kubectl logs POD_NAME

Estos registros pueden ayudarte a identificar si un comando o código en el contenedor hizo que el Pod fallara.

Después de identificar el error, usa las siguientes secciones para intentar resolver el problema.

Error: CrashLoopBackOff

Un estado de CrashLoopBackOff no significa que haya un error específico, sino que indica que un contenedor falla repetidas veces después de reiniciarse.

Para obtener más información, consulta Soluciona problemas relacionados con eventos de CrashLoopBackOff.

Errores: ImagePullBackOff y ErrImagePull

Un estado de ImagePullBackOff o ErrImagePull indica que la imagen que usa un contenedor no se puede cargar desde el registro de imágenes.

Para obtener orientación sobre la solución de problemas relacionados con estos estados, consulta Soluciona problemas de extracción de imágenes.

Error: OutOfPods

El estado OutOfPods indica que un nodo no puede ejecutar un Pod porque alcanzó su capacidad máxima de Pods.

Síntomas

Es posible que veas un mensaje en los eventos del Pod similar al siguiente:

Node didn't have enough resource: pods, requested: 1, used: 32, capacity: 32

Causa

Este error se produce cuando hay una solicitud para programar un Pod en un nodo que ya está al máximo de su capacidad. Esta situación puede ocurrir con frecuencia durante el inicio del nodo, por ejemplo, cuando el componente kube-scheduler asigna Pods a un nodo nuevo antes de que el agente kubelet haya informado la presencia de Pods estáticos, como el componente kube-proxy, que requieren su propia capacidad de Pods.

Solución

Para resolver este problema, prueba una de las siguientes soluciones:

  • Aumenta la cantidad máxima de Pods por nodo. Si tus nodos alcanzan de forma constante su límite de Pods, aumenta el parámetro de configuración --max-pods-per-node para tus grupos de nodos. Aumentar la cantidad de Pods podría requerir nodos más grandes para controlar la mayor demanda de recursos.

  • Habilita el escalador automático de clústeres y el aprovisionamiento automático de nodos. Si con frecuencia te quedas sin capacidad de Pods, habilitar el escalador automático del clúster y el aprovisionamiento automático de nodos puede ayudar a garantizar que el clúster tenga suficientes nodos para satisfacer la demanda de tus cargas de trabajo.

  • Cambia el perfil de ajuste de escala automático. Si ya usas el escalador automático del clúster, intenta cambiar el perfil de ajuste de escala automático al perfil balanced en lugar del perfil optimize-utilization. El perfil optimize-utilization puede aumentar la probabilidad de errores de OutOfPods porque intenta colocar Pods en los nodos más utilizados.

Error: Pod no programable

Un estado de PodUnschedulable indica que tu Pod no se puede programar debido a recursos insuficientes o a algún error de configuración.

Si configuraste las métricas del plano de control, puedes encontrar más información sobre estos errores en las métricas del programador y las métricas del servidor de la API.

Usa la guía interactiva de Pods no programables

Puedes solucionar problemas PodUnschedulable con la guía interactiva en la consola de Google Cloud :

  1. Ve a la guía interactiva de Pods no programables:

    Ir a la guía

  2. En la lista desplegable Clúster, selecciona el clúster para el que deseas solucionar el problema. Si no encuentras tu clúster, ingresa su nombre en el campo Filtro de .

  3. En la lista desplegable Espacio de nombres, selecciona el espacio de nombres para el que deseas solucionar problemas. Si no encuentras tu espacio de nombres, ingresa su nombre en el campo Filtro de .

  4. Para ayudarte a identificar la causa, revisa cada una de las secciones de la guía:

    1. Investiga la CPU y la memoria
    2. Investiga la cantidad máxima de Pods por nodo
    3. Investiga el comportamiento del escalador automático
    4. Investiga otros modos de falla
    5. Correlaciona los eventos de cambio

  5. Opcional: Para recibir notificaciones sobre errores PodUnschedulable futuros, en la sección Sugerencias para mitigaciones futuras, selecciona Crear una alerta.

Error: Recursos insuficientes

El estado PodUnschedulable puede ocurrir si no hay suficiente CPU, memoria o recursos para satisfacer las solicitudes del Pod.

Síntomas

Puedes encontrar un error que indique una falta de CPU, memoria o algún otro recurso. Por ejemplo: No nodes are available that match all of the predicates: Insufficient cpu (2). Este mensaje indica que, en dos nodos, no hay suficiente CPU disponible para cumplir con las solicitudes de un Pod.

Causa

Si las solicitudes de recursos de tu Pod superan las de un solo nodo de cualquier grupo de nodos apto, GKE no programa el Pod ni activa el escalamiento vertical para agregar un nodo nuevo.

Tu clúster ejecuta contenedores de sistema en el espacio de nombres kube-system. Esos contenedores también usan recursos de clúster.

Solución

Prueba las siguientes soluciones:

  • Ajusta la solicitud de recursos del Pod especificando un valor más bajo en el campo spec: containers: resources: requests. La solicitud de CPU predeterminada es de 100 m o el 10% de una CPU (o un núcleo).

  • Crea un grupo de nodos nuevo con nodos que tengan recursos suficientes para satisfacer las solicitudes del Pod.

  • Habilita el aprovisionamiento automático de nodos para que GKE pueda crear de forma automática grupos de nodos con nodos en los que puedan ejecutarse los Pods no programados.

Error: MatchNodeSelector

Un error MatchNodeSelector indica que no hay nodos que coincidan con el selector de etiquetas del Pod.

Síntomas

El estado o los eventos del Pod muestran un error MatchNodeSelector.

Causa

Las etiquetas especificadas en el campo nodeSelector del manifiesto del Pod no existen en ningún nodo del clúster.

Solución

Para resolver este error, asegúrate de que las etiquetas especificadas en el campo nodeSelector del Pod coincidan con las etiquetas de, al menos, un nodo de tu clúster:

  1. Para identificar los requisitos de etiquetas que busca el Pod, revisa su campo spec: nodeSelector.

  2. Para ver si alguna etiqueta coincide con los requisitos del Pod, consulta las etiquetas reales asignadas a los nodos de tu clúster:

    kubectl get nodes --show-labels

  3. Si un nodo está destinado a ejecutar este Pod, adjunta la etiqueta necesaria:

    kubectl label nodes NODE_NAME LABEL_KEY=LABEL_VALUE

    Reemplaza lo siguiente:

    • NODE_NAME: Es el nodo al que deseas agregar una etiqueta.
    • LABEL_KEY: la clave de la etiqueta.
    • LABEL_VALUE: el valor de la etiqueta.

Para obtener más información, consulta Asigna Pods a nodos en la documentación de Kubernetes.

Error: PodToleratesNodeTaints

Un error PodToleratesNodeTaints indica que el Pod no se puede programar en ningún nodo porque no tiene tolerancias que correspondan a los taints de nodo existentes.

Síntomas

El estado o los eventos del Pod muestran un error PodToleratesNodeTaints.

Causa

El Pod no se puede programar en ningún nodo porque no tiene tolerancias que correspondan a los taints de nodo existentes.

Solución

  1. Verifica los taints en el nodo:

    kubectl describe nodes NODE_NAME

    En el resultado, verifica el campo Taints, que enumera pares clave-valor y efectos de programación. Si el efecto indicado es NoSchedule, no se puede programar ningún Pod en ese nodo, a menos que tenga una tolerancia coincidente.

  2. Quita el taint del nodo. Por ejemplo, para quitar un taint NoSchedule, ejecuta el siguiente comando:

    kubectl taint nodes NODE_NAME key:NoSchedule-

Error: PodFitsHostPorts

El error PodFitsHostPorts significa que un nodo está intentando usar un puerto que ya está ocupado.

Síntomas

El estado del Pod muestra un error PodFitsHostPorts.

Causa

Un Pod solicita un puerto de host que ya está en uso por otro Pod o proceso en el nodo de destino.

Solución

Para resolver el problema, considera seguir las prácticas recomendadas de Kubernetes y usar un servicio NodePort en lugar del parámetro de configuración hostPort.

Si debes usar un puerto de host, verifica los manifiestos de los Pods y asegúrate de que todos los Pods del mismo nodo tengan valores únicos definidos para el parámetro de configuración hostPort.

Error: No tiene disponibilidad mínima

Este error puede ocurrir si un nodo tiene recursos suficientes, pero no está disponible para la programación.

Síntomas

  • Verás el error Does not have minimum availability.

  • El estado del nodo muestra un estado SchedulingDisabled o un estado Cordoned.

Causa

El estado de acordonamiento del nodo impide que se programen Pods nuevos en él.

Solución

Para que el nodo vuelva a estar disponible para programar Pods, desacordónalo:

Console

Sigue los siguientes pasos:

  1. Accede a la página de Google Kubernetes Engine en la consola de Google Cloud .

    Ir a Google Kubernetes Engine

  2. Selecciona el clúster que deseas explorar. La pestaña Nodos muestra los nodos y su estado.

Para habilitar la programación en el nodo, realiza los pasos siguientes:

  1. En la lista, haz clic en el nodo que quieres investigar.

  2. En la sección Detalles del nodo, haz clic en Desvincular.

kubectl

Para obtener los estados de los nodos, ejecuta el siguiente comando:

kubectl get nodes

Para habilitar la programación en el nodo, ejecuta lo siguiente:

kubectl uncordon NODE_NAME

Error: Se alcanzó el límite máximo de Pods por nodo

Un error Too many pods indica que no se puede programar un Pod porque el nodo de destino alcanzó su capacidad máxima de Pods configurada.

Síntomas

  • Los Pods están atascados en un estado Unschedulable.
  • Verás un mensaje que incluye la frase Too many pods.

Causa

Todos los nodos del clúster alcanzan el límite de máximo de Pods por nodo.

Solución

Para resolver este error, completa los siguientes pasos:

  1. Verifica la configuración de Maximum pods per node desde la pestaña Nodos en los detalles del clúster de GKE en la consola de Google Cloud .

  2. Obtén una lista de nodos:

    kubectl get nodes

  3. Para cada nodo, verifica la cantidad de Pods que se ejecutan en el nodo:

    kubectl get pods -o wide | grep NODE_NAME | wc -l

  4. Si se alcanza el límite, agrega un grupo de nodos nuevo o agrega nodos adicionales al grupo existente.

Problema: Se alcanzó el tamaño máximo del grupo de nodos con el escalador automático del clúster habilitado

Este problema se produce cuando un grupo de nodos alcanza su tamaño máximo configurado en el escalador automático del clúster.

Síntomas

GKE no activa el escalamiento vertical para un Pod que, de lo contrario, se programaría con este grupo de nodos. En su lugar, el Pod permanece en un estado Pending.

Causa

El grupo de nodos alcanzó su tamaño máximo según la configuración del escalador automático de clústeres.

Solución

Aumenta el tamaño máximo del grupo de nodos cambiando la configuración del escalador automático del clúster.

Problema: Tamaño máximo del grupo de nodos alcanzado con el escalador automático del clúster inhabilitado

Este problema se produce cuando un grupo de nodos alcanza su tamaño máximo y el escalador automático del clúster está inhabilitado.

Síntomas

GKE no puede programar el Pod con el grupo de nodos.

Causa

El grupo de nodos alcanzó la cantidad máxima de nodos y el escalador automático del clúster está inhabilitado.

Solución

Para resolver este problema, prueba una de las siguientes soluciones:

Error: PersistentVolumeClaims no vinculados

Un error Unbound PersistentVolumeClaims indica que el Pod hace referencia a una PersistentVolumeClaim que no está vinculada.

Síntomas

El estado o los eventos del Pod muestran un error Unbound PersistentVolumeClaims.

Causa

Este error puede ocurrir por uno de los siguientes motivos:

  • No se pudo aprovisionar tu PersistentVolume.
  • Se produjo un error de configuración durante el aprovisionamiento previo manual de un PersistentVolume y su vinculación a una PersistentVolumeClaim.

Solución

  1. Para verificar si falló el aprovisionamiento, obtén los eventos de tu PersistentVolumeClaim:

    kubectl describe pvc STATEFULSET_NAME-PVC_NAME-0

    Reemplaza lo siguiente:

    • STATEFULSET_NAME: Es el nombre del objeto StatefulSet.
    • PVC_NAME: El nombre del objeto PersistentVolumeClaim.

  2. Intenta aprovisionar el volumen de nuevo.

Error: Cuota insuficiente

Si GKE intenta escalar verticalmente tu clúster para programar un Pod, pero encuentra restricciones de cuota, el escalamiento vertical falla.

Síntomas

Recibes el mensaje de error scale.up.error.quota.exceeded en los eventos de tu Pod.

Causa

Si se escala verticalmente el clúster, se superaría la cuota disponible de tu proyecto.

Solución

Verifica que tu proyecto tenga suficiente cuota de Compute Engine para que GKE escale verticalmente tu clúster. Para obtener más información, consulta Errores de ScaleUp.

Problema: APIs obsoletas

El uso de APIs que ya no se admiten en tus manifiestos puede impedir la implementación de la carga de trabajo.

Síntomas

Las cargas de trabajo no se pueden implementar ni ejecutar debido al uso de APIs obsoletas.

Causa

Tus manifiestos usan APIs obsoletas que se quitaron en la versión secundaria de tu clúster.

Solución

Asegúrate de no usar APIs obsoletas. Actualiza tus manifiestos para usar APIs compatibles. Para obtener más información, consulta Bajas de funciones y APIs.

Error: No había puertos libres para los puertos de Pod solicitados

Vincular un Pod a un puerto de host limita los lugares en los que GKE puede programar el Pod, ya que cada combinación de dirección hostIP, parámetro de configuración hostPort y valor protocol debe ser única.

Síntomas

Verás un error similar al siguiente:

0/1 nodes are available: 1 node(s) didn't have free ports for the requested pod ports. preemption: 0/1 nodes are available: 1 No preemption victims found for incoming pod.

Causa

Varios Pods en el mismo nodo especifican el mismo valor definido en el campo hostPort.

Solución

Para resolver este problema, prueba una de las siguientes soluciones:

  • Sigue las prácticas recomendadas de Kubernetes y usa un servicio NodePort en lugar de un puerto de host.
  • Si debes usar un puerto de host, verifica los manifiestos de los Pods y asegúrate de que todos los Pods del mismo nodo tengan valores únicos definidos para el campo hostPort.

Problema: Fallas de la aplicación y la sonda en los Pods

Este problema se produce cuando ejecutas aplicaciones que usan HTTPS para comunicarse con un servidor.

Síntomas

Las fallas en estas aplicaciones son similares a las siguientes:

  • Los Pods no se inician y los contenedores fallan con el código de salida 137.

  • Los sondeos de funcionamiento o preparación fallan con un mensaje de error similar al siguiente:

    probeResult="failure" output="Get "https://example.com/healthy": EOF"

  • Los Pods se ejecutan según lo esperado, pero los registros de la aplicación muestran errores de conexión.

Causa

Las versiones 1.30 y posteriores de Kubernetes usan versiones de Golang que inhabilitan los siguientes conjuntos de algoritmos de cifrado de TLS:

  • TLS_RSA_WITH_AES_128_GCM_SHA256
  • TLS_RSA_WITH_AES_256_GCM_SHA384
  • TLS_RSA_WITH_AES_128_CBC_SHA
  • TLS_RSA_WITH_AES_256_CBC_SHA
  • TLS_RSA_WITH_3DES_EDE_CBC_SHA

Solución

Usa conjuntos de algoritmos de cifrado compatibles de TLS 1.2 y versiones posteriores.

¿Qué sigue?