Kubernetes: drenar nodos sin perder contexto

En muchos equipos el drenado de nodos se trata como una tarea rutinaria: se agenda, se ejecuta y se da por hecho que todos entienden el impacto. En produccion eso casi nunca pasa asi. Cuando el correo de aviso llega flojo, la guardia pierde tiempo preguntando que nodo cae, que workloads se mueven y si hay riesgo para el trafico. Ese hueco parece pequeno, pero abre confusiones muy reales.

Me he encontrado este problema varias veces en cambios de cluster donde el comando era correcto y el contexto no. kubectl drain hace su trabajo, claro, pero el equipo necesita algo mas que el comando: necesita saber que servicio puede sentir el golpe, cuanto dura la ventana y cual es el criterio de rollback. Si ese resumen no aparece en el primer vistazo, el cambio arranca con friccion innecesaria.

Donde se rompe el contexto durante un drenado

El error comun no esta en Kubernetes. Esta en la comunicacion que rodea al cambio. Un correo tipo "hoy drenamos dos nodos para mantenimiento" suena suficiente hasta que alguien responde con tres preguntas:

1. Que pools o node groups estan afectados.
2. Que cargas son sensibles a reubicacion.
3. Que hago si veo latencia o pods pendientes.

La documentacion oficial recuerda que kubectl drain marca el nodo como unschedulable y evicta pods gestionados, con varias excepciones que importan bastante en produccion: https://kubernetes.io/docs/reference/kubectl/generated/kubectl_drain/

Por eso yo intento que el correo funcione como mini runbook. No reemplaza dashboards, pero evita el clasico "donde estaba el detalle?". Tambien ayuda mucho separar el aviso humano del log tecnico. El log puede tener todo; el correo debe tener solo lo accionable, aunque suene menos sofisticado.

La plantilla minima que uso antes del cambio

Antes de anunciar un drenado reviso una checklist corta:

• nodo o pool afectado
• motivo del mantenimiento
• cargas con riesgo conocido
• ventana estimada
• condicion de rollback
• enlace a dashboard y runbook

Suena basico, si, pero es lo que mas baja preguntas repetidas. En especial cuando el cambio ocurre temprano o cerca de un deploy. Google comenta algo parecido en su libro de SRE: durante operaciones sensibles conviene reducir ambiguedad y dejar claro el siguiente paso para el equipo, no solo el estado actual: https://sre.google/sre-book/emergency-response/

En articulos de producto se ve una idea similar cuando se preparan seed lists limpias para onboarding: no basta con enviar algo, importa que la senal correcta llegue a la persona correcta. En infraestructura pasa igual, solo que con menos margen para improvisar.

Como probar el correo sin tocar bandejas reales

Aqui aparece una leccion muy practica. Si vas a generar correo desechable para validar plantillas de mantenimiento, intenta que cada escenario tenga un inbox aislado. Uno para drenado planeado, otro para rollback, otro para canary fallido. Mezclar todo en la misma bandeja vuelve dificil saber si el mensaje llego tarde, roto o duplicado.

No hace falta un sistema enorme. Yo suelo pedir tres cosas:

• nombres reproducibles por entorno
• expiracion corta para pruebas
• recibo final del payload enviado

Ese recibo importa mas de lo que parece, por que deja revisar asunto, destinatarios y cuerpo exacto cuando algo sale raro. Para automatizaciones internas me gusta pensar estos flujos como contratos de inbox para flujos automatizados: el correo no es un efecto secundario magico, es una salida verificable del sistema.

Tambien meto una cadena torpe como fake e mail com en staging para detectar validaciones o filtros demasiado agresivos. Es feo, un poco rarito incluso, pero descubre bugs tontos antes de que el cambio toque una bandeja real.

Un ejemplo corto que evita preguntas repetidas

Este formato me funciona bastante bien:

Asunto: [Mantenimiento] Drenado de nodos en pool api-green

Estado: Cambio programado
Inicio: 06:30 UTC
Duracion esperada: 20 minutos
Impacto esperado: recreacion gradual de pods en api-green
Riesgo principal: latencia breve si el HPA ya va muy ajustado
Rollback: cordon revertido y pausa del drenado si sube error rate
Enlaces: dashboard, runbook, canal de guardia

No es elegante, pero si util. En menos de 20 segundos cualquier companero entiende que mirar y cuando preocuparse. Tambien deja claro que el impacto es una hipotesis revisable, no una promesa absoluta. Ese matiz importa bastante y aveces se redacta mal.

Si el cluster esta muy cargado, anado una linea extra con el PodDisruptionBudget sensible o el servicio que mas me preocupa. No siempre hace falta; cuando si hace falta, ahorra varios mensajes de seguimiento. Es de esas pequenas cosas que no impresionan a nadie, pero hacen la operacion mas tranquila.

Preguntas frecuentes

Conviene avisar por correo si ya existe Slack?

Si, cuando el correo resume el cambio y deja un registro facil de buscar. Slack sirve para coordinar en vivo; el correo sirve para contexto estable y handoff posterior.

Cuanto detalle tecnico deberia entrar?

Solo el necesario para decidir. Si pones demasiado detalle, el mensaje pierde foco. Si pones muy poco, el equipo abre otra vez el runbook y la consola. Hay que encontrar ese punto medio, no siempre sale a la primera.

Que fallo veo mas seguido?

Asumir que "mantenimiento de nodos" ya explica el riesgo. No lo explica. Lo que ayuda es nombrar workloads, ventana, rollback y responsable. Lo demas puede vivir en el runbook.

Si hoy tus avisos de Cloud salen correctos pero poco utiles, yo empezaria por recortar una plantilla hasta que responda impacto, accion y siguiente paso sin vueltas. Parece una mejora menor, pero en guardias reales se nota un monton.