Remediación autónoma en Kubernetes: mi arquitectura de referencia
Tabla de contenidos
Un agente que reinicia pods a las 3 AM puede ser un héroe o un desastre. La diferencia está en cuánto le permites hacer sin supervisión.
La remediación autónoma es una de las aplicaciones más atractivas del agentic DevOps. También es una de las más riesgosas. Este post describe la arquitectura que usaría si quisiera construir un sistema de remediación autónoma en Kubernetes.
El bucle OODA
Todo sistema de remediación sigue el mismo ciclo:
- Observar: métricas, logs, trazas.
- Orientar: entender la causa raíz.
- Decidir: elegir una acción.
- Actuar: ejecutar y verificar.
La diferencia con un script tradicional es que el agente puede manejar causas que no fueron codificadas explícitamente. Eso es poderoso y peligroso.
Arquitectura de 4 capas
1. Observabilidad
Prometheus, Loki, Grafana. Sin buena observabilidad no hay remediación.
2. Servidor MCP
Expone herramientas de Kubernetes al agente. Por defecto, solo lectura. Las acciones de escritura requieren aprobación.
3. Runtime del agente
Claude Code, LangGraph, o un agente custom. Ejecuta el bucle OODA.
4. Gobernanza
Aprobaciones, rate limits, audit logs, políticas. Esta capa decide si una acción puede ejecutarse.
Ejemplo: pod OOMKilled
Una alerta dispara el agente. El agente consulta logs y métricas. Decide escalar el deployment. La decisión pasa por un gate de aprobación. Si se aprueba, se ejecuta y se verifica.
Sin el gate, no lo desplegaría.
Conclusión
La remediación autónoma es viable, pero solo con guardrails sólidos. Empieza con diagnóstico automático y sugerencias humanas. Añade acciones reversibles con aprobación. La autonomía total debe ganarse con evidencia.
No dejes que un agente actúe a ciegas en tu cluster. La observabilidad y la gobernanza son más importantes que la velocidad de reacción.