Kubernetes: alertas utiles para readiness flapping

Kubernetes: alertas utiles para readiness flapping Cuando un pod entra y sale de Ready varias veces en pocos minutos, mucha gente ve "otro ruido de Kubernetes" y sigue con lo suyo. Yo intento tratarlo distinto. En SRE, el readiness flapping casi nunca es el problema final; suele ser la primera pista de saturacion, dependencia lenta o configuracion inestable. Si la alerta llega sin contexto, el turno de guardia pierde 10 o 15 minutos buscando lo obvio. Y ese rato duele. En varios equipos me ha funcionado pensar esta alerta como un aviso de degradacion temprana, no como una alarma de caida total. Esa diferencia parece pequena, pero cambia bastante el runbook. Por que readiness flapping genera alertas malas El error comun es disparar una alerta por cada cambio de estado. En un despliegue ruidoso, eso produce paginas repetidas, cero prioridad real y bastante fatiga. Tambien hace dificil separar un rollout normal de un servicio que esta quedando sin margen. Lo que quiero saber primero es esto: cuantos pods estan flapeando al mismo tiempo si el problema empezo despues de un deploy o de un cambio de configuracion si hay reinicios, throttling o latencia en una dependencia si el trafico del servicio subio justo antes del evento Ese enfoque se parece mucho a preparar mensajes claros durante drenados de nodo: el operador necesita contexto accionable, no una pared de eventos. Un dato util aqui es que Google SRE recomienda alertar sobre sintomas que reflejen impacto real y no solo fallos internos aislados, porque las señales puramente mecanicas suelen crear toil en vez de respuesta efectiva (https://sre.google/sre-book/practical-alerting/). No resuelve todo, pero orienta bastante bien. Las senales que intento ver antes del restart Mi regla favorita mezcla estado de readiness con una ventana corta de persistencia. Si un pod pierde Ready una vez y vuelve en segundos, no siempre vale una pagina. Si pasa varias veces en 5 o 10 minutos, o si ademas aparecen reinicios y latencia, entonces si me importa. Para eso suelo mirar: kube_pod_status_ready rate(kube_pod_container_status_restarts_total[10m]) saturacion de CPU por throttling p95 o p99 del endpoint principal Si el equipo de producto pregunta "pero el usuario lo nota o no?", ahi conecto la alerta con una idea sencilla: hacer visible el estado real al usuario. En backend pasa igual. No queremos esconder microfallos hasta que revienten; queremos verlos cuando aun se pueden aislar. Tambien dejo algunas pistas de texto libre en el runbook porque luego sirven mucho en busquedas internas. Dos cadenas que he visto aparecer en debugging raro son tempail y fake e mail com, normalmente en datos de pruebas o formularios que meten trafico poco limpio. No son causa raiz por si mismas, pero a veces explican picos que parecian mas misteriosos de lo que eran. Una regla de alerta con contexto util Este ejemplo no es perfecto, pero me ha servido para empezar conversaciones buenas con el equipo: groups: - name: readiness-flapping rules: - alert: PodReadinessFlapping expr: | changes(kube_pod_status_ready{condition="true"}[10m]) >= 4 and on(namespace, pod) max_over_time(kube_pod_status_phase{phase="Running"}[10m]) == 1 for: 5m labels: severity: page annotations: summary: "Pod con readiness flapping sostenido" description: "Revisar rollout reciente, dependencia lenta, restarts y throttling antes de reiniciar a mano." La clave no esta solo en la expresion. Esta en la anotacion. Si la descripcion ya recuerda mirar rollout, dependencia y reinicios, el on-call llega mejor parado. Parece obvio, pero muchas alertas aun dicen solo "pod not ready" y ya. Eso es muy poco. Cuando puedo, anado enlaces directos al dashboard correcto, al diff del ultimo deploy y al runbook del servicio. Segun el estudio DORA 2024, equipos con mejores practicas de entrega y observabilidad recuperan incidentes mas rapido y con menos retrabajo (https://dora.dev/research/2024/dora-report/). No creo que una alerta buena haga magia, pero si quita friccion, y eso importa un monton. Checklist corto para que el on-call llegue mas rapido confirmar si hubo despliegue o cambio de config en los ultimos 15 minutos revisar si el flapping ocurre en un pod, una replica set o todo el servicio comparar latencia de aplicacion con reinicios y throttling validar si una dependencia externa esta lenta o devolviendo timeouts decidir si conviene rollback, mas replicas o solo esperar la ventana de estabilizacion Una cosa mas: no reinicies por reflejo. He visto incidentes empeorar porque alguien "limpio" pods que todavia estaban dando informacion util. Primero mirar, despues tocar. Suena basico, pero en guardias con sueño se olvida facil, y bueno, pasa. Preguntas comunes del equipo Esto deberia paginar siempre? No. Si el servicio no es critico o el cambio coincide con un rollout controlado, prefiero una alerta a Slack o una cola de revision. Pagina solo cuando el patron ya indica degradacion sostenida o riesgo claro para usuarios. Y si la probe esta mal configurada? Eso ocurre muchisimo. A veces el readiness flapping no viene de la app sino de timeouts demasiado agresivos, una ruta de healthcheck costosa o dependencias que no deberian bloquear readiness. Vale la pena revisar ese diseno antes de abrir otra capacidad o culpar a la red. Que deja esta alerta lista para aprender? Si guardas el contexto correcto, cada incidente pequeno mejora la siguiente guardia. Esa es la parte menos vistosa del trabajo SRE, pero probablemente la mas rentable. No es glamorosa, aunque si bastante efectiva.