El dashboard esta verde. El Deployment tiene todas sus replicas disponibles. Los pods dicen Ready. Y, aun asi, el usuario recibe errores. En ese momento Kubernetes parece estar mintiendo, pero normalmente solo esta respondiendo una pregunta mas pequeña que la que nos interesa.
Una readiness probe dice si un contenedor cumple la comprobacion que nosotros definimos. Si esa comprobacion solo abre un puerto o devuelve una ruta demasiado superficial, puede estar verde mientras una dependencia, una cola o una consulta critica ya esta rota.
Ready para que
Antes de añadir reinicios, leo la probe como si fuera un contrato:
kubectl get deploy api -o yaml
kubectl describe pod -l app=api
kubectl get endpointslices -l kubernetes.io/service-name=api -o wide
Si el pod entra y sale de los EndpointSlices, la probe esta protegiendo al trafico, aunque la aplicacion sufra. Si permanece como endpoint durante el fallo, tal vez la comprobacion no representa la experiencia real del usuario.
Hay una diferencia importante entre estar vivo y estar listo. Una liveness probe que reinicia un proceso porque una base de datos externa esta lenta puede empeorar un incidente: en lugar de esperar a que vuelva la dependencia, introduces arranques y mas carga. Curar un fallo no siempre significa reiniciar lo que lo padece.
Seguir una peticion completa
La depuracion gana calidad cuando ejecutas la misma operacion que falla para el usuario desde distintos puntos: desde fuera del cluster, desde un pod vecino y directamente contra la IP del pod. Si falla solo al pasar por el ingreso, miras esa capa. Si falla incluso directo al pod, la aplicacion o sus dependencias ya estan hablando.
kubectl logs deploy/api --since=10m
kubectl get events --sort-by=.lastTimestamp
kubectl port-forward deploy/api 8080:8080
Los eventos cuentan cambios del cluster; los logs cuentan lo que la aplicacion alcanzo a entender. Ninguno por separado representa al usuario. La leccion practica es escribir probes que midan una capacidad util sin convertir cada dependencia externa en una orden de reinicio.
Un pod verde no es el final del analisis. Es solo una pista: Kubernetes cree que puede recibir trafico. El resto se demuestra recorriendo la solicitud real.
Para continuar: Kubernetes documenta las probes y sus diferencias en Liveness, Readiness and Startup Probes.
Conversacion
Se el primero en comentar