La base de datos PostgreSQL tiene problemas: latencia multiplicada por diez. Los pods API responden en ocho segundos en lugar de doscientos milisegundos. La sonda de actividad HTTP caduca a los tres segundos. Kubernetes reinicia los pods: pérdida de conexiones, caché inactivo, nueva tormenta en la base de datos. El incidente se convierte en una cascada cuando la aplicación podría haberse conformado con ser eliminada temporalmente del balanceador de carga.
Las sondas son el termómetro que utiliza el kubelet para decidir: enviar tráfico, esperar o matar. Mal regulados, convierten el deterioro en desastre. El escenario es común porque los tutoriales copian una única sonda /health para todos los roles y porque la actividad se configura antes de que el equipo comprenda la diferencia con la preparación.
La buena noticia: una sonda bien calibrada cuesta medio día de trabajo. Lo malo: una prueba agresiva puede costar horas de bucle y agravar una falla de la base de datos que podría haberse resuelto por sí sola.
Vividez, preparación, inicio: tres señales distintas
| Sonda | Efecto | Pregunta |
|---|---|---|
| Preparación | Quitar del servicio | "¿Puedo recibir tráfico ahora?" » |
| Vivacidad | Reiniciar el pod | “¿El proceso está muerto sin recuperación? » |
| Inicio | Bloquea a otros al inicio | “¿Ha terminado de iniciarse la aplicación?” » |
Error clásico: solo una URL /health para los tres roles. Bajo carga, la preparación falla y la vitalidad mata: doble castigo. La preparación debería eliminar el pod del tráfico cuando una dependencia es lenta; La vitalidad sólo debería intervenir si el proceso está realmente estancado, no sólo si es lento.
Reiniciar un pod lento no acelera una base de datos saturada: agrega caos.
Para una implementación sin actividad inicial, la preparación más las alertas de Prometheus suelen ser suficientes. Agregue vivacidad cuando distinga claramente “lento pero vivo” de “muerto sin recuperación”.
Calibrar tiempos de espera, período y umbral de falla
Tres parámetros determinan la agresividad:
- timeoutSeconds debe exceder el percentil 99 bajo carga normal, no bajo carga ideal de laboratorio.
- periodSeconds establece la frecuencia de las comprobaciones; demasiado agresivo multiplica la carga incidente.
- failureThreshold × período = retraso antes de la acción; tres fallas cada diez segundos dejan treinta segundos antes del reinicio.
Ejemplo: si su interfaz responde en 400 ms en el percentil 99 bajo carga normal, un tiempo de espera de tres segundos deja un margen cómodo. Si la base se ralentiza y el percentil 99 aumenta a seis segundos, la preparación falla, pero la vitalidad no debería matar mientras el proceso siga respondiendo.
Estado de los endpoints: separados en vivo y listos
Controles separados en su aplicación:
- /health/live: el proceso responde, sin llamadas de base intensas.
- /health/ready: base de datos accesible, caché activa, migraciones completadas.
No pongas una costosa llamada base en vida. Si PostgreSQL no está disponible, todos los pods no deberían entrar en crashloop; la preparación es suficiente para eliminarlos del Servicio durante la interrupción.
Configure una startupProbe con treinta fallas cada diez segundos si el arranque excede los treinta segundos: esto deja cinco minutos de inicio sin actividad no deseada. Esencial para aplicaciones Java, migraciones de inicio o carga de una caché grande.
Sondas y Kubernetes gestionados en Europa
En Kubernetes administrado por OVHcloud, Scaleway Kapsule u otras ofertas europeas, el plano de control gestiona las sondas en el lado de kubelet; su responsabilidad sigue siendo el contenido del control y su carga.
Puntos de vigilancia:
- Contenedores laterales que añaden latencia de inicio;
- Límites bajos del procesador que provocan tiempos de espera bajo carga;
- Confusión entre el control del distribuidor de carga externo y la sonda pod: dos mecanismos distintos.
Compare las ofertas de Kubernetes a través del directorio y la comparación. Si está implementando en un clúster pequeño, consulte también Kubernetes: ¿Realmente lo necesita? antes de agregar complejidad de sondeo a una pila de gran tamaño.
Observabilidad: correlacionar reinicios y sondeos
Métricas de incidentes útiles:
- Reiniciar el contador por implementación;
- Eventos "no saludables" en "kubectl describe pod";
- Kubelet registra al momento del reinicio.
Runbook recomendado: si es crashloop: deshabilite temporalmente la actividad después de confirmar que el proceso no es zombie; corregir la causa raíz (base lenta, piscina agotada); reactivar con umbrales relajados. Nunca deshabilite la vida en producción sin una alerta paralela de disponibilidad.
La correlación de reinicios y latencia base en producción a menudo revela una prueba demasiado agresiva, no un error de la aplicación. Consulte Métricas de Prometheus para instrumentar el percentil 99 antes de establecer tiempos de espera.
La cumbre: reiniciar como un reflejo perezoso
Una sonda útil elimina el tráfico. Se reinicia una sonda diferida y espera que el problema desaparezca. La diferencia está en la separación vivo/listo, los tiempos de espera calibrados en mediciones reales y la disciplina de no copiar una configuración encontrada en un foro sin adaptarla a su carga.
Decide y avanza sin puntos ciegos
Durante media jornada, podrás volver a poner las sondas al servicio de la estabilidad:
- Implemente puntos finales separados en vivo y listos: en vivo sin llamada base, listo con dependencias críticas.
- Configure una startupProbe si el arranque excede los treinta segundos; sin él, liveness cerrará la aplicación antes de que se complete el inicio.
- Establezca tiempos de espera desde el percentil 99 medido bajo carga normal; no es un valor predeterminado del tutorial.
- Prueba en preproducción con saturación de base simulada: los pods deben pasar NotReady, no CrashLoopBackOff.
- Correlacionar reinicios y latencia base en producción; ajuste el umbral de falla antes de agregar réplicas.
- Compare las ofertas de Kubernetes a través del directorio si está migrando a un clúster administrado europeo.
Preguntas frecuentes
¿Cuál es la diferencia entre vivacidad y preparación?
La preparación elimina el pod del servicio sin eliminarlo, lo que resulta adecuado cuando una dependencia no está disponible temporalmente. Liveness reinicia el contenedor; resérvelo para bloqueos irrecuperables. Confundir los dos provoca reinicios innecesarios durante la degradación temporal.
¿Por qué mi vida provoca un crashloop?
Tiempos de espera demasiado cortos, punto final lento bajo carga o control pasando por la misma base de datos saturada. El kubelet mata la cápsula mientras la preparación sería suficiente. Relaje los umbrales o mueva el control de línea base solo a preparación.
¿Para qué se utiliza startupProbe?
Retrasa la vida y la preparación durante un arranque prolongado: migraciones, caché, conexiones remotas. Sin él, la actividad finaliza la aplicación antes de que se complete el inicio. Configúrelo tan pronto como un pod tarde más de treinta segundos en estar operativo.
¿HTTP o ejecutivo para una sonda?
Es preferible HTTP en un punto final de aplicación ligero. Los sockets Exec o TCP apenas verifican el estado del negocio; resérvelos como último recurso cuando HTTP no esté disponible.
Una sonda útil reduce el tráfico; una sonda diferida se reinicia y espera que el problema desaparezca.