Drenados de nodo sin alertas confusas

En varios equipos de SRE he visto el mismo problema durante una ventana de mantenimiento: el drenado de un nodo sale bien, pero los correos y alertas que llegan alrededor del cambio meten mas ruido que ayuda. Al final no discutes el kubectl drain, discutes si hubo una caída real, si fue un falso positivo o si alguien lanzó el cambio sin avisar.

El fallo no suele estar en Kubernetes. Casi siempre está en el contexto que no viaja con la alerta. Cuando ese contexto falta, una tarea rutinaria parece incidente. Y cuando te toca revisarlo rapido desde el móvil, peor todavia.

Por qué un node drain genera correos tan malos

Un node drain toca varias piezas al mismo tiempo:

• pods desalojados
• readiness cambiando
• alertas de capacidad
• reprogramación en otros nodos
• mensajes de CI o de la plataforma

Si todas esas señales terminan en el mismo canal con asuntos parecidos, el equipo recibe una historia rota. Ves "pod reiniciado", "latencia alta" y "nodo no disponible", pero no ves que todo forma parte de una misma operacion prevista.

No es raro ver a alguien abrir un incidente antes de tiempo por eso. Tambien he visto el extremo contrario: una alerta real queda medio escondida porque el canal ya venía cargado de ruido por mantenimiento planificado. Ninguna de las dos cosas esta bien.

La causa real suele ser falta de contexto

Lo que mejor me ha funcionado es pensar cada correo operativo como una mini ficha de cambio. No necesita ser largo, pero sí responder cuatro preguntas enseguida:

1. ¿Qué nodo o grupo de nodos se está drenando?
2. ¿Cuál es la razón del cambio?
3. ¿Qué ventana o runbook aplica?
4. ¿Qué síntomas son esperables y cuáles no?

Cuando esas respuestas están presentes, el equipo deja de adivinar. Cuando no están, aparece el clásico "creo que esto era esperado, pero no estoy seguro". Ese tipo de frase frena decisiones y te deja medio ciego justo cuando necesitas leer la situación en segundos.

Algo parecido pasa cuando necesitas validar correos despues de un rollback: el evento técnico puede ser correcto, pero si el mensaje no explica el contexto del cambio, la revisión se vuelve lenta y un poco torpe.

Qué datos deben viajar en cada alerta

Yo intento que cada notificación relacionada con el drenado incluya, como mínimo, esto:

• identificador del nodo
• clúster y entorno
• inicio del mantenimiento
• persona o automatización que disparó la acción
• lista breve de impactos esperados
• condición de escalado si algo sale mal

Si usas plantillas, una versión simple podría verse así:

[mantenimiento] drain iniciado en ip-10-0-24-18
cluster: prod-eu1
motivo: parcheo del nodo
impacto esperado: reprogramación de pods y 1-2 reinicios controlados
escalar si: hay pods en Pending > 10 min o errores 5xx sostenidos
runbook: node-drain-07

Eso no elimina el ruido por completo, pero lo vuelve interpretable. También reduce mensajes innecesarios de seguimiento, que es donde a veces se pierde tiempo demasido facil.

Una forma simple de probarlo antes del mantenimiento

Antes de una ventana importante, me gusta probar las notificaciones con un ejercicio muy corto:

1. simular el evento en staging o en un clúster pequeño
2. disparar exactamente los correos o webhooks que saldrían en producción
3. revisar si alguien que no participó en la preparación entiende el mensaje en menos de un minuto

Ese tercer punto importa mucho. La persona que escribió la plantilla ya sabe el contexto; quien recibe el correo no. Por eso conviene aislar pruebas de emails transaccionales y mirar el resultado como si fueras el on-call de turno, no el autor del sistema.

En algunos entornos también uso buzones de prueba o un flujo de correo desechable para comprobar asunto, formato y deduplicación sin ensuciar bandejas personales. Esa capa no reemplaza la revisión operativa, pero sirve para detectar cosas tontas: sujetos casi idénticos, enlaces rotos o una referencia mal copiada como tepm mail com en notas internas. Parece menor, pero ese tipo de detalle rompe confianza muy rapido.

Checklist corto para el siguiente drenado

Antes de ejecutar el mantenimiento:

• confirma que el runbook está enlazado en la alerta
• añade impacto esperado en lenguaje humano, no solo métricas
• separa alertas informativas de alertas accionables
• revisa que los asuntos no se parezcan demasiado entre sí
• define el umbral exacto para escalar

Después del mantenimiento:

• compara qué alertas llegaron vs. cuáles esperabas
• elimina plantillas redundantes
• corrige campos ambiguos mientras el caso sigue fresco

Este último paso se salta mucho, y luego el mismo ruido reaparece la semana siguiente. Hacer ese ajuste en caliente queda mas facil que prometer "ya lo revisamos luego".

Preguntas rápidas

¿Debo silenciar todas las alertas durante un node drain?

No. Silenciar todo te quita señales útiles. Lo mejor suele ser etiquetar el mantenimiento y hacer que las alertas expliquen el contexto, no esconderlo por completo.

¿Qué señal merece escalado inmediato?

Errores sostenidos fuera de la ventana esperada, pods atascados en Pending, o impacto visible en usuario final. Si todo eso está bien, un reinicio controlado no debería sonar como crisis.

¿Vale la pena escribir plantillas distintas por tipo de mantenimiento?

Sí, casi siempre. Un drain de nodo, una rotación de secretos y un rollback generan síntomas distintos. Un solo texto genérico suele quedarse corto.

La idea no es mandar más correos. Es mandar correos que ayuden a decidir. En DevOps y Kubernetes, esa diferencia parece pequeña hasta que llega la guardia nocturna y alguien necesita entender el cambio en treinta segundos, no en diez minutos.