Agentic DevOps: Herramientas Seguridad y Gobierno
Tabla de contenidos
Parte 3 de 5 | ← Parte 1 | ← Parte 2 | Parte 4 → | Parte 5 →
Construyendo tu Primer Servidor MCP para Consultas de Logs de Kubernetes
Construyamos algo real. El siguiente servidor MCP en Python expone herramientas para consultar logs de Kubernetes y listar pods. Usa el SDK oficial de MCP para Python y el cliente de Python para Kubernetes.
Instalación
# Crea un entorno virtual para el proyecto del servidor MCPuv init k8s-mcp-servercd k8s-mcp-serveruv venvsource .venv/bin/activate
# Instala el SDK de MCP y el cliente de Kubernetes# mcp[cli] proporciona el framework FastMCP para construir servidores rápidamente# kubernetes es el cliente oficial de Python para la API de K8suv add "mcp[cli]" kubernetesEl Código del Servidor
Crea server.py:
# server.py. Un servidor MCP de consulta de logs de Kubernetes para Agentic DevOps# Este servidor expone herramientas seguras de solo lectura que permiten a los agentes de IA# inspeccionar el estado del cluster sin requerir acceso directo a kubectl ni permisos elevados.
from typing import Optional
from kubernetes import client, configfrom mcp.server.fastmcp import FastMCP
# Inicializa el servidor FastMCP con un nombre descriptivo.# Este nombre aparece en la interfaz de descubrimiento de herramientas del agente.mcp = FastMCP("k8s-logs")
# Carga la kubeconfig una vez al inicio para evitar llamadas repetidas al filesystem.# Para despliegue in-cluster, reemplaza con config.load_incluster_config()config.load_kube_config()v1 = client.CoreV1Api()
@mcp.tool()async def get_pod_logs( pod_name: str, namespace: str = "default", tail_lines: int = 100, container: Optional[str] = None,) -> str: """Obtiene logs recientes de un pod de Kubernetes.
Esta herramienta permite a los agentes de IA diagnosticar fallas leyendo logs de aplicaciones sin necesidad de acceso shell a los nodos del cluster.
Args: pod_name: Nombre del pod a consultar (ej., "nginx-7c4b9c6f5-x2v1p") namespace: Namespace de Kubernetes donde corre el pod (default: default) tail_lines: Número de líneas de log a retornar (default: 100) container: Nombre del contenedor (requerido solo si el pod tiene múltiples contenedores) """ try: # Construye kwargs dinámicamente para solo pasar 'container' cuando se proporciona. # Esto evita errores de API por pasar valores None. kwargs = { "name": pod_name, "namespace": namespace, "tail_lines": tail_lines, } if container: kwargs["container"] = container
# Llama a la API de Kubernetes para obtener logs. # Esta es una operación de solo lectura sin efectos secundarios en el cluster. logs = v1.read_namespaced_pod_log(**kwargs) return logs except client.exceptions.ApiException as e: # Retorna mensajes de error estructurados para que el agente pueda razonar sobre las fallas. return f"Kubernetes API error: {e.status}, {e.reason}" except Exception as e: return f"Unexpected error fetching logs: {str(e)}"
@mcp.tool()async def list_pods(namespace: str = "default") -> str: """Lista pods en un namespace con su estado y conteos de reinicio.
Esta herramienta da a los agentes de IA una instantánea de la salud de la carga de trabajo, permitiéndoles identificar pods que se están cayendo o son inestables rápidamente.
Args: namespace: Namespace de Kubernetes a listar (default: default) """ try: # Consulta la API de K8s para todos los pods en el namespace especificado. pods = v1.list_namespaced_pod(namespace=namespace)
# Formatea la salida como tabla para que los LLMs puedan parsearla fácilmente. # Los conteos de reinicio ayudan a los agentes a detectar ciclos de crash recurrentes. lines = [f"{'POD':<40} {'STATUS':<12} {'RESTARTS':<10}"] lines.append("-" * 64) for pod in pods.items: # Suma los conteos de reinicio a través de todos los contenedores en el pod. restarts = sum(c.restart_count for c in (pod.status.container_statuses or [])) lines.append( f"{pod.metadata.name:<40} {pod.status.phase:<12} {restarts:<10}" ) return "\n".join(lines) except client.exceptions.ApiException as e: return f"Kubernetes API error: {e.status}, {e.reason}"
if __name__ == "__main__": # Ejecuta el servidor con transporte stdio para pruebas locales. # En producción, cambia a HTTP/SSE o despliega como sidecar. mcp.run(transport="stdio")Conectando a Claude Desktop
Agrega esto a tu configuración de Claude Desktop (~/Library/Application Support/Claude/claude_desktop_config.json en macOS o %APPDATA%\Claude\claude_desktop_config.json en Windows):
{ "mcpServers": { "k8s-logs": { "command": "uv", "args": [ "run", "--cwd", "/absolute/path/to/k8s-mcp-server", "python", "server.py" ] } }}Reinicia Claude Desktop. Ahora puedes preguntar: “Muéstrame las últimas 50 líneas de logs del pod nginx.” Claude descubrirá la herramienta get_pod_logs, la invocará a través del servidor MCP, y presentará los resultados.
💡 Consejo: Para despliegue in-cluster, reemplaza
config.load_kube_config()conconfig.load_incluster_config()y ejecuta el servidor como un pod con un ServiceAccount que tenga permisos de solo lectura para logs.
Herramientas de Agentic DevOps: De Claude Code a LangGraph
El ecosistema de agentic devops está evolucionando rápido. Aquí están las herramientas y frameworks clave que potencian los flujos de trabajo modernos de IA SRE.
Claude Code
Claude Code es la herramienta de programación agentica de Anthropic. Puede editar archivos, ejecutar comandos shell e interactuar con clusters vía servidores MCP. La integración de servidor MCP es nativa y está bien documentada en la documentación de MCP de Anthropic.
Fortaleza: Razonamiento profundo y contexto largo. Debilidad: Requiere ejecución local; no es un servidor headless.
GitHub Copilot Chat
Copilot Chat genera Terraform y Kubernetes YAML pero carece de tool-calling nativo para APIs de infraestructura. Existen workarounds, pero la experiencia es menos integrada que el soporte de servidor MCP de Claude Code.
Fortaleza: Ubicuo en los flujos de trabajo de desarrolladores. Debilidad: No tiene un runtime de agente de infraestructura de primera clase.
Agentes Personalizados con LangGraph y OpenAI Agents SDK
Para sistemas de agentic devops en producción, probablemente construirás agentes personalizados usando LangGraph o el OpenAI Agents SDK. El enfoque de máquina de estados de LangGraph funciona bien para flujos de trabajo de remediación con pasos explícitos y rutas de rollback.
Fortaleza: Control total y observabilidad sobre las operaciones autónomas. Debilidad: Requiere esfuerzo de desarrollo significativo.
El Ecosistema MCP
Los servidores MCP están proliferando. Los ejemplos oficiales incluyen servidores para PostgreSQL, Slack y Git. Los servidores de la comunidad están emergiendo para Terraform, AWS y Datadog. Si estás explorando opciones de orquestación de workflows para tus pipelines de IA, entender cómo los servidores MCP encajan en esa arquitectura es esencial.
FAQ
¿Qué herramienta debería usar para Agentic DevOps. Claude Code o LangGraph?
Depende de la complejidad de tu workflow. Claude Code funciona bien para tareas lineales como escalar un deployment. LangGraph es mejor para workflows multi-paso que necesitan gestión de estado y ramificación condicional, por ejemplo, rastrear un pod OOMKilled hasta un memory leak y luego desplegar un hotfix.
¿Cuáles son los mayores riesgos de seguridad con operaciones autónomas?
Los tres principales son: servidores MCP con demasiados privilegios (dar acceso cluster-admin al agente), alucinaciones del LLM (un agente ejecutando con confianza una acción incorrecta), y radio de impacto no controlado (una acción correcta causando fallos en cascada). Mitiga los tres con modos dry-run, aprobaciones explícitas y rollback automático.
¿Cómo audito las acciones de los agentes en producción?
Registra cada invocación de herramienta con contexto completo: la alerta que la disparó, el razonamiento del LLM, la acción tomada y el resultado. Almacena estos registros en S3 con hashing a prueba de manipulaciones. La mayoría de los marcos de cumplimiento no contemplan agentes de IA todavía, así que empieza a construir tu trail de auditoría ahora.
¿Puedo ejecutar servidores MCP para diferentes herramientas de infraestructura simultáneamente?
Sí. Puedes tener servidores MCP separados para Kubernetes, AWS EC2, PagerDuty y PostgreSQL, cada uno independientemente desplegable y delimitado. El runtime del agente descubre e invoca herramientas de cualquier servidor conectado. Este enfoque modular mantiene el radio de impacto contenido por servicio.
Partes en esta serie: ← Parte 1 | ← Parte 2 | Parte 4 → | Parte 5 →