Solucionar problemas de eventos CrashLoopBackOff

Si tus pods de Google Kubernetes Engine (GKE) están bloqueados en un estado CrashLoopBackOff, significa que uno o varios contenedores se inician y se cierran repetidamente. Es probable que este comportamiento haga que tus aplicaciones sean inestables o que no estén disponibles.

Usa esta página para diagnosticar y resolver las causas subyacentes, que suelen clasificarse en categorías como limitaciones de recursos, problemas con las sondas de actividad, errores de la aplicación o errores de configuración. Solucionar estos problemas ayuda a que tus aplicaciones funcionen de forma fiable y sigan estando disponibles para tus usuarios.

Esta información es importante para los desarrolladores de aplicaciones que quieran identificar y solucionar problemas a nivel de aplicación, como errores de codificación, puntos de entrada incorrectos, problemas con archivos de configuración o problemas de conexión con dependencias. Los administradores y operadores de la plataforma pueden identificar y solucionar problemas relacionados con la plataforma, como el agotamiento de recursos (OOMKilled), las interrupciones de nodos o las sondas de actividad mal configuradas. Para obtener más información sobre los roles habituales y las tareas de ejemplo a las que hacemos referencia en el contenido de Google Cloud , consulta Roles y tareas habituales de usuario de GKE.

Información sobre el evento CrashLoopBackOff

Cuando tu pod se queda bloqueado en un estado CrashLoopBackOff, significa que un contenedor de su interior se inicia, falla o se cierra repetidamente. Este CrashLoop hace que Kubernetes intente reiniciar el contenedor siguiendo su restartPolicy. Con cada reinicio fallido, el retraso de BackOff antes del siguiente intento aumenta de forma exponencial (por ejemplo, 10 s, 20 s y 40 s) hasta un máximo de cinco minutos.

Aunque este evento indica que hay un problema en tu contenedor, también es una señal de diagnóstico valiosa. Un evento CrashLoopBackOff confirma que ya se han completado muchos pasos fundamentales de la creación del pod, como la asignación a un nodo y la extracción de la imagen del contenedor. Este conocimiento te permite centrar tu investigación en la aplicación o la configuración del contenedor, en lugar de en la infraestructura del clúster.

El estado CrashLoopBackOff se produce debido a la forma en que Kubernetes, concretamente kubelet, gestiona la finalización de los contenedores en función de la política de reinicio del pod. El ciclo suele seguir este patrón:

  1. El contenedor se inicia.
  2. El contenedor se cierra.
  3. El kubelet observa el contenedor detenido y lo reinicia según el restartPolicy del pod.
  4. Este ciclo se repite y el contenedor se reinicia después de un retraso de tiempo de espera exponencial cada vez mayor.

El restartPolicy del pod es la clave de este comportamiento. La política predeterminada, Always, es la causa más habitual de este bucle, ya que reinicia un contenedor si se cierra por cualquier motivo, incluso después de cerrarse correctamente. Es menos probable que la política OnFailure provoque un bucle porque solo se reinicia con códigos de salida distintos de cero, y la política Never evita por completo el reinicio.

Identificar los síntomas de un evento CrashLoopBackOff

Un pod con el estado CrashLoopBackOff es el principal indicador de un evento CrashLoopBackOff.

Sin embargo, es posible que experimentes algunos síntomas menos evidentes de un evento de CrashLoopBackOff:

  • No hay réplicas en buen estado para una carga de trabajo.
  • Una disminución drástica de las réplicas correctas.
  • Las cargas de trabajo con el autoescalado horizontal de pods habilitado se escalan lentamente o no se escalan.

Si una system carga de trabajo (por ejemplo, un agente de registro o de métricas) tiene el estado CrashLoopBackOff, también puedes observar los siguientes síntomas:

  • No se registran algunas métricas de GKE.
  • Algunos paneles y gráficos de GKE tienen lagunas.
  • Problemas de conectividad en la red a nivel de pod.

