Kubernetes: alertas de rollback con contexto real

Cuando un rollout falla en Kubernetes, casi siempre sobra ruido y falta contexto. Llega una alerta, alguien mira el canal, y en menos de cinco minutos ya hay tres hipotesis distintas. Ese momento decide si el rollback sera una respuesta limpia o una reaccion apurada.

Con el tiempo aprendi que la alerta de rollback no debe limitarse a decir "deployment failed". Tiene que explicar que release se rompio, en que namespace, que cambio la precedio y que senal concreta empujo la reversion. Si no trae eso, el equipo termina haciendo arqueologia operativa cuando deberia estar corrigiendo.

Por que un rollback alerta tarde y mal

El patron que veo seguido es este:

• el sistema alerta por disponibilidad, pero no por progreso del rollout
• el mensaje no incluye deployment, revision ni namespace
• el runbook vive en otro sitio y nadie lo abre en el minuto importante
• varias releases comparten el mismo canal y todo parece medio igual

Ese ultimo punto duele mas de lo que parece. He visto equipos revisar un inbox de tempail o una cuenta de fake e mail com para verificar avisos de deploy, pero eso solo mueve el problema. El fallo real es no tener una alerta que actue como recibo operativo del cambio.

Por eso me gusta copiar ideas de flujos mas controlados, como validar correos antes de tocar produccion. La leccion no es sobre frontend; es sobre contratos. Si la senal importa, hay que definir que evidencia minima debe traer.

La evidencia minima que debe traer la alerta

Para un equipo de SRE, una buena alerta de rollback deberia incluir al menos:

• nombre del Deployment o StatefulSet
• namespace y cluster
• revision previa y revision candidata
• imagen o digest desplegado
• razon del fallo, por ejemplo ProgressDeadlineExceeded
• ventana de tiempo entre inicio de rollout y error
• enlace al job, commit o cambio de configuracion

No hace falta escribir una novela. Hace falta escribir el mensaje correcto. Si la alerta muestra "fallo rollout api-prod" pero no indica que imagen quedo viva o cual empezo a fallar, el on-call todavia tiene que reconstruir la historia a mano. Y eso retrasa todo, aveces por detalles tontos.

Tambien sirve separar la evidencia de usuario y la evidencia tecnica. Si tu proceso revisa notificaciones externas, un servicio de correo temporal desechable puede ayudar a aislar pruebas de mensajes automaticos sin mezclar bandejas reales, pero la verdad del rollback debe seguir saliendo del cluster, los eventos y el pipeline. No del inbox.

Senales que reviso antes de revertir

Antes de lanzar rollout undo, reviso estas senales en este orden:

1. kubectl rollout status para confirmar si el despliegue sigue progresando o ya esta claramente atascado.
2. kubectl describe deployment para leer eventos recientes y ver si el problema fue imagen, probes o capacidad.
3. logs de la aplicacion nueva, solo si el pod alcanza a levantar algo util.
4. metrica de error y latencia de los ultimos minutos, para no revertir por una alarma enganosa.

Ese paso de contexto previo importa mucho. A veces el cambio no necesita rollback sino unos minutos mas porque un initContainer pesado va lento. Otras veces la reversion si es correcta, pero hay que evitar que el mismo pipeline redeploye la revision mala cinco minutos despues. Es un detalle pequeno, pero se olvida seguido.

Si tu equipo ya hace pruebas de correo en entornos reales, aplica la misma disciplina aqui: aislar senales, correlacionarlas con una sola ejecucion y dejar rastro claro para el siguiente turno.

Un ejemplo pequeno con kubectl

Este bloque me sigue pareciendo suficiente para capturar contexto rapido:

DEPLOYMENT=api
NAMESPACE=prod

kubectl rollout status deployment/$DEPLOYMENT -n $NAMESPACE --timeout=90s
kubectl describe deployment/$DEPLOYMENT -n $NAMESPACE
kubectl get rs -n $NAMESPACE --sort-by=.metadata.creationTimestamp | tail -n 3
kubectl rollout undo deployment/$DEPLOYMENT -n $NAMESPACE

Lo importante no es el comando en si. Lo importante es que la alerta y el runbook usen los mismos nombres, la misma revision y el mismo destino. Cuando cada parte llama distinto al mismo deploy, el equipo pierde segundos muy caros y empieza a dudar de cosas basicas, y eso nunca ayuda.

Errores comunes que vuelven ruidoso el rollback

Estos son los tropiezos mas repetidos:

• alertar por pod reiniciado sin relacionarlo con una release concreta
• no guardar la revision previa que se considera estable
• lanzar rollback automatico sin freno cuando el fallo viene de una dependencia externa
• mezclar staging y produccion en la misma plantilla de alerta
• asumir que "rollback successful" significa "servicio sano"

El ultimo error es el mas peligroso. Un rollback puede completar y aun asi dejar conexiones rotas, caches viejas o jobs duplicados. La alerta final deberia confirmar recuperacion basica, no solo que Kubernetes acepto el comando. Parece obvio, pero no siempre se hace bien.

Q&A

Cuando automatizo el rollback?

Solo cuando el patron de fallo esta muy bien entendido y la comprobacion posterior es confiable. Si no, prefiero sugerencia automatica con aprobacion humana.

Que dato falta mas seguido en las alertas?

La revision exacta que estaba estable antes del cambio. Sin eso, el equipo sabe que algo fallo pero no sabe hacia donde volver con confianza.

Conviene poner todo en la alerta?

No. Conviene poner el contexto minimo y un enlace claro al detalle. Una alerta gigante nadie la lee completa bajo presion, y eso termina siendo peor.