Kubernetes Exit Code 143: 8 causas, diagnóstico y soluciones

Cómo diagnosticar el Exit Code 143 en Kubernetes

Diagnosticar el código de salida 143 implica averiguar quién envió SIGTERM y por qué. Como Kubernetes usa esta señal con frecuencia durante la gestión normal de workloads, el código de salida por sí solo no indica una falla.

Comienza con el estado del pod y del contenedor, y luego correlaciona el momento de la terminación con logs, eventos, despliegues, actividad de escalado y operaciones de nodos. Verifica también que la aplicación responda correctamente cuando recibe SIGTERM.

Paso 1: Inspecciona el estado del pod

Comienza revisando el estado actual del pod y su información detallada:

kubectl get pod <pod-name> -n <namespace>
kubectl describe pod <pod-name> -n <namespace>

Busca reinicios de contenedores, condiciones del pod, eventos recientes e información de terminación. kubectl describe pod también puede revelar fallas de sondas, actividad de desalojo, cambios de programación y otros eventos relacionados con el apagado.

Si el pod está gestionado por un Deployment, StatefulSet u otro controlador, identifica también a su propietario. Esto ayuda a determinar si la terminación formó parte de la actividad normal del controlador.

Paso 2: Verifica el código de salida y la razón de terminación del contenedor

Inspecciona el estado de terminación actual y anterior del contenedor. Para un contenedor reiniciado, Kubernetes puede conservar detalles como el código de salida, la razón, la señal y las marcas de tiempo:

kubectl get pod <pod-name> -n <namespace> \
  -o jsonpath='{.status.containerStatuses[*].lastState.terminated}'

Confirma que el código de salida registrado sea 143. Revisa también la razón de terminación y las marcas de tiempo startedAt y finishedAt, que pueden correlacionarse con los eventos de Kubernetes y los logs de la aplicación.

No asumas que el código de salida 143 explica por sí mismo la causa. Te dice que el proceso terminó a causa de SIGTERM, pero no qué operación de Kubernetes o proceso externo inició la terminación.

Paso 3: Revisa los logs actuales y anteriores del contenedor

Revisa los logs de la aplicación alrededor del momento de la terminación:

kubectl logs <pod-name> -n <namespace>

Si el contenedor se reinició, inspecciona los logs de la instancia anterior del contenedor:

kubectl logs <pod-name> -n <namespace> --previous

Busca mensajes de apagado, mensajes de señal recibida, solicitudes inconclusas, errores de conexión y excepciones de la aplicación. Una secuencia limpia —recibir SIGTERM, dejar de aceptar trabajo nuevo, cerrar recursos y salir— normalmente indica una terminación controlada.

Para pods con varios contenedores, especifica el contenedor correspondiente con -c <container-name>.

Paso 4: Inspecciona los eventos de Kubernetes

Los eventos de Kubernetes pueden dar contexto sobre lo que ocurrió inmediatamente antes de la terminación:

kubectl get events -n <namespace> \
  --sort-by=.metadata.creationTimestamp

Busca mensajes relacionados con sondas fallidas, desalojo de pods, reinicios de contenedores, escalado, programación o problemas de nodos. Compara las marcas de tiempo de los eventos con la marca de tiempo de terminación del contenedor.

Los eventos son útiles, pero no constituyen un registro de auditoría completo. Pueden expirar y no toda causa de terminación de un pod genera un evento que explique con claridad por qué se envió SIGTERM.

Paso 5: Revisa la actividad de Deployments y despliegues

Determina si el contenedor se detuvo durante una actualización del Deployment u otro cambio en el workload:

kubectl rollout status deployment/<deployment-name> -n <namespace>
kubectl rollout history deployment/<deployment-name> -n <namespace>

Inspecciona también los ReplicaSets al diagnosticar un Deployment. La aparición de un nuevo ReplicaSet cerca del momento de la terminación es un fuerte indicio de que los pods antiguos estaban siendo reemplazados durante un despliegue.

Si el código de salida 143 ocurre solo cuando se despliegan nuevas versiones de la aplicación, normalmente forma parte del reemplazo normal de pods. La siguiente pregunta es si esos pods se apagaron limpiamente sin perder solicitudes ni trabajo.

Paso 6: Busca eventos de escalado, desalojo o de nodos

Verifica si cambios de réplicas, autoescalado, drenajes de nodos u operaciones de infraestructura coinciden con la terminación. Para workloads que usan un HorizontalPodAutoscaler, inspecciona su estado actual y su comportamiento reciente:

kubectl get hpa -n <namespace>
kubectl describe hpa <hpa-name> -n <namespace>

Inspecciona también el nodo que alojaba el pod:

kubectl describe node <node-name>

Busca apagados de nodos, mantenimiento, condiciones de presión, actividad del autoescalador o eventos relacionados con desalojos. Si muchos pods sin relación entre sí terminan aproximadamente al mismo tiempo, es más probable que se trate de una operación a nivel de nodo o de clúster que de un problema específico de la aplicación.