Si observas alguno de estos síntomas menos evidentes, el siguiente paso es confirmar si se ha producido un CrashLoopBackOff.

Confirmar un evento CrashLoopBackOff

Para confirmar e investigar un evento CrashLoopBackOff, recopila pruebas de los eventos de Kubernetes y de los registros de la aplicación del contenedor. Estas dos fuentes ofrecen puntos de vista diferentes, pero complementarios, sobre el problema:

  • Los eventos de Kubernetes confirman que un pod falla.
  • Los registros de la aplicación del contenedor pueden mostrarte por qué falla el proceso dentro del contenedor.

Para ver esta información, selecciona una de las siguientes opciones:

Consola

Para ver los eventos de Kubernetes y los registros de aplicaciones, haz lo siguiente:

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

    Ve a Cargas de trabajo.

  2. Selecciona la carga de trabajo que quieras investigar. En la pestaña Información general o Detalles se muestra más información sobre el estado de la carga de trabajo.

  3. En la sección Pods gestionados, haz clic en el nombre del pod que tiene problemas.

  4. En la página Detalles del pod, investiga lo siguiente:

    • Para ver los detalles de los eventos de Kubernetes, ve a la pestaña Eventos.
    • Para ver los registros de la aplicación del contenedor, ve a la pestaña Registros. En esta página se encuentran los mensajes de error o los rastreos de pila específicos de la aplicación.

kubectl

Para ver los eventos de Kubernetes y los registros de aplicaciones, haz lo siguiente:

  1. Consulta el estado de todos los pods que se ejecutan en tu clúster:

    kubectl get pods

    El resultado debería ser similar al siguiente:

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

    En el resultado, revisa las siguientes columnas:

    • Ready: revisa cuántos contenedores están listos. En este ejemplo, 0/1 indica que ninguno de los contenedores esperados está en estado de preparado. Este valor es un signo claro de que hay un problema.
    • Status: busca pods con el estado CrashLoopBackOff.
    • Restarts: un valor alto indica que Kubernetes intenta iniciar el contenedor repetidamente y no lo consigue.

  2. Una vez que hayas identificado un pod que no funciona, descríbelo para ver los eventos a nivel de clúster relacionados con el estado del pod:

    kubectl describe pod POD_NAME -n NAMESPACE_NAME

    Haz los cambios siguientes:

    • POD_NAME: el nombre del pod que has identificado en el resultado del comando kubectl get.
    • NAMESPACE_NAME: el espacio de nombres del pod.

    El resultado debería ser similar al siguiente:

    Containers:
container-name:
...
  State:          Waiting
    Reason:       CrashLoopBackOff
  Last State:     Terminated
    Reason:       StartError
    Message:      failed to create containerd task: failed to create shim task: context deadline exceeded: unknown
    Exit Code:    128
    Started:      Thu, 01 Jan 1970 00:00:00 +0000
    Finished:     Fri, 27 Jun 2025 16:20:03 +0000
  Ready:          False
  Restart Count:  3459
