Agente SRE IA: Despliegue en Producción

2026.01.10
Technology
744 Words
Agente SRE IA: Despliegue en Producción

Esta es la Parte 3 de una serie de 3 partes. La Parte 1 cubrió MCP y la arquitectura de 4 capas. La Parte 2 recorrió el código del servidor con guardarrailes de seguridad. Aquí desplegamos en producción y exploramos flujos avanzados.

Flujos de Trabajo Multi-Herramienta

El poder real de MCP se manifiesta cuando Claude encadena múltiples herramientas. Así se ve en una conversación real:

Usuario: “El despliegue api-gateway en production se ve poco saludable. ¿Puedes investigar?”

Claude (razonamiento interno):

  1. Llamar a list_pods en production para encontrar pods de api-gateway.
  2. Llamar a describe_pod en el pod problemático.
  3. Llamar a get_pod_logs con tail_lines=500 para ver errores recientes.
  4. Sintetizar: “El pod api-gateway-7d9f4b2c-x1z9 está en CrashLoopBackOff. Los logs muestran un timeout de conexión al auth-service en 10.0.4.15:8080. La última verificación de salud exitosa fue hace 12 minutos. Siguiente paso recomendado: verificar si auth-service es alcanzable desde el pod api-gateway.”

Toda la secuencia de diagnóstico se completa en menos de cinco segundos. El operador humano recibe un resumen preciso y una recomendación, no un muro de logs sin procesar. Este encadenamiento funciona porque MCP le da a Claude definiciones estructuradas de herramientas con parámetros tipados que se componen naturalmente.

Despliegue en Producción

Para producción, empaqueto el servidor MCP como un contenedor y lo despliego como sidecar o servicio independiente en Kubernetes.

# Dockerfile
FROM python:3.12-slim
WORKDIR /app
COPY pyproject.toml uv.lock ./
RUN pip install uv && uv sync --no-dev
COPY server.py approval_queue.py ./
ENV K8S_MCP_MODE=readonly
ENV K8S_MCP_DRY_RUN=false
ENV PYTHONUNBUFFERED=1
USER 1000
CMD ["uv", "run", "python", "server.py"]

Despliega con una ServiceAccount que tenga RBAC con alcance explícito:

rbac.yaml
apiVersion: v1
kind: ServiceAccount
metadata:
name: k8s-mcp-server
namespace: monitoring
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: k8s-mcp-readonly
namespace: default
rules:
- apiGroups: [""]
resources: ["pods", "pods/log", "events"]
verbs: ["get", "list"]
- apiGroups: ["apps"]
resources: ["deployments"]
verbs: ["get", "list"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: k8s-mcp-readonly
namespace: default
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: Role
name: k8s-mcp-readonly
subjects:
- kind: ServiceAccount
name: k8s-mcp-server
namespace: monitoring

¿Necesitas la capacidad de reinicio? Crea un Role separado con patch en despliegues y vincúlalo solo después de implementar los flujos de aprobación.

Solución de Problemas

SíntomaCausaSolución
Falla kube_config.load_kube_configNo hay kubeconfig en el entornoMonta un Secret de kubeconfig o usa configuración in-cluster
Claude muestra “No tools available”El servidor MCP no iniciaRevisa los logs de Claude Desktop; verifica la ruta del JSON
PermissionError en ops de lecturaLista blanca de namespaces incorrectaVerifica que K8S_MCP_NAMESPACES incluya el namespace objetivo
Logs truncados en 1000 líneasLímite duro de tail_linesUsa kubectl logs directamente para logs históricos completos
Cola de aprobación no funcionaPermisos de directorioAsegúrate de que el directorio de aprobación sea escribible

Preguntas Frecuentes

¿Qué es un servidor MCP y por qué necesito uno?

Un servidor MCP es un servicio ligero que expone herramientas a un asistente de IA mediante el Model Context Protocol. Le da a la IA acceso estructurado y validado a tu infraestructura, en lugar de pedirle que genere y ejecute comandos de shell a ciegas.

¿Es FastMCP la única forma de construir servidores MCP?

Para nada. Anthropic tiene un SDK oficial de TypeScript, y existen implementaciones para Go y Rust. Uso FastMCP (Python) porque el cliente de Kubernetes es maduro y la mayoría del tooling SRE ya vive en Python.

¿Puede este agente romper realmente mi clúster?

Solo si lo configuras así. El modo por defecto es readonly, restringido por namespace, y cada operación de escritura se envuelve en una cola de aprobación. Empieza con mínimo privilegio y expande con cuidado.

¿Cómo se compara con kubectl-ai o k8sgpt?

kubectl-ai genera comandos kubectl desde lenguaje natural pero necesita que los ejecutes. k8sgpt diagnostica clústeres con análisis estático pero nunca ejecuta comandos. Este enfoque MCP fusiona ambos: interfaz en lenguaje natural con ejecución validada y compuertas de seguridad.

¿Qué pasa si Claude alucina un nombre de pod?

El servidor recibe el nombre exacto de Claude y consulta la API de Kubernetes. Si el pod no existe, la API devuelve un 404, que el servidor transmite de vuelta a Claude. La capa de herramientas valida la realidad; la IA no necesita alucinar correctamente.

¿Puedo usar esto con otros clientes de IA?

El protocolo MCP es abierto, aunque el soporte de clientes sigue expandiéndose. Claude Desktop tiene la implementación más madura. OpenAI Agents SDK ha anunciado compatibilidad con MCP y varios clientes open-source están agregando soporte.

¿Debería ejecutarlo localmente o en el clúster?

Para uso personal, ejecutarlo localmente funciona. Para producción en equipo, ejecútalo dentro del clúster con una ServiceAccount y RBAC. Esto elimina la gestión de kubeconfig y mantiene el tráfico de red interno.

Próximos Pasos

Ahora tienes un agente SRE de IA funcional que diagnostica problemas de Kubernetes mediante lenguaje natural. Aquí tienes hacia dónde seguir:

Si construyes algo interesante con esto, comparte tu flujo de trabajo. Me interesan especialmente las variantes creativas del patrón de cola de aprobación.

# Mcp # agente-ia # sre # Kubernetes # agentic # DevOps