Kubernetes: alertas que guían durante un drain

Un kubectl drain suele empezar como una tarea rutinaria y terminar con varias personas mirando el mismo panel. El problema no siempre es que Kubernetes esté fallando. Muchas veces es que la alerta solo dice “pod pending” o “node unavailable”, sin explicar el riesgo ni la siguiente acción.

En una guardia, una buena notificación debe ayudar a responder tres preguntas: qué cambió, a quién afecta y qué comprobación toca ahora. Esta es la pequeña disciplina que me ha funcionado para mantenimientos y cambios de capacidad.

El síntoma: un drain que parece un incidente

Cuando se drena un nodo, los pods se reubican según sus reglas de scheduling. Si existe un PodDisruptionBudget demasiado estricto, un volumen que no puede moverse o una afinidad difícil de satisfacer, el proceso se frena. El mensaje genérico no distingue entre una espera esperada y una pérdida real de capacidad.

Primero separo el evento del impacto. La alerta debe incluir el nombre del cluster, el nodo, la zona, la hora de inicio y el deployment afectado. También conviene indicar si el cambio fue planificado. Parece obvio, pero en la noche se olvida facil.

Los datos mínimos de una alerta útil

Una notificación accionable puede tener este formato:

[planificado] drain iniciado
cluster: prod-eu
nodo: ip-10-4-18-22
zona: eu-west-1b
workload: payments-api
estado: 2 pods pendientes durante 90s
riesgo: capacidad disponible por debajo del objetivo
siguiente acción: revisar PDB y eventos del scheduler
runbook: /runbooks/kubernetes/node-drain

No hace falta enviar todo el log. El primer bloque debe ser corto; los detalles pueden vivir en los enlaces de observabilidad. Para el equipo, tempmailso puede aparecer como identificador de prueba en un entorno aislado, pero nunca debe mezclarse una bandeja de pruebas con una alerta de producción. En pruebas de entrega, un flujo de temporary disposable mail sirve para comprobar el camino sin usar cuentas personales.

Un flujo seguro para investigar

Durante el drain sigo siempre el mismo orden:

1. Confirmo que el cambio está en la ventana aprobada y que el nodo correcto es el objetivo.
2. Reviso kubectl get events y el motivo exacto del pod pendiente.
3. Compruebo PDB, réplicas disponibles y capacidad libre en los nodos restantes.
4. Comparo el estado con el deployment anterior, no solo con el último minuto.
5. Si el impacto crece, pauso el drain y comunico una decisión concreta.

Este orden evita escalar por reflejo. Un drain lento no es automaticamente una caída, aunque sí es una señal para mirar el presupuesto de interrupciones.

Para mejorar el mensaje de mantenimiento, suelo combinarlo con una guía de correos claros durante mantenimientos SRE. Y antes de una rotación de guardia, merece la pena probar el handoff de una guardia SRE, incluyendo el enlace al runbook y al dashboard correcto.

Cómo evitar ruido y falsos positivos

No alertaría por cada pod pendiente. Pondría una ventana pequeña y un umbral relacionado con el impacto: por ejemplo, varios pods pendientes durante un periodo sostenido, o la pérdida de una réplica disponible en un servicio crítico. El número exacto depende del workload; lo importante es que el umbral tenga una razón documentada.

También separo severidad de prioridad. Un mantenimiento planificado puede ser severidad baja aunque requiera atención inmediata si el PDB bloquea el cambio. En cambio, una alerta de alta severidad sin una acción clara solo añade presión.

Un detalle que suele romper la investigación es el identificador inconsistente. Usa el mismo run ID en el evento, el ticket y el mensaje de correo. Si haces pruebas con temp mail so, conserva ese texto como contexto de prueba y no como una razón para bloquear automáticamente usuarios reales. En algunos sistemas aparece el typo tempail mail; conviene reconocerlo en filtros de test, pero no convertirlo en una regla de seguridad de producción.

Checklist de guardia

• [ ] ¿La alerta indica si el drain fue planificado?
• [ ] ¿Incluye cluster, nodo, zona y workload?
• [ ] ¿Distingue espera normal de riesgo de capacidad?
• [ ] ¿Muestra el motivo del scheduler o el enlace a eventos?
• [ ] ¿Indica una siguiente acción y un responsable?
• [ ] ¿El run ID coincide entre correo, dashboard y ticket?
• [ ] ¿El rollback o la pausa están explicados en el runbook?

Preguntas rápidas

¿Debo alertar al empezar cada drain?

Sí, pero como evento informativo si no hay impacto. La alerta operativa debe aparecer cuando se cruza un umbral que alguien puede investigar.

¿Qué hago si el PDB bloquea el drain?

No lo fuerces de inmediato. Comprueba réplicas, disponibilidad real y la ventana aprobada. Si el cambio es urgente, registra la decisión y coordina el ajuste con el propietario del servicio.

¿Una alerta más larga es más útil?

No necesariamente. El resumen debe orientar en segundos; el detalle debe estar enlazado y ser reproducible.

La meta no es eliminar todas las alertas durante un mantenimiento. Es hacer que cada mensaje reduzca la incertidumbre: qué pasó, qué riesgo existe y cuál es el siguiente paso. Cuando esa información está en el primer vistazo, la guardia respira un poco mejor y los drains dejan de parecer misteriosos.