...
Conditions:
Type                        Status
PodReadyToStartContainers   True
Initialized                 True
Ready                       False
ContainersReady             False
PodScheduled                True
...
Events:
Type     Reason   Age                     From     Message
----     ------   ----                    ----     -------
Warning  Failed   12m (x216 over 25h)     kubelet  Error: context deadline exceeded
Warning  Failed   8m34s (x216 over 25h)   kubelet  Error: context deadline exceeded
Warning  BackOff  4m24s (x3134 over 25h)  kubelet  Back-off restarting failed container container-name in pod failing-pod(11111111-2222-3333-4444-555555555555)

    En el resultado, comprueba los siguientes campos para detectar signos de un evento CrashLoopBackOff:

    • State: es probable que el estado del contenedor sea Waiting y el motivo sea CrashLoopBackOff.
    • Last State: el estado del contenedor que se ha terminado anteriormente. Busca el estado Terminated y revisa el código de salida para ver si se ha producido un fallo (código de salida distinto de cero) o una salida correcta inesperada (código de salida cero).
    • Events: acciones realizadas por el propio clúster. Busca mensajes sobre el inicio del contenedor, seguidos de errores de la sonda de vivacidad o advertencias de retardo, como Back-off restarting failed container.

  3. Para obtener más información sobre por qué ha fallado el pod, consulta sus registros de aplicaciones:

    kubectl logs POD_NAME --previous

    La marca --previous obtiene los registros del contenedor anterior que se ha terminado, que es donde puedes encontrar el seguimiento de pila o el mensaje de error específicos que revelan la causa del fallo. Es posible que el contenedor actual sea demasiado nuevo para haber registrado algún registro.

    En la salida, busca errores específicos de la aplicación que provoquen que el proceso se cierre. Si usas una aplicación personalizada, los desarrolladores que la crearon son los más indicados para interpretar estos mensajes de error. Si usas una aplicación prediseñada, estas aplicaciones suelen proporcionar sus propias instrucciones de depuración.

Usar el manual interactivo de pods en bucle de fallos

Después de confirmar un evento CrashLoopBackOff, empieza a solucionar los problemas con la guía interactiva:

  1. En la Google Cloud consola, ve a la página GKE Interactive Playbook - Crashlooping Pods (Guía interactiva de GKE: pods en bucle de fallos).

    Ir a Pods en bucle de fallos

  2. En la lista Clúster, selecciona el clúster que quieras solucionar. Si no encuentras tu clúster, introduce su nombre en el campo Filtrar.

  3. En la lista Espacio de nombres, seleccione el espacio de nombres que quiera solucionar. Si no encuentras tu espacio de nombres, introdúcelo en el campo Filtrar.

  4. Lee cada sección para responder las siguientes preguntas:

    1. Identificar errores de aplicaciones: ¿qué contenedores se están reiniciando?
    2. Investiga los problemas de falta de memoria: ¿hay alguna configuración incorrecta o algún error relacionado con la aplicación?
    3. Investiga las interrupciones de los nodos: ¿las interrupciones en el recurso del nodo provocan reinicios de contenedores?
    4. Investiga los fallos de las comprobaciones de actividad: ¿las comprobaciones de actividad detienen tus contenedores?
    5. Correlacionar eventos de cambio: ¿qué ocurrió cuando los contenedores empezaron a fallar?

  5. Opcional: Para recibir notificaciones sobre futuros eventos de CrashLoopBackOff, en la sección Consejos de mitigación futuros, selecciona Crear alerta.

Si el problema persiste después de usar el manual de procedimientos, consulta el resto de la guía para obtener más información sobre cómo resolver eventos de CrashLoopBackOff.

Resolver un evento CrashLoopBackOff

En las secciones siguientes se explica cómo solucionar los problemas más habituales relacionados con los eventos CrashLoopBackOff:

Resolver el agotamiento de recursos

Un evento CrashLoopBackOff suele deberse a un problema de falta de memoria (OOM). Puedes confirmar si esta es la causa si el resultado de kubectl describe muestra lo siguiente:

Last State: Terminated
  Reason: OOMKilled

Para obtener información sobre cómo diagnosticar y resolver eventos de falta de memoria, consulta el artículo Solucionar problemas de eventos de falta de memoria.

Resolver errores de comprobación de actividad

Una prueba de actividad es una comprobación del estado periódica que realiza el kubelet. Si la sonda falla un número de veces especificado (el número predeterminado es tres), kubelet reinicia el contenedor, lo que puede provocar un evento CrashLoopBackOff si los fallos de la sonda continúan.

Confirmar si el problema se debe a una prueba de actividad

Para confirmar si los fallos de la sonda de actividad están activando el evento CrashLoopBackOff, consulta los registros de kubelet. Estos registros suelen contener mensajes explícitos que indican fallos de la sonda y reinicios posteriores.

  1. En la Google Cloud consola, ve a la página Explorador de registros.

    Ir a Explorador de registros

  2. En el panel de consultas, filtra los reinicios relacionados con la sonda de actividad introduciendo la siguiente consulta:

    resource.type="k8s_node"
