Sondas de Kubernetes: cuándo esperar, enrutar tráfico o reiniciar

Un proceso de API hipotético está en ejecución, pero la inicialización aún no ha terminado. Más tarde, su base de datos deja de estar disponible. Otro día, un interbloqueo local impide que se completen las solicitudes. Cada situación podría provocar el fallo de una comprobación de estado. No deberían provocar automáticamente la misma respuesta.

Decide qué ayudaría. ¿Permitir más tiempo para el arranque? ¿Retirar esta instancia del tráfico? ¿Reiniciar su contenedor? Kubernetes asigna una semántica de sondas distinta a cada opción, como explica la documentación oficial sobre sondas.

Un buen diseño de sondas empieza por justificar la recuperación. Esta guía abarca una aplicación HTTP convencional en un Deployment detrás de un Service normal. El acceso directo a los Pods, los procesos de trabajo, las configuraciones especializadas de Service y el enrutamiento personalizado requieren un análisis aparte. La configuración es ilustrativa y no se ha ejecutado.

Sondas de preparación, vitalidad y arranque de Kubernetes: tres decisiones distintas

La sonda determina qué hace Kubernetes con la señal del endpoint. Revisa el comportamiento de las sondas de Kubernetes antes de elegir la comprobación.

El arranque protege la inicialización

Una sonda de arranque pospone las comprobaciones de vitalidad y preparación hasta que se completa correctamente. Así, la inicialización dispone de su propio margen sin debilitar las comprobaciones posteriores. Sigue existiendo un límite: los fallos repetidos de arranque terminan el contenedor. La guía de configuración del arranque describe esta espera acotada.

La preparación controla la admisión de tráfico

El fallo de preparación no reinicia nada por sí mismo. Cambia el estado de preparación y la admisión de tráfico de los Services que seleccionan el Pod. La preparación del Pod también requiere que los demás contenedores y las condiciones adicionales de preparación configuradas estén listos, como explica la documentación sobre el ciclo de vida de los Pods. El trabajo en segundo plano no se detiene solo porque la instancia deje de estar preparada, y una comprobación fallida no demuestra que todas las rutas sean inutilizables. Consulta la documentación sobre sondas para conocer la consecuencia sobre el Service; el cierre necesita un contrato aparte.

La vitalidad evalúa si reiniciar puede ayudar

Al alcanzar su umbral de fallo, la sonda de vitalidad provoca la terminación del contenedor concreto, no la sustitución del Pod entero. La política de reinicio determina lo que ocurre después, incluido el intervalo de espera entre reinicios descrito en la documentación sobre el ciclo de vida de los Pods. Un proceso en ejecución puede estar bloqueado. Un proceso que espera a un servicio externo no disponible puede no tener ningún problema local.

El marco Esperar, Enrutar, Reiniciar para decidir sobre las sondas

Esperar, Enrutar, Reiniciar es una ayuda editorial original de Optijara para la toma de decisiones, no una función de Kubernetes, un estándar del sector ni un método verificado con clientes. Úsalo para revisar la justificación de la recuperación antes de implementar una comprobación de estado.

Asocia el fallo con una acción

Todos los escenarios siguientes son hipotéticos. Comprueba las condiciones de aceptación con la carga de trabajo real.

Las dependencias compartidas complican la decisión de enrutamiento. Si todas las réplicas comprueban el mismo backend no disponible, retirar una instancia puede acabar retirándolas todas. El análisis práctico de Colin Breck examina este problema de los dominios de fallo. Reiniciar las réplicas no puede, por sí solo, reparar su dependencia compartida.

Registra la evidencia y quién es responsable de la recuperación

Anota junto a la configuración qué sigue siendo útil, qué cambiaría un reinicio y quién es responsable de la recuperación. Este JSON es un registro de planificación, no una política ejecutable.

{
  "framework": "wait-route-restart",
  "wait": "bounded-initialization-allowance",
  "route": "scoped-request-usefulness",
  "restart": "tested-local-recovery-mechanism",
  "acceptance": "observed-state-and-real-requests"
}

Omitir la sonda de vitalidad puede ser razonable cuando no existe una señal que justifique el reinicio. Kubernetes documenta esa opción. La objeción merece la misma atención: retirar una instancia del tráfico por falta de preparación puede dejarla bloqueada y no disponible indefinidamente. El análisis de Breck muestra por qué ese diseño sigue necesitando a alguien o algo responsable de restablecer el progreso.

Comprobaciones de dependencias para la preparación sin retirar capacidad útil

Separa las dependencias esenciales de las funciones opcionales

La guía oficial permite comprobar dependencias indispensables del backend en las sondas de preparación. Henning Jacobs advierte sobre las comprobaciones de dependencias compartidas, mientras que Breck examina solicitudes con distintas dependencias. Pregúntate qué consigue retirar la instancia del tráfico.

