Una sonda de liveness que falla hace que el kubelet reinicie el contenedor, así que es para un proceso atascado que no puede recuperarse solo. Una sonda de readiness que falla saca al pod de los endpoints del Service para que deje de recibir tráfico, pero lo deja en ejecución. Las sondas de startup cubren las aplicaciones que arrancan lento para que un arranque largo no dispare la liveness. La liveness debería comprobar el propio proceso, no sus dependencias.
Por qué lo preguntan los entrevistadores
Es una pregunta pequeña que expone de forma fiable la experiencia real. Cualquiera que haya llevado Kubernetes en serio ha visto una sonda de liveness enganchada a un chequeo de salud profundo tumbar un despliegue entero durante un parpadeo de una dependencia. El entrevistador quiere esa distinción, más conocer las sondas de startup, más entender cómo interactúa la readiness con las actualizaciones progresivas y el apagado ordenado.
Cómo estructurar tu respuesta
- Da la diferencia en una línea: reiniciar frente a sacar del tráfico.
- Explica qué debería comprobar realmente cada sonda.
- Nombra el fallo clásico de una sonda de liveness que mira dependencias.
- Añade las sondas de startup y el vínculo con las actualizaciones progresivas.
Ejemplo de respuesta
La readiness responde a si este pod puede recibir tráfico ahora mismo, y la liveness a si este proceso no tiene salvación. Si falla la readiness, el controlador de endpoints saca el pod del Service, el tráfico para y el pod sigue ejecutándose para poder recuperarse. Si falla la liveness, el kubelet mata y reinicia el contenedor. El error que veo más a menudo es un endpoint de liveness que comprueba la base de datos y la caché. Entonces la base de datos tiene un bandazo de treinta segundos, todas las réplicas fallan la liveness a la vez, el despliegue entero se reinicia y ahora tienes una caché fría y una estampida encima del problema original. Así que la liveness comprueba solo que el proceso responde, y la readiness es donde van las comprobaciones de dependencias, porque perder tráfico temporalmente es recuperable. Para un servicio que tarda noventa segundos en calentarse añado una sonda de startup con un umbral de fallos generoso para que la liveness no empiece hasta que esté arriba. La readiness también gobierna las actualizaciones progresivas, así que me aseguro de que pase a no lista al inicio del apagado, antes de que el proceso deje de aceptar conexiones.
¿Tienes esta entrevista a la vuelta de la esquina? GhostPilot escucha tu llamada en vivo, detecta la pregunta en cuanto la hacen y pone una respuesta estructurada en tu pantalla en tiempo real. Pruébalo en tu próxima entrevista de práctica, o coge un Session Pass de $29, sin suscripción, para la de verdad.
Mira cómo funcionaPreguntas de seguimiento que puedes esperar
- ¿Cómo interactúan las sondas de readiness con el apagado ordenado y los hooks preStop?
- ¿Qué pasa durante una actualización progresiva si la readiness nunca pasa?
- ¿Cuándo usarías una sonda de startup en vez de un retraso inicial largo?
Más preguntas para Ingeniero DevOps
Tu entrevistador hará su propia versión de esta. Pega la descripción real del puesto en el Question Predictor gratuito y obtén las 20 preguntas que ese puesto tiene más probabilidades de hacerte, con lo que cada una busca en realidad.
Predecir mis preguntas