log_id("kubelet")
jsonPayload.MESSAGE:"failed liveness probe, will be restarted"
resource.labels.cluster_name="CLUSTER_NAME"

    Sustituye CLUSTER_NAME por el nombre de tu clúster.

  3. Revisa el resultado. Si el error de una prueba de actividad es la causa de tus eventos CrashLoopBackOff, la consulta devolverá mensajes de registro similares a los siguientes:

    Container probe failed liveness probe, will be restarted

Una vez que hayas confirmado que las comprobaciones de actividad son la causa del evento CrashLoopBackOff, procede a solucionar los problemas habituales:

Revisar la configuración de la comprobación de actividad

Las sondas mal configuradas son una causa frecuente de eventos CrashLoopBackOff. Comprueba los siguientes ajustes en el manifiesto de tu sonda:

  • Verifica el tipo de sonda: la configuración de la sonda debe coincidir con la forma en que tu aplicación informa de su estado. Por ejemplo, si tu aplicación tiene una URL de comprobación del estado (como /healthz), usa el tipo de sondeo httpGet. Si su estado se determina ejecutando un comando, usa el tipo de sonda exec. Por ejemplo, para comprobar si un puerto de red está abierto y en escucha, usa el tipo de sondeo tcpSocket.
  • Comprobar los parámetros de la sonda:
    • Ruta (para el tipo de sondeo httpGet): comprueba que la ruta HTTP sea correcta y que tu aplicación sirva comprobaciones de estado en ella.
    • Puerto: comprueba que la aplicación usa y expone el puerto configurado en la sonda.
    • Comando (para el tipo de sondeo exec): comprueba que el comando exista en el contenedor, devuelva un código de salida 0 si se ejecuta correctamente y se complete en el periodo timeoutSeconds configurado.
    • Tiempo de espera: asegúrate de que el valor de timeoutSeconds sea suficiente para que la aplicación responda, sobre todo durante el inicio o cuando esté sometida a carga.
    • Retraso inicial (initialDelaySeconds): comprueba si el retraso inicial es suficiente para que la aplicación se inicie antes de que empiecen las comprobaciones.

Para obtener más información, consulta el artículo Configurar sondas de vivacidad, preparación e inicio de la documentación de Kubernetes.

Inspeccionar el uso de la CPU y de E/S de disco

La contención de recursos provoca que se agote el tiempo de espera de las sondas, lo que es una de las principales causas de los errores de las sondas de vivacidad. Para comprobar si el uso de recursos es la causa del fallo de la sonda de actividad, prueba las siguientes soluciones:

  • Analizar el uso de la CPU: monitoriza el uso de la CPU del contenedor afectado y del nodo en el que se ejecuta durante los intervalos de la sonda. Una métrica clave que debes monitorizar es kubernetes.io/container/cpu/core_usage_time. Un uso elevado de la CPU en el contenedor o el nodo puede impedir que la aplicación responda a la comprobación a tiempo.
  • Monitorizar E/S de disco: comprueba las métricas de E/S de disco del nodo. Puedes usar la métrica compute.googleapis.com/guest/disk/operation_time para evaluar el tiempo dedicado a las operaciones de disco, que se clasifican en lecturas y escrituras. Una E/S de disco alta puede ralentizar significativamente el inicio del contenedor, la inicialización de la aplicación o el rendimiento general de la aplicación, lo que provoca que se agote el tiempo de espera de la sonda.

Abordar implementaciones de gran tamaño

En situaciones en las que se implementan simultáneamente un gran número de pods (por ejemplo, con una herramienta de CI/CD como ArgoCD), un aumento repentino de pods nuevos puede sobrecargar los recursos del clúster, lo que provoca el agotamiento de los recursos del plano de control. Esta falta de recursos retrasa el inicio de la aplicación y puede provocar que las comprobaciones de actividad fallen repetidamente antes de que las aplicaciones estén listas.