Considera una API hipotética que necesita su base de datos para cada solicitud autorizada. Marcar la instancia como no preparada podría describir con precisión su capacidad. En otra API hipotética, las rutas de lectura funcionan pese a una interrupción de la telemetría. Retirarla del tráfico descartaría capacidad útil. El funcionamiento degradado debe seguir respetando la autorización y otros requisitos de seguridad.

Cuando las rutas dependen de distintos servicios, considera gestionar los fallos por ruta o separar las cargas de trabajo con contratos de preparación distintos. El límite del fallo debe justificar el esfuerzo adicional de despliegue y mantenimiento.

Acota las comprobaciones y conserva el funcionamiento degradado

Establece límites de tiempo para las comprobaciones de dependencias y especifica qué ocurre si se agota el tiempo. El estado de salud almacenado en caché necesita una antigüedad máxima y una regla para resultados desconocidos o desactualizados. Una comprobación correcta de ayer no demuestra que el servicio pueda aceptar solicitudes ahora.

La preparación puede oscilar. Kubernetes ofrece umbrales de éxitos y fallos consecutivos, cuya semántica se detalla en la guía de configuración. Elige esos umbrales según el comportamiento observado. Cualquier mecanismo adicional en el código de la aplicación para suavizar las oscilaciones también necesita pruebas.

No incluyas los fallos de dependencias en la comprobación de vitalidad, salvo que las pruebas expliquen cómo los repara un reinicio local. Los artículos de profesionales incluyen ejemplos históricos de controladores; valida el recorrido de entrada del tráfico instalado en lugar de asumir que esos ejemplos describen su comportamiento actual.

Una configuración ilustrativa de sondas HTTP y un contrato de endpoints

Asigna significados distintos al arranque, la preparación y la vitalidad

Este fragmento se incluye en la especificación de un contenedor. No es un Deployment completo y ejecutable. Supone que una aplicación escucha en el puerto 8080 con los endpoints indicados. Los valores de tiempo son ejemplos sin evaluación de rendimiento, no recomendaciones de ajuste.

ports:
  - name: http
    containerPort: 8080
startupProbe:
  httpGet:
    path: /startupz
    port: http
  periodSeconds: 5
  timeoutSeconds: 2
  failureThreshold: 24
  successThreshold: 1
readinessProbe:
  httpGet:
    path: /readyz
    port: http
  periodSeconds: 5
  timeoutSeconds: 2
  failureThreshold: 3
  successThreshold: 2
livenessProbe:
  httpGet:
    path: /livez
    port: http
  periodSeconds: 10
  timeoutSeconds: 2
  failureThreshold: 3
  successThreshold: 1

Según este contrato propuesto, /startupz informa de que la inicialización ha terminado. /readyz informa de si la instancia debería recibir el tráfico definido en su ámbito. /livez detecta una condición local que un reinicio puede resolver. Las rutas separadas facilitan la revisión de este ejemplo; Kubernetes no exige URLs separadas.

Las sondas HTTP comprueban el código de estado de la respuesta, no el éxito de una operación de negocio. La guía oficial de configuración define como correctos los códigos de estado del 200 al 399. La gestión de redirecciones tiene excepciones que conviene examinar: kubelet sigue las redirecciones al mismo host, pero una redirección a un host distinto o 11 o más redirecciones se consideran un éxito con un evento ProbeWarning. Da preferencia a una respuesta de estado explícita frente a una redirección al inicio de sesión. Mantén pequeños los cuerpos de respuesta y excluye secretos o detalles sensibles de las dependencias.

Elige los tiempos según la evidencia de la carga de trabajo

periodSeconds establece la frecuencia de la sonda. timeoutSeconds acota cada comprobación. failureThreshold cuenta los fallos consecutivos, mientras que successThreshold cuenta los éxitos consecutivos después de un fallo. Este último debe ser 1 para las sondas de arranque y vitalidad. La sonda de preparación puede ejecutarse con mayor frecuencia mientras el contenedor no esté preparado. Esta es la semántica documentada de los campos, no una receta de ajuste.

Mide la inicialización en las condiciones de arranque que pretendes admitir, incluidos los arranques en frío pertinentes. Revisa también el período de gracia para la terminación. Kubelet respeta el período de gracia aplicable durante la terminación provocada por una sonda; el período de gracia por sonda está disponible para el arranque y la vitalidad, no para la preparación. Consulta la documentación sobre sondas.

Multiplicar los umbrales no produce un plazo exacto de recuperación. La planificación de ejecución, los tiempos de espera, el cierre, los intervalos entre reinicios y la inicialización también afectan al tiempo transcurrido. Una guía ejecutable necesitaría un entorno de prueba completo con versiones fijadas y resultados de ejecución conservados. Este fragmento no se ha ejecutado en un clúster.

Un procedimiento en preproducción: probar fallos, examinar la evidencia y desplegar

Registra la situación inicial y prueba un fallo cada vez

