Kubernetes: prueba alertas tras cambios de red

Los cambios de red en Kubernetes suelen romper alertas en silencio. Esta comprobacion corta valida egress, DNS y entrega antes de dar un cambio por cerrado.

He aprendido a desconfiar un poco de los cambios de red "pequenos" en Kubernetes. Una regla de egress, un ajuste en NetworkPolicy o una salida por NAT puede parecer trivial durante la ventana de cambio, pero a veces el problema aparece veinte minutos despues, cuando Alertmanager intenta enviar un correo y nadie lo recibe. En ese punto ya no estas verificando red; estas perdiendo visibilidad operacional.

Por que un cambio de red rompe alertas sin avisar

La mayoria de estos fallos no tumban el servicio principal. La app sigue respondiendo, los probes pasan y el despliegue parece estable. El daño real cae sobre las rutas secundarias: SMTP, webhooks, DNS saliente o resolucion hacia un relay corporativo. Ese patron pasa mucho mas de lo que la gente admite, y por eso una prueba de humo especifica merece su propio paso.

Kubernetes explica que las NetworkPolicy solo afectan al trafico que coincida con los pods seleccionados, lo cual hace facil dejar una dependencia fuera de la cabeza durante un cambio: https://kubernetes.io/docs/concepts/services-networking/network-policies/. El resultado tipico es feo pero silencioso: los paneles siguen verdes y, sin embargo, el canal de alerta queda roto. Es un fallo muy incomodo, porqe la primera señal real puede ser una incidencia ya avanzada.

Mi regla es simple: si el cambio toca salida a internet, DNS interno, firewall de nodo o politicas entre namespaces, cierro el cambio solo despues de probar el camino de las alertas.

La comprobacion corta que hago despues del cambio

No hago una prueba teatral ni larga. Hago una secuencia corta, casi siempre en menos de diez minutos:

1. Confirmo que el pod de Alertmanager o del servicio emisor sigue resolviendo el host SMTP correcto.
2. Verifico conectividad al puerto esperado desde el namespace afectado.
3. Lanzo una alerta controlada o un evento de prueba con un identificador facil de buscar.
4. Reviso logs del emisor y del relay para asegurar que hubo aceptacion, no solo intento.
5. Confirmo recepcion en un inbox de prueba aislado.

Ese ultimo punto evita varias discusiones raras en equipos grandes. Si usas un destino compartido, alguien borra el mensaje, otro responde tarde, o una regla de filtrado te confunde. Un inbox de prueba aislado mantiene la validacion limpia. Incluso lo he usado para revisar plantillas de notificacion que terminaban en un email temporal para Facebook durante una integracion heredada medio extraña; no era elegante, pero sirvio para detectar que el asunto habia quedado truncado.

Cuando necesito pensar el flujo como sistema y no solo como "manda correo o no", me ayuda recordar este enfoque de inbox por etapa en flujos con agentes. La idea de validar cada etapa por separado tambien aplica muy bien a operaciones.

Que revisar cuando Alertmanager parece sano pero no entrega

Aqui es donde conviene ser aburridamente metódico.

Primero, DNS. Muchos equipos prueban curl a una API y dan el cambio por bueno, pero el relay SMTP va por otro nombre, otra ruta o incluso otro proxy. Si el pod no resuelve igual que antes, ya tienes media averia armada.

Segundo, tiempos de espera. Segun la documentacion de Prometheus para configuracion de Alertmanager, un error de red o autenticacion en el receptor puede no ser evidente a primera vista si solo miras el estado general del proceso: https://prometheus.io/docs/alerting/latest/configuration/. A veces el servicio esta "up", pero el receptor devuelve errores intermitentes, o reintenta mas de la cuenta y ensucia la lectura del incidente.

Tercero, evidencias. Yo guardo tres cosas en el ticket del cambio:

1. El comando o alerta de prueba que dispare.
2. La hora exacta y el identificador de correlacion.
3. Una captura de los logs donde se vea entrega o rechazo.

Suena basico, pero ahorra bastante tiempo cuando alguien pregunta si el cambio rompio algo horas despues. El mismo principio aparece en este post sobre auditar emails de upgrade: sin una evidencia pequeña y clara, la conversacion deriva rapido en opiniones.

Tambien reviso si algun operador ha metido destinos de prueba improvisados como tamp mail com en scripts viejos o variables de entorno. No deberia pasar, pero pasa. Y cuando aparece, la investigacion se vuelve mas lenta de lo que deveria.

Un ejemplo pequeno para probar el flujo

Este ejemplo no sustituye una prueba real, pero deja listo un chequeo rapido desde el cluster:

kubectl -n monitoring exec deploy/alertmanager -- \
  sh -lc 'getent hosts smtp.internal.example && nc -vz smtp.internal.example 587'

Si eso responde bien, suelo disparar una alerta de prueba o fuerzo un evento controlado desde el sistema que envia la notificacion. Lo importante es que el mensaje lleve un asunto o etiqueta que puedas rastrear sin dudas. En cambios delicados, prefiero anotar el change_id dentro del texto y revisar recepcion completa, no solo handshake de red.

AWS tambien insiste en que la observabilidad y la validacion posterior al cambio forman parte de una operacion sana, no de un lujo opcional, dentro de sus practicas recomendadas para EKS: https://aws.github.io/aws-eks-best-practices/. Estoy bastante de acuerdo. El error no suele estar en no saber Kubernetes; suele estar en asumir que un cambio de red ya quedo validado porque el deployment no se cayo.

He visto equipos cerrar cambios con demasiada prisa porque "el dashboard sigue verde". Luego llega una alerta real y descubren que el canal de correo estaba roto desde hace media hora. Ese tipo de fallo no es dramatico en el momento, pero te roba confianza en el proceso.

Preguntas rapidas antes de cerrar el cambio

¿Basta con probar conectividad al relay?

No. Eso confirma una parte. Todavia falta validar autenticacion, aceptacion del mensaje y recepcion final.

¿Hace falta hacerlo en cada cambio?

Si el cambio puede tocar rutas de salida, DNS, firewall o politicas entre pods, yo diria que si. No siempre tarda mucho, y evita sustos tontos.

¿Debo usar siempre el mismo inbox de prueba?

Solo si esta bien aislado y con contexto claro. Si varios jobs o equipos lo comparten, la señal se degrada bastante rapido.

¿Que quiero ver para cerrar tranquilo?

Resolucion correcta, conexion al destino, evento emitido, logs consistentes y recepcion confirmada. Si falta uno de esos pasos, para mi el cambio aun no esta del todo cerrado.

Las alertas por correo no son la parte mas glamourosa de Kubernetes, pero cuando fallan te dejan operando medio a ciegas. Por eso prefiero tratar esa validacion como parte del cambio y no como un detalle de despues. Es un paso corto, un poco aburrido, y funciona.