Para solucionar este problema, prueba las siguientes soluciones:

  • Implementar implementaciones escalonadas: implementa estrategias para desplegar pods en lotes o durante un periodo más largo para evitar sobrecargar los recursos de los nodos.
  • Reconfigurar o escalar nodos: si las implementaciones escalonadas no son viables, considera la posibilidad de actualizar los nodos con discos más rápidos o más grandes, o con reclamaciones de volumen persistente, para gestionar mejor el aumento de la demanda de E/S. Asegúrate de que el escalado automático del clúster esté configurado correctamente.
  • Espera y observa: en algunos casos, si el clúster no tiene pocos recursos, las cargas de trabajo pueden implementarse al cabo de un tiempo (a veces, 30 minutos o más).

Corregir errores transitorios

Es posible que la aplicación experimente errores temporales o ralentizaciones durante el inicio o la inicialización, lo que provoca que la sonda falle inicialmente. Si la aplicación se recupera, considera la posibilidad de aumentar los valores definidos en los campos initialDelaySeconds o failureThreshold del manifiesto de tu prueba de actividad.

Abordar el consumo de recursos de las sondas

En raras ocasiones, la ejecución de la sonda de actividad puede consumir una cantidad significativa de recursos, lo que podría provocar restricciones de recursos que podrían llevar a que se terminara el contenedor debido a un error de falta de memoria. Asegúrate de que los comandos de la sonda sean ligeros. Es más probable que una sonda ligera se ejecute de forma rápida y fiable, lo que le da una mayor fidelidad a la hora de informar con precisión sobre el estado real de tu aplicación.

Resolver errores de configuración de aplicaciones

Los errores de configuración de la aplicación provocan muchos eventos CrashLoopBackOff. Para saber por qué se detiene tu aplicación, el primer paso es examinar su código de salida. Este código determina la ruta de solución de problemas:

  • El código de salida 0 indica que la salida se ha completado correctamente, lo cual es inesperado en un servicio de larga duración y apunta a problemas con el punto de entrada del contenedor o con el diseño de la aplicación.
  • Un código de salida distinto de cero indica que la aplicación ha fallado, por lo que debes centrarte en los errores de configuración, los problemas de dependencias o los errores del código.

Buscar el código de salida

Para encontrar el código de salida de tu aplicación, sigue estos pasos:

  1. Describe el Pod:

    kubectl describe pod POD_NAME -n NAMESPACE_NAME

    Haz los cambios siguientes:

    • POD_NAME: el nombre del pod que tiene problemas.
    • NAMESPACE_NAME: el espacio de nombres del pod.

  2. En el resultado, consulta el campo Exit Code situado en la sección Last State del contenedor correspondiente. Si el código de salida es 0, consulta Solucionar problemas de salidas correctas (código de salida 0). Si el código de salida es un número distinto de 0, consulta Solucionar problemas de fallos de aplicaciones (código de salida distinto de cero).

Solucionar problemas de salidas correctas (código de salida 0)

Un código de salida 0 suele significar que el proceso del contenedor ha finalizado correctamente. Aunque este es el resultado que quieres para un trabajo basado en tareas, puede indicar un problema en un controlador de larga duración, como un Deployment, un StatefulSet o un ReplicaSet.

Estos controladores se encargan de que un pod esté siempre en ejecución, por lo que tratan cualquier salida como un error que debe corregirse. kubelet aplica este comportamiento siguiendo el restartPolicy del pod (que tiene el valor predeterminado Always), lo que reinicia el contenedor incluso después de que se haya cerrado correctamente. Esta acción crea un bucle que, en última instancia, activa el estado CrashLoopBackOff.

