IA en la nube · Kubernetes
Crear un agente para diagnosticar problemas de Kubernetes con Strands Agents y Amazon Bedrock AgentCore
Traducción al español del artículo original, con sus herramientas de diagnóstico, escenarios, validación en EKS y límites operativos.
Introducción
Cuando falla una carga de Kubernetes, diagnosticar el problema suele implicar correlacionar varias fuentes de información: el estado del Pod, los detalles de terminación del contenedor, los logs, los eventos de Kubernetes, la configuración del workload y las condiciones del nodo. Una sola señal rara vez cuenta toda la historia, y reunir manualmente esa evidencia puede ralentizar al personal de soporte.
En este proyecto construí un agente de troubleshooting de Kubernetes con Python, Strands Agents, Amazon Bedrock y Amazon Bedrock AgentCore Runtime. El agente recibe una solicitud de diagnóstico en lenguaje natural, recopila evidencia relevante del clúster mediante herramientas de diagnóstico y produce una explicación basada en los resultados.
La arquitectura separa el razonamiento del acceso a Kubernetes. Strands decide qué herramientas de diagnóstico llamar e interpreta su salida. Un servidor dedicado de Model Context Protocol (MCP) expone las herramientas de Kubernetes y gestiona las consultas al clúster. AgentCore Runtime hospeda el agente y el servidor MCP como componentes independientes.
¿Por qué Strands Agents?
Strands Agents es un SDK de Python para crear agentes guiados por modelos. Conecta un modelo con instrucciones y herramientas, y después orquesta la interacción: el modelo puede solicitar una llamada a una herramienta, inspeccionar el resultado y continuar hasta poder ofrecer una respuesta final.
Encaja naturalmente con troubleshooting porque cada incidente requiere evidencia distinta. Un problema ImagePullBackOff necesita información de la imagen y los eventos; una terminación OOMKilled requiere detalles de terminación del contenedor y la configuración de recursos. En vez de codificar todos los diagnósticos en un árbol de decisiones enorme, el agente puede seleccionar herramientas enfocadas y correlacionar sus resultados.
Strands no conoce por sí mismo el estado de un clúster de Kubernetes. Solo puede acceder a la información que le proporcionan sus herramientas. Por eso las instrucciones del sistema enfatizan respuestas basadas en evidencia: no inventar estados del clúster, logs, eventos ni resultados de herramientas; distinguir hechos observados de posibles explicaciones; y recomendar las siguientes comprobaciones de diagnóstico cuando la evidencia esté incompleta.
Crear el agente de Strands
El agente reúne tres elementos principales:
- Un modelo: configurado mediante Strands para usar un modelo disponible en Amazon Bedrock.
- Herramientas: funciones que recuperan conjuntos acotados de información de diagnóstico de Kubernetes.
- Instrucciones del sistema: pautas para recopilar evidencia, interpretar resultados y devolver explicaciones concisas y accionables.
En tiempo de ejecución, se envía una solicitud al agente de Strands. El modelo decide qué herramientas son relevantes, Strands orquesta su ejecución y los resultados vuelven al modelo para que formule un diagnóstico. Esto permite que el agente adapte la investigación al incidente en lugar de seguir una secuencia fija de comandos.
La implementación mantiene separado el razonamiento del agente de los mecanismos para consultar Kubernetes. Ese límite resulta especialmente importante cuando el agente se hospeda en AgentCore y sus herramientas las proporciona un servidor MCP remoto.
Diseñar herramientas para casos de troubleshooting de Kubernetes
Las capacidades de diagnóstico están deliberadamente enfocadas. En lugar de dar al modelo acceso irrestricto a Kubernetes, el agente usa herramientas que recopilan hechos específicos del clúster.
Inventario del namespace
list_namespace_pods enumera los Pods de un namespace y ayuda a identificar qué workload necesita investigación. Ofrece al agente una vista inicial de los recursos involucrados en una solicitud de soporte.
Diagnóstico del Pod
get_pod_diagnostics recupera el estado de ejecución, los logs previos del contenedor cuando están disponibles y los eventos relevantes de Kubernetes. Estas señales ayudan a explicar ciclos de reinicio, errores al descargar imágenes y terminaciones de contenedores.
Configuración del Pod
get_pod_configuration inspecciona detalles del workload, como comandos de contenedores, probes y solicitudes o límites de recursos. La configuración aporta contexto a los síntomas de ejecución, pero por sí sola no demuestra una causa raíz.
Diagnóstico del nodo
get_node_diagnostics recopila información sobre la disponibilidad del nodo y la presión de recursos relevante para problemas de scheduling y ejecución. Esta herramienta también puede revelar que los permisos actuales del agente no le permiten inspeccionar un nodo.
Estas herramientas se complementan. Kubernetes sigue siendo la fuente de verdad; la responsabilidad del agente es elegir consultas pertinentes, correlacionar los hechos devueltos, explicar qué respalda la evidencia e identificar lo que todavía se desconoce.
Escenarios de troubleshooting
La implementación se centra en cuatro patrones de fallos comunes.
CrashLoopBackOff
Un contenedor termina repetidamente y Kubernetes lo reinicia. Los diagnósticos del Pod pueden revelar la cantidad de reinicios, estados actual y anterior del contenedor, logs disponibles y eventos relacionados. El agente puede resumir el fallo observado y sugerir comprobaciones sobre el comportamiento de la aplicación, comandos, probes o configuración de recursos, sin asumir una causa que no se haya establecido.
ImagePullBackOff
Un Pod no puede iniciarse porque Kubernetes no logra descargar su imagen de contenedor. El estado del Pod y los eventos pueden identificar el error informado al intentar descargar la imagen. Según el error real, el agente puede recomendar revisar el repositorio y la etiqueta, el acceso al registry o las credenciales para descargar la imagen.
OOMKilled
Un contenedor terminó después de agotar la memoria. El motivo de terminación y el código de salida son evidencia útil, y la configuración del Pod muestra las solicitudes y límites de memoria configurados. Sin embargo, los límites configurados no son métricas históricas de uso. Sin datos de monitorización, el agente no debe afirmar que conoce el consumo real de memoria del contenedor antes de la terminación.
Pending por restricciones de scheduling
Un Pod permanece en estado Pending porque el scheduler no puede ubicarlo en un nodo. Los eventos de scheduling pueden informar CPU insuficiente, taints no tolerados u otras restricciones de ubicación. Los diagnósticos del nodo aportan contexto adicional cuando la identidad de ejecución está autorizada para leer la información relevante.
Estos casos ejercitan distintas señales de diagnóstico y mantienen limitada la superficie de herramientas a operaciones de solo lectura.
Desplegar el agente con Amazon Bedrock AgentCore Runtime
Amazon Bedrock AgentCore Runtime proporciona el entorno administrado en el que un cliente externo puede invocar al agente de Strands. El cliente envía una solicitud al runtime, el agente la procesa con el modelo y las herramientas configurados, y devuelve la respuesta.
Esto separa al cliente de la implementación del agente. Un cliente local de Python puede invocar el runtime desplegado mediante el AWS SDK, y se pueden añadir otros clientes sin reescribir el razonamiento de diagnóstico. Cada cliente necesita un método de autenticación apropiado y permiso para invocar el runtime.
En el flujo de troubleshooting de Kubernetes, el runtime del agente es la capa de razonamiento. La conectividad con Kubernetes y los permisos del clúster pertenecen a la capa dedicada de herramientas, en vez de mezclarse con la lógica de la aplicación del agente.
Conectar herramientas de Kubernetes a través de MCP
Model Context Protocol ofrece una forma estándar de exponer herramientas a una aplicación de IA. En esta arquitectura, el servidor MCP de Kubernetes publica las capacidades de diagnóstico como herramientas MCP. El agente de Strands se conecta al endpoint MCP remoto, descubre las herramientas disponibles mediante un cliente MCP —por ejemplo, con mcp_client.list_tools_sync()— y las proporciona a Strands.
El flujo de la solicitud es:
- Un ingeniero de soporte envía una pregunta en lenguaje natural al agente Strands hospedado en AgentCore.
- Strands selecciona las herramientas de diagnóstico necesarias para investigar el problema.
- El agente llama al servidor MCP usando el endpoint y la autenticación configurados.
- El servidor MCP valida el contexto de clúster solicitado y ejecuta las consultas de Kubernetes permitidas.
- Los resultados de las herramientas vuelven al agente, que correlaciona la evidencia y responde a quien hizo la solicitud.
Este diseño mantiene explícitas las responsabilidades: Strands razona sobre el incidente, MCP expone las capacidades de diagnóstico y Kubernetes proporciona el estado real del clúster.
Hacer que el servidor MCP sea reutilizable en varios clústeres
Un servicio de troubleshooting útil no debería estar ligado permanentemente a un único clúster EKS. En su lugar, la capa MCP puede usar perfiles de clúster configurados por administradores, para que quien llama solicite diagnósticos sobre un contexto autorizado y con nombre, como desarrollo o staging.
El servidor MCP debe validar la selección del clúster. No se debe permitir que un modelo o cliente proporcione endpoints de API arbitrarios, contenido de kubeconfig ni credenciales. El servidor solo debe conectarse a clústeres configurados explícitamente para los que el runtime tenga autenticación válida, acceso de red y autorización.
Para EKS, esto incluye la identidad de AWS adecuada, la autenticación de EKS, la autorización de Kubernetes y una ruta de red hacia la API del clúster. El acceso debe limitarse a las operaciones de solo lectura que requieren las herramientas de diagnóstico. Admitir varios clústeres no significa conceder acceso a todos los clústeres de una cuenta AWS: cada contexto configurado debe tener un límite de seguridad definido.
Esta abstracción también mantiene al agente Strands independiente de la implementación específica del clúster. El agente solicita información de diagnóstico a través de herramientas, mientras la capa MCP resuelve el contexto de Kubernetes autorizado y recupera los datos.
Validar el agente contra un clúster EKS real
Después de desplegar el agente Strands en AgentCore Runtime, lo invoqué contra un clúster real de Amazon EKS y le pedí diagnosticar el Pod oom-demo en el namespace agent-lab.
La respuesta informó la siguiente evidencia observada:
- Fase del Pod:
Running, pero no estaba listo. - Estado del contenedor: esperando en
CrashLoopBackOff. - Cantidad de reinicios: 7.
- Terminación previa:
OOMKilled, con código de salida 137. - Configuración de recursos: solicitud de memoria de 32 MiB y límite de 64 MiB.
- Eventos del Pod: la imagen se descargó y el contenedor se creó e inició varias veces, seguidos por eventos de backoff de reinicio.
El agente identificó la presión de memoria como una explicación plausible y recomendó investigar más. No afirmó conocer el uso histórico de memoria del Pod porque esa información no estaba disponible mediante las herramientas de diagnóstico.
La ejecución también reveló un límite de permisos: los diagnósticos del nodo recibieron HTTP 403 al intentar leer un nodo. El agente informó la denegación de acceso en vez de presentar las condiciones del nodo como hechos conocidos. Esto es parte esencial de un troubleshooting confiable: una observación ausente debe seguir ausente, no convertirse en un diagnóstico inventado.
Esta invocación demuestra la capacidad del agente para reunir y correlacionar evidencia real de EKS. La integración MCP remota es el siguiente paso de arquitectura para separar la capa de acceso a Kubernetes del agente y hacer que las herramientas sean reutilizables entre clústeres autorizados explícitamente.
Límites de seguridad y operación
La arquitectura requiere algo más que desplegar dos runtimes. El agente y el servidor MCP necesitan identidades de ejecución con alcance apropiado, el endpoint MCP necesita una configuración explícita de autenticación y el runtime MCP requiere conectividad de red y autorización para consultar el clúster objetivo.
Las herramientas de diagnóstico deben permanecer en modo de solo lectura. Las credenciales no deben incluirse en prompts, código fuente ni imágenes de contenedor. La selección de clúster debe estar permitida y autorizada por el servidor, y cualquier información no disponible —por falta de telemetría o de permisos— debe reportarse con transparencia.
Conclusión
Este proyecto combina Strands Agents, Amazon Bedrock, AgentCore Runtime, MCP y herramientas de diagnóstico de Kubernetes en una arquitectura de soporte. Strands aporta razonamiento y orquestación de herramientas, AgentCore hospeda el runtime del agente y MCP separa al agente de la capa de acceso a Kubernetes.
La invocación real en EKS valida la capacidad del agente para razonar a partir de evidencia del clúster y comunicar incertidumbre. El siguiente paso es completar la integración MCP remota y hacer que la selección de clústeres sea reutilizable y segura, para que el mismo agente de troubleshooting pueda trabajar con varios contextos de Kubernetes autorizados explícitamente.