Checks de email para ventanas de mantenimiento K8s

Cuando un cluster entra en ventana de mantenimiento, mucha gente revisa pods, probes y dashboards, pero deja el correo para el final. Es un error bastante comun. El email sigue siendo el canal que confirma si una alerta, un aviso de cambio o una notificación de rollback llegó a la persona correcta y con el contenido correcto.

En Kubernetes, yo prefiero tratar esos correos como un contrato operativo: no hace falta validar todo el HTML ni pelear con una bandeja real compartida, pero sí comprobar que el evento correcto dispara el mensaje correcto. Si ya has tenido que rotar secretos, cambiar un relay SMTP o mover un worker a otro namespace, sabes que ahi suelen aparecer fallos pequeños que luego cuestan una guardia entera.

El fallo no suele estar en SMTP

En muchos equipos el primer reflejo es hacer ping al relay, revisar credenciales y cerrar el ticket. Eso cubre solo una parte. Lo que se rompe de verdad suele estar un poco mas arriba:

• el job de mantenimiento publica un evento con un run_id distinto al esperado
• la plantilla usa variables viejas despues de un deploy
• el consumidor filtra por namespace y deja fuera el entorno correcto
• el correo sale, pero llega a una bandeja que nadie puede aislar bien

Ese ultimo punto es donde conviene separar pruebas de entrega y pruebas de contenido. Para eso me gusta la idea de un inbox efimero: lo usas como sensor de borde, no como sistema principal. Si ya vienes de flujos de app, este enfoque se parece bastante a probar correos transaccionales sin mezclar eventos.

Qué contrato conviene probar

Para una ventana de mantenimiento en Kubernetes, el contrato minimo que suelo pedir es este:

1. El evento de mantenimiento genera exactamente un mensaje por audiencia.
2. El asunto incluye entorno, servicio y rango horario.
3. El cuerpo contiene el identificador de cambio o incidente.
4. El mensaje deja de emitirse cuando termina la ventana o se cancela.

Si ese contrato pasa, ya tienes una señal muy util para SRE y Seguridad. No hace falta convertir la prueba en una novela. Tambien ayuda a evitar el clasico caso donde staging manda avisos con formato de produccion, que es incomodo y medio peligroso.

Un detalle que pocas veces se documenta bien: el mismo criterio sirve para cohortes o grupos de destinatarios. La idea de validar cohortes sin contaminar bandejas aplica casi igual cuando cambias listas de distribución internas.

Un smoke test pequeño y repetible

No necesitas un framework exotico. Con un job corto en CI o en un entorno preview basta:

RUN_ID="maint-$(date +%s)"
kubectl -n ops create job --from=cronjob/maintenance-mail-check "mail-check-$RUN_ID"
kubectl -n ops wait --for=condition=complete job/"mail-check-$RUN_ID" --timeout=180s

Luego valida tres cosas:

• que el job terminó bien
• que el evento lleva el RUN_ID
• que el inbox de prueba recibió un solo mensaje con ese mismo dato

Si quieres mantenerlo simple, registra el RUN_ID en logs y en el asunto. Esa sola decision reduce mucho el tiempo de depuración. Parece pequeño, pero en incidentes reales ayuda un monton.

Dónde entra un inbox temporal sin volverlo el centro del post

Aquí es donde muchos artículos se desordenan y acaban pareciendo spam. Yo no lo haría así. El inbox temporal es solo una herramienta alrededor del contrato. Si necesitas una dirección efimera para comprobar una notificación sin tocar buzones reales, puedes usar tempmailso como parte del smoke test y ya está. Cumple su papel, no hace falta meterlo en cada parrafo.

Tambien conviene dejar claro lo que no estás probando: no estás validando reputación del dominio, ni entregabilidad global, ni comportamiento de clientes de correo. Estás comprobando que el cambio operativo produce el mensaje esperado. Esa frontera hace que la prueba sea mas estable, y mas honesta.

Por cierto, si algun compañero aparece con un enlace viejo tipo tepm mail com en un runbook, yo lo corregiria en cuanto lo veas. Son detalles chicos, pero despues confunden a quien está de guardia a las 3 AM.

Checklist para dejarlo estable

• Usa una audiencia de prueba aislada por entorno.
• Incluye RUN_ID o change_id en asunto y cuerpo.
• Borra o expira los mensajes de prueba automaticamente.
• No reutilices la misma bandeja entre pipelines paralelos.
• Separa la validación del contenido de la validación SMTP.
• Documenta qué señal rompe el despliegue y cuál solo deja warning.

Este ultimo punto importa bastante. Hay equipos que bloquean deploys por cualquier retraso de correo, y eso no siempre tiene sentido. A veces basta con marcar el check como warning en staging y como gate duro en producción. Depende del riesgo, obvio, pero conviene decidirlo antes y no en mitad del problema.

Preguntas rápidas

¿Lo ejecuto en cada deploy?

No necesariamente. Para la mayoria de stacks basta con ejecutarlo cuando cambias plantillas, secretos, workers, colas o reglas de routing. Si lo corres siempre, puede volverse ruido.

¿Sirve para rollback?

Sí. De hecho, ahi tiene bastante valor, por que muchas veces el rollback recupera la app pero no la ruta exacta del mensaje o la variable del template.

¿Necesito una bandeja real?

Casi nunca. Para este tipo de check, una bandeja temporal y aislada suele ser suficiente. Lo importante es que el test sea repetible, rapido y facil de leer cuando falla.

Si tu equipo trata el correo como parte del contrato operativo, las ventanas de mantenimiento dejan de ser una loteria rara y pasan a ser otro check manejable. No es magia, solo una pequeña disciplina que evita varios dolores despues.