Estos son los motivos más habituales por los que se cierra una aplicación correctamente de forma inesperada:

  • El comando del contenedor no inicia un proceso persistente: un contenedor permanece en ejecución solo mientras lo hace su proceso inicial (command o entrypoint). Si este proceso no es un servicio de larga duración, el contenedor se cierra en cuanto se completa el comando. Por ejemplo, un comando como ["/bin/bash"] sale inmediatamente porque no tiene ninguna secuencia de comandos que ejecutar. Para resolver este problema, asegúrese de que el proceso inicial de su contenedor inicie un proceso que se ejecute de forma continua.

  • La aplicación de trabajador se cierra cuando una cola de trabajo está vacía: muchas aplicaciones de trabajador se han diseñado para comprobar si hay alguna tarea en una cola y cerrarse correctamente si la cola está vacía. Para solucionarlo, puedes usar un controlador de trabajo (diseñado para tareas que se ejecutan hasta completarse) o modificar la lógica de la aplicación para que se ejecute como un servicio persistente.

  • La aplicación se cierra debido a que falta una configuración o no es válida: es posible que tu aplicación se cierre inmediatamente si le faltan instrucciones de inicio obligatorias, como argumentos de línea de comandos, variables de entorno o un archivo de configuración crítico.

    Para solucionar este problema, primero inspecciona los registros de tu aplicación para ver si hay mensajes de error específicos relacionados con la carga de la configuración o con parámetros que faltan. A continuación, comprueba lo siguiente:

    • Argumentos o entorno de la aplicación: asegúrate de que todos los argumentos de línea de comandos y las variables de entorno necesarios se transfieran correctamente al contenedor, tal como espera tu aplicación.
    • Presencia del archivo de configuración: confirma que los archivos de configuración necesarios se encuentran en las rutas esperadas del contenedor.
    • Contenido del archivo de configuración: valida el contenido y el formato de los archivos de configuración para detectar errores de sintaxis, campos obligatorios que faltan o valores incorrectos.

    Un ejemplo habitual de este problema es cuando una aplicación está configurada para leer de un archivo montado con un volumen ConfigMap. Si el archivo ConfigMap no está adjunto, está vacío o tiene claves con nombres incorrectos, una aplicación diseñada para cerrarse cuando falta su configuración puede detenerse con un código de salida 0. En estos casos, verifica los siguientes ajustes: - El nombre ConfigMap de la definición de volumen de tu pod coincide con su nombre real. - Las claves de ConfigMap coinciden con lo que tu aplicación espera encontrar como nombres de archivo en el volumen montado.

Solucionar problemas de fallos de aplicaciones (código de salida distinto de cero)

Cuando un contenedor sale con un código distinto de cero, Kubernetes lo reinicia. Si el problema subyacente que ha provocado el error persiste, la aplicación vuelve a fallar y el ciclo se repite hasta llegar al estado CrashLoopBackOff.