Estas son pruebas propuestas, no resultados experimentales. Antes de la primera prueba:

1. Documenta el comportamiento de los endpoints, los valores predeterminados de las comprobaciones de estado del framework y los supuestos de enrutamiento.
2. Guarda la configuración actual de las sondas y la evidencia inicial de solicitudes, preparación y reinicios.
3. Asigna a cada fallo una acción esperada y un responsable de recuperación.
4. Provoca un fallo cada vez en una carga de trabajo aislada de preproducción.
5. Compara las observaciones con el contrato antes de aprobar un despliegue acotado.
6. Conserva la configuración revisada de la aplicación y el procedimiento para revertir el despliegue.

Usa una aplicación desechable para provocar bloqueos deliberados. No introduzcas interbloqueos en servicios de producción compartidos.

Comprueba tanto el estado de Kubernetes como las solicitudes reales

Lee las condiciones de los Pods y los recuentos de reinicios de los contenedores. Examina los eventos y los registros del contenedor anterior cuando estén disponibles, y correlaciona después la preparación de los EndpointSlices del Service correspondiente con solicitudes a través del Service o del punto de entrada previstos. La documentación sobre sondas y la documentación sobre el ciclo de vida explican las transiciones de estado. La aceptación de una configuración demuestra poco sobre la recuperación por sí sola.

Los cambios de EndpointSlice llegan a los mecanismos de seguimiento y a las cachés de los clientes en distintos momentos, como explica la documentación oficial sobre EndpointSlice. También documenta una excepción: publishNotReadyAddresses hace que ready sea verdadero para el endpoint independientemente de la preparación del Pod. Esta guía supone que esa opción está desactivada. Prueba el recorrido de enrutamiento instalado y las solicitudes de larga duración; no asumas que todos los controladores detienen inmediatamente el nuevo tráfico ni que un fallo de preparación cierra las conexiones establecidas.

Para los servicios de inferencia, compara la evidencia de las sondas con la observabilidad de la inferencia de IA. Un proceso en buen estado no demuestra la latencia de respuesta, el éxito de las solicitudes ni la calidad de los resultados. El procedimiento de trazado de OpenTelemetry GenAI aporta contexto para las llamadas a modelos y herramientas. Complementa las pruebas de sondas.

Mide la recuperación, no solo los indicadores en verde.

Define la recuperación y la reversión antes de pasar a producción

Rechaza el cambio si se retiran réplicas no relacionadas, aumentan los reinicios sin recuperación, fallan rutas útiles o la recuperación sigue sin explicación. Establece criterios de aceptación para la carga de trabajo en lugar de adoptar umbrales universales de latencia o disponibilidad.

La reversión debe restablecer el contrato de endpoints revisado y la configuración de sondas mediante el proceso de despliegue habitual. Comprueba después la preparación, el comportamiento de reinicio y las solicitudes reales. Que un comando de despliegue termine correctamente no demuestra la recuperación.

En qué se equivocan los equipos y qué no pueden garantizar las sondas

Evita señales de fallo compartidas y reinicios injustificados

Las comprobaciones idénticas merecen revisión cuando las consecuencias de sus fallos son distintas. Otros errores incluyen comprobar un puerto de administración que revela poco sobre el flujo que atiende las solicitudes, o establecer umbrales agresivos sin medir el arranque. Jacobs analiza los puntos ciegos del puerto de administración y los riesgos de reinicio.

Insistir en URLs distintas tampoco sirve como regla absoluta. Kubernetes describe diseños con un endpoint compartido y umbrales distintos. Revisa la señal y su consecuencia. El nombre del endpoint no puede determinar si un reinicio ayudará.

Trata por separado las interrupciones, el cierre y el trabajo duradero

Un PodDisruptionBudget limita las operaciones de desalojo voluntario admitidas. No coordina los reinicios de contenedores provocados por sondas de vitalidad ni garantiza un nivel mínimo de disponibilidad. La documentación oficial sobre interrupciones define su alcance. La discusión histórica de la comunidad ayuda a explicar la confusión; no es una especificación actual.

Retirar una instancia del tráfico por falta de preparación no proporciona terminación ordenada, drenaje de conexiones ni cierre de procesos de trabajo. La documentación sobre el ciclo de vida de los Pods aborda la terminación por separado. Estas responsabilidades necesitan diseños y pruebas explícitos.

Reiniciar un contenedor tampoco establece el estado de referencia de los trabajos ni elimina las escrituras externas duplicadas. Para las cargas de trabajo de agentes, revisa el estado duradero y la recuperación de los flujos de trabajo junto con el estado del contenedor.

Las sondas observan las señales que has elegido. No pueden demostrar la corrección completa de la aplicación, su seguridad ni la calidad de la inferencia. Los manejadores de comprobaciones de estado también consumen recursos, y el estado almacenado en caché puede quedar desactualizado. La guía operativa debe explicar estos límites y cómo reconocer la recuperación.