Paso 7: Determina si la aplicación maneja SIGTERM correctamente

Por último, verifica cómo responde a SIGTERM el proceso principal de la aplicación. Normalmente debería dejar de aceptar trabajo nuevo, completar o cancelar de forma segura las operaciones activas, vaciar los datos necesarios, cerrar las conexiones externas y salir antes de que expire el período de gracia de terminación.

Revisa el período de gracia configurado en el pod:

kubectl get pod <pod-name> -n <namespace> \
  -o jsonpath='{.spec.terminationGracePeriodSeconds}'

Verifica también que las señales realmente lleguen a la aplicación. Los contenedores que lanzan aplicaciones mediante scripts de shell o gestores de procesos mal configurados pueden interferir con el reenvío de señales cuando la aplicación no es el PID 1.

Si el apagado ordenado tarda sistemáticamente más que el período disponible, mejora la ruta de apagado o aumenta terminationGracePeriodSeconds cuando corresponda. Probar la aplicación directamente con SIGTERM puede confirmar que su manejador de señales se ejecuta y sale dentro del tiempo esperado.

Buenas prácticas para prevenir el Exit Code 143 en Kubernetes {#best-practices-to-prevent-kubernetes-exit-code-143}

Estas son algunas formas de prevenir el código de salida 143 al trabajar con Kubernetes.

1. Implementa un manejo ordenado de SIGTERM

Las aplicaciones deberían manejar SIGTERM de forma explícita y comenzar un apagado ordenado cuando llega la señal. Un servicio debería dejar de aceptar trabajo nuevo, terminar o cancelar de forma segura las solicitudes activas, cerrar conexiones, vaciar los datos en búfer y luego salir.

Asegúrate de que la aplicación realmente reciba la señal. Los scripts de shell envolventes y los gestores de procesos pueden impedir que las señales lleguen a la aplicación si no las reenvían correctamente. Usar exec en un script de entrypoint puede reemplazar el shell por el proceso de la aplicación:

exec /app/my-service

Esto convierte a la aplicación en el PID 1 y permite que las señales de terminación del contenedor le lleguen directamente.

2. Configura un terminationGracePeriodSeconds apropiado

Configura terminationGracePeriodSeconds con un valor lo bastante largo para que la aplicación complete su procedimiento normal de apagado. Kubernetes usa 30 segundos por defecto, pero eso puede ser insuficiente para solicitudes de larga duración, trabajos por lotes, consumidores de mensajes o aplicaciones con tareas de limpieza considerables.

Por ejemplo:

spec:
  terminationGracePeriodSeconds: 60

Basa el valor en los tiempos de apagado observados, en lugar de simplemente definir un timeout grande. Las aplicaciones deberían seguir terminando tan rápido como sea práctico, porque un período de gracia innecesariamente largo puede retrasar despliegues, operaciones de escalado y mantenimiento de nodos.

3. Usa un hook preStop cuando se requiera lógica de apagado adicional

Un hook preStop puede ejecutar lógica adicional antes de que el contenedor reciba su señal normal de detención. Es útil cuando el apagado requiere un comando explícito, dar de baja el servicio u otra operación fuera del manejador estándar de SIGTERM de la aplicación.

Por ejemplo:

lifecycle:
  preStop:
    exec:
      command: ["/bin/sh", "-c", "/app/prepare-shutdown.sh"]

Mantén el hook breve y confiable. Su tiempo de ejecución se descuenta del período de gracia de terminación del pod, por lo que un hook preStop lento reduce el tiempo disponible para que la aplicación se apague después de recibir SIGTERM.

4. Haz que los workers en segundo plano se apaguen de forma segura

Los workers en segundo plano necesitan manejo de terminación tanto como los servicios HTTP. Cuando un worker recibe SIGTERM, normalmente debería dejar de tomar trabajos nuevos y, o bien terminar su trabajo actual, o devolver el trabajo inconcluso a la cola usando el mecanismo soportado por el sistema de colas.

Evita salir de inmediato mientras un trabajo está procesado parcialmente. Según el workload, esto puede resultar en trabajo perdido, procesamiento duplicado, actualizaciones incompletas de la base de datos o un estado inconsistente de la aplicación.

Para trabajos de larga duración, asegúrate de que el período de gracia de terminación sea compatible con los tiempos de procesamiento esperados. Cuando los trabajos no puedan terminar de forma confiable dentro de ese período, diséñalos para que se puedan reintentar o reanudar.

5. Monitorea el código de salida 143 en contexto

No generes alertas por cada aparición del código de salida 143. Es esperable durante los despliegues progresivos, la eliminación manual de pods, las operaciones de reducción de escala, los drenajes de nodos y otras actividades rutinarias de Kubernetes.

En su lugar, correlaciona el código de salida 143 con las tasas de reinicio de pods, la actividad de despliegue, los eventos de Kubernetes, las operaciones de nodos, los errores de la aplicación y las solicitudes fallidas. Las terminaciones repetidas por SIGTERM sin una operación conocida del clúster merecen una investigación más profunda.

Monitorear el contexto hace que el código de salida 143 sea útil como señal de diagnóstico. Ayuda a distinguir la actividad saludable del ciclo de vida de las fallas de sondas, los workloads inestables, las terminaciones inesperadas de procesos o los cambios de infraestructura.

Preguntas frecuentes

¿El código de salida 143 de Kubernetes es un error? Normalmente no. El código de salida 143 significa que el proceso principal del contenedor recibió SIGTERM y se detuvo. Kubernetes envía esta señal durante actividades normales como rolling updates, eliminación de pods, reducción de escala y drenajes de nodos, por lo que el código por sí solo no apunta a una falla.

¿Cuál es la diferencia entre el código de salida 143 y el 137? El código de salida 143 es 128 + 15 y significa que el proceso se detuvo tras recibir SIGTERM, lo que le da a la aplicación la oportunidad de apagarse de forma ordenada. El código 137 es 128 + 9 y significa SIGKILL, que no se puede capturar. Puede ocurrir cuando un contenedor no cumple su período de gracia de terminación o es eliminado por quedarse sin memoria.

¿Cuánto espera Kubernetes antes de enviar SIGKILL? El período de gracia de terminación es de 30 segundos por defecto y se configura con terminationGracePeriodSeconds. Un hook preStop se ejecuta dentro de esa misma ventana, por lo que un hook lento le deja a la aplicación menos tiempo para manejar SIGTERM.

¿Cómo averiguo quién envió el SIGTERM? Comienza con kubectl describe pod y el último estado de terminación del contenedor, y luego compara las marcas de tiempo con los eventos de Kubernetes, el historial de despliegues, la actividad del HPA y los eventos de nodos. Si nada en el clúster coincide, revisa los logs de la aplicación y del gestor de procesos, ya que un script, un supervisor o un sidecar también pueden enviar SIGTERM.

¿Debería crear alertas por el código de salida 143? No, no por cada aparición. Crea alertas por patrones, como terminaciones repetidas por SIGTERM sin un despliegue, escalado u operación de nodo conocidos, o terminaciones que coinciden con solicitudes fallidas o tasas de reinicio en aumento.

Mantén tus workloads de Kubernetes estables en cada terminación con PerfectScale

El código de salida 143 suele ser señal de una actividad saludable del ciclo de vida, pero los despliegues frecuentes, las reducciones de escala y los cambios de nodos hacen más difícil distinguir las terminaciones rutinarias de los problemas reales de resiliencia. PerfectScale for Kubernetes de DoiT ofrece una automatización adaptada a los workloads con un enfoque que prioriza la estabilidad, manteniendo la salud de las aplicaciones en el centro de cada recomendación de optimización. Brinda a los equipos de plataforma, SRE y FinOps una vista única de la salud, el rendimiento y el costo del clúster, para que puedan detectar problemas de resiliencia y ajustar el tamaño de los workloads sin monitoreo manual ni reconfiguraciones constantes.

Capacidades clave de PerfectScale for Kubernetes:

• Detección de problemas de resiliencia: Podfit ofrece una vista granular de la salud y los costos del clúster, priorizando las áreas que requieren atención y ayudando a los equipos a identificar rápidamente recursos desaprovechados y problemas de resiliencia.
• Right-sizing con la estabilidad como prioridad: El right-sizing contextual adapta las acciones usando líneas base de rendimiento, patrones de tráfico y criticidad de negocio, de modo que la optimización nunca se logre a costa de la salud de las aplicaciones.
• Optimización autónoma de workloads: Las recomendaciones basadas en datos y los flujos de automatización ajustan el tamaño de los workloads de forma continua, eliminando el ciclo constante de reconfiguración que consume el tiempo de ingeniería.
• Insights de configuración de autoescaladores: Recomendaciones accionables ayudan a mejorar las configuraciones de HPA y KEDA, mientras que Infrafit ayuda a maximizar la efectividad de autoescaladores de nodos como Karpenter.
• Visibilidad del uso de nodos: Infrafit identifica capacidad ociosa en los nodos y recomienda los nodos adecuados para tus workloads, para que el rendimiento y la confiabilidad del clúster se mantengan al máximo nivel.
• Seguimiento de recursos a nivel de contenedor: Monitorea la CPU y la memoria a nivel de contenedor para eliminar la pérdida y definir los recursos según el uso real.
• Guardrails y políticas: Define reglas de optimización por criticidad del workload y tipo de entorno para mantener protegidos los workloads de producción.
• Visibilidad multi-cloud y multi-clúster: Obtén inteligencia basada en datos, aplicación de políticas y acciones de optimización en cualquier cantidad de clústeres y proveedores de nube, incluido el seguimiento del uso de GPU.

¿Todo listo para ejecutar workloads de Kubernetes confiables y rentables? Conoce más sobre PerfectScale for Kubernetes.