El código de salida distinto de cero es una señal clara de que se ha producido un error en la propia aplicación, lo que dirige tus esfuerzos de depuración hacia su funcionamiento interno y su entorno. Los siguientes problemas suelen provocar esta finalización:

  • Errores de configuración: un código de salida distinto de cero suele indicar que hay problemas con la configuración de la aplicación o con el entorno en el que se ejecuta. Comprueba si tu aplicación tiene alguno de estos problemas habituales:

    • Falta el archivo de configuración: es posible que la aplicación no pueda encontrar o acceder a un archivo de configuración obligatorio.
    • Configuración no válida: el archivo de configuración puede contener errores de sintaxis, valores incorrectos o ajustes incompatibles, lo que provoca que la aplicación falle.
    • Problemas de permisos: es posible que la aplicación no tenga los permisos necesarios para leer o escribir el archivo de configuración.
    • Variables de entorno: si las variables de entorno son incorrectas o faltan, la aplicación puede no funcionar correctamente o no iniciarse.
    • entrypoint o command no válidos: puede que el comando especificado en el campo entrypoint o command del contenedor sea incorrecto. Este problema puede ocurrir con imágenes recién implementadas en las que la ruta al ejecutable sea incorrecta o el archivo en sí no esté presente en la imagen del contenedor. Esta configuración incorrecta suele dar como resultado el código de salida 128.

    • Actualizaciones de imágenes no controladas (etiqueta :latest): si las imágenes de tu carga de trabajo usan la etiqueta :latest, es posible que los nuevos pods extraigan una versión actualizada de la imagen que introduzca cambios incompatibles.

      Para garantizar la coherencia y la reproducibilidad, utiliza siempre etiquetas de imagen específicas e inmutables (por ejemplo, v1.2.3) o resúmenes SHA (por ejemplo, sha256:45b23dee08...) en entornos de producción. Esta práctica ayuda a asegurarse de que se extrae exactamente el mismo contenido de imagen cada vez.

  • Problemas de dependencias: tu aplicación puede fallar si no se puede conectar a los otros servicios de los que depende o si no se autentica o no tiene permisos suficientes para acceder a ellos.

    • Servicio externo no disponible: es posible que la aplicación dependa de servicios externos (por ejemplo, bases de datos o APIs) a los que no se pueda acceder debido a problemas de conectividad de red o a interrupciones del servicio. Para solucionar este problema, conéctate al Pod. Para obtener más información, consulta el artículo Depurar pods en ejecución de la documentación de Kubernetes.

      Una vez que te hayas conectado al pod, podrás ejecutar comandos para comprobar el acceso a archivos y bases de datos, o para probar la red. Por ejemplo, puedes usar una herramienta como curl para intentar acceder a la URL de un servicio. Esta acción te ayuda a determinar si un problema se debe a las políticas de red, al DNS o al propio servicio.

    • Errores de autenticación: es posible que la aplicación no pueda autenticarse con servicios externos debido a que las credenciales son incorrectas. Consulta los registros del contenedor para ver si hay mensajes como 401 Unauthorized (credenciales incorrectas) o 403 Forbidden (permisos insuficientes), que suelen indicar que la cuenta de servicio del pod no tiene los roles de gestión de identidades y accesos necesarios para hacer llamadas a servicios externos. Google Cloud

      Si usas la federación de identidades de cargas de trabajo de GKE, verifica que el identificador principal tenga los permisos necesarios para la tarea. Para obtener más información sobre cómo conceder roles de IAM a principales mediante Workload Identity Federation de GKE, consulta Configurar la autorización y los principales. También debes verificar que el uso de recursos del servidor de metadatos de GKE no haya superado sus límites.

    • Tiempos de espera agotados: la aplicación puede experimentar tiempos de espera agotados al esperar respuestas de servicios externos, lo que provoca fallos.

  • Errores específicos de la aplicación: si la configuración y las dependencias externas parecen correctas, el error puede estar en el código de la aplicación. Revisa los registros de la aplicación para comprobar si se han producido estos errores internos habituales:

    • Excepciones no controladas: los registros de la aplicación pueden contener seguimientos de pila o mensajes de error que indiquen excepciones no controladas u otros errores relacionados con el código.
    • Interbloqueos o bloqueos activos: la aplicación puede quedarse bloqueada en un interbloqueo, en el que varios procesos esperan a que se completen entre sí. En este caso, es posible que la aplicación no se cierre, pero deje de responder indefinidamente.
    • Conflictos de puertos: es posible que la aplicación no se inicie si intenta enlazarse a un puerto que ya está en uso por otro proceso.
    • Bibliotecas incompatibles: es posible que la aplicación dependa de bibliotecas o dependencias que falten o que no sean compatibles con el entorno de tiempo de ejecución.

    Para encontrar la causa principal, inspecciona los registros del contenedor en busca de un mensaje de error o un seguimiento de pila específicos. Esta información te ayuda a decidir si debes corregir el código de la aplicación, ajustar los límites de recursos o corregir la configuración del entorno. Para obtener más información sobre los registros, consulta Acerca de los registros de GKE.

Siguientes pasos