Agentes de IA y Kubernetes: quién razona y quién ejecuta

En Kubernetes llevamos años conviviendo con "agentes", aunque no sean los que ahora protagonizan todas las conversaciones sobre inteligencia artificial. Un controlador observa el estado actual, lo compara con el estado deseado declarado y actúa para cerrar la distancia entre ambos. La tentación de decir que un agente de IA y un operador de Kubernetes son lo mismo es alta. No lo son, y la diferencia importa mucho cuando hablamos de un clúster en producción.

La pregunta ya no es teórica. En el último año y medio, las herramientas de agentes han pasado de ser un experimento a formar parte del stack cloud native. El CNCF ha aceptado frameworks de agentes en su Sandbox y el SIG Apps de Kubernetes ha incorporado Agent Sandbox como subproyecto para ejecutar cargas de agentes con seguridad. Muchos equipos de plataforma ya están decidiendo qué puede tocar un agente en un clúster en vivo, normalmente mediante un pull request cada vez y sin una política escrita de por medio. Es decir, la frontera entre razonar y ejecutar se está definiendo por convención, no por diseño.

Dos formas distintas de entender el control

Un operador de Kubernetes está pensado para ser predecible: reconcilia recursos según reglas codificadas, reintenta operaciones fallidas y converge hacia el estado declarado. Un agente de IA resulta útil cuando el resultado deseado está claro pero el camino no lo está. Puede investigar una situación desconocida, reunir contexto de varios sistemas, sopesar alternativas y proponer un curso de acción.

El patrón arquitectónico más sensato combina ambas fortalezas: el agente aporta razonamiento y contexto; los operadores, los motores de políticas y el resto de sistemas deterministas conservan el control de la ejecución. Es una separación de responsabilidades clásica, aplicada a un componente nuevo.

kagent: un ejemplo concreto

El proyecto de código abierto kagent, dentro del Sandbox del CNCF, ilustra bien este patrón. Ejecuta agentes de IA como recursos de Kubernetes y los conecta con Kubernetes, Helm, observabilidad y herramientas propias. Un agente puede inspeccionar recursos, recuperar logs y eventos, consultar métricas, revisar documentación y coordinar agentes especializados.

Eso no significa que todas las herramientas deban poder ejecutarse libremente. Las operaciones de lectura no sensibles pueden automatizarse, mientras que cambios como aplicar, parchear o borrar recursos pueden exigir aprobación explícita. Así el agente investiga con amplitud sin que un proceso de razonamiento incierto tenga autoridad ilimitada sobre el clúster.

El bucle operativo resultante sería: observar, diagnosticar, proponer, aprobar, reconciliar y verificar. Los tres primeros pasos se benefician del razonamiento del agente; la reconciliación la asume Kubernetes con sus operadores; la verificación cierra el ciclo sin dar por hecho que un cambio aceptado ha producido el efecto buscado.

Karpenter: el operador no se sustituye, se supervisa

Pensemos en un clúster donde Karpenter aprovisiona capacidad correctamente, pero el equipo sigue viendo nodos infrautilizados, consolidación lenta, rotación de instancias Spot o pods pendientes. Karpenter ya es un operador: evalúa restricciones de planificación y reconcilia NodePools y NodeClaims. Sustituir esa lógica por un modelo de lenguaje haría menos predecible un bucle de control que funciona.

Lo razonable es poner un agente de operaciones por encima de Karpenter. Puede revisar la configuración de NodePool y EC2NodeClass, pods pendientes, eventos de Kubernetes, Pod Disruption Budgets, logs de Karpenter y métricas de Prometheus, y preguntarse por qué el comportamiento observado difiere del objetivo del equipo. La investigación podría descubrir que un Pod Disruption Budget bloquea la consolidación, que una anotación do-not-disrupt mantiene un nodo fijo o que consolidateAfter es demasiado agresivo para una carga con picos.

La salida del agente no debería ser una recomendación vaga del tipo "optimiza el NodePool". Debería presentar la evidencia, identificar el compromiso y generar un parche de configuración acotado: cuántos nodos podrían verse afectados, durante cuánto tiempo se observará la estabilidad o qué restricciones se preservan al ampliar las opciones de instancia. Después, el parche pasa por una puerta de aprobación o de políticas y Karpenter reconcilia con su lógica de siempre.

Argo CD aplica; el agente construye el caso

Otro escenario habitual: un equipo de plataforma actualiza una chart de Helm gestionada por Argo CD. Cambiar la versión en Git es sencillo; entender cómo afectará a la aplicación en marcha requiere más trabajo. Argo CD muestra qué recursos difieren; un agente puede explicar qué significan esas diferencias. Por ejemplo, una nueva versión de la chart podría renombrar un valor usado para configurar el readiness probe. El agente compara notas de versión, valores existentes y manifiestos renderizados para detectar si la actualización caería silenciosamente en un valor por defecto.

El resultado debería ser un pull request enfocado que actualice la versión y los valores afectados, explique el riesgo operativo y defina las comprobaciones previas al despliegue. Una vez revisado y fusionado, Argo CD renderiza y sincroniza. El agente construye el caso; Argo CD aplica.

Qué significa para una pyme o un equipo de IT

Si gestionas infraestructura con Kubernetes, aunque sea de forma modesta, esta discusión te afecta antes de lo que parece. Algunas recomendaciones prácticas:

• No delegues la ejecución en el agente. Que proponga, no que aplique. Los cambios en el clúster deben pasar por operadores, pipelines o políticas existentes.
• Define por escrito qué puede tocar. Si hoy la frontera es una convención, conviértela en política: lectura automática, escritura con aprobación.
• Exige evidencia y alcance. Un buen agente no dice "optimiza"; explica el problema, el compromiso y el impacto máximo del cambio.
• Verifica después. Que un cambio se acepte no significa que haya funcionado. Cierra el bucle con métricas y criterios de aceptación.
• Empieza por lo aburrido. Diagnóstico de pods pendientes, revisión de logs o comparación de charts antes de tocar capacidad o redes.

Este enfoque encaja con lo que ya hemos comentado en el blog sobre los tres cuellos de botella al escalar Kubernetes y con la idea, cada vez más extendida, de que el riesgo de la IA no se mide activo a activo. La IA aporta contexto y velocidad de análisis; la infraestructura sigue necesitando determinismo para ejecutar.

En ForgeNEX lo vemos así: el agente es un buen analista, no un operador con las llaves del clúster. Diseñar esa separación desde el principio es más barato que descubrirla después de un incidente.

Fuente: The New Stack. Análisis y adaptación: ForgeNEX.