Agentes de IA en Kubernetes: qué enseñan kagent y OpenChoreo
Dos proyectos de código abierto destacados por la comunidad de Cloud Native Sydney este agosto muestran un cambio en la forma de utilizar Kubernetes. kagent es un framework nativo de Kubernetes para crear, desplegar y gestionar agentes de IA. OpenChoreo es una plataforma de desarrollo de código abierto para Kubernetes que ofrece a desarrolladores y agentes de IA mecanismos de nivel superior para construir, desplegar y operar aplicaciones y cargas de trabajo agénticas.
Ejecutar IA en un clúster de Kubernetes no es ninguna novedad, ya que los equipos llevan tiempo alojando servicios de inferencia, servidores de modelos, bases de datos vectoriales y cargas de GPU en Kubernetes. La cuestión más reciente es qué sucede cuando los agentes se convierten tanto en cargas de trabajo como en usuarios activos de la plataforma.
Eso hace que los cimientos operativos existentes cobren aún más importancia. Antes de añadir una capa de agentes, los equipos todavía necesitan entender el modelo de clúster, los límites entre cargas de trabajo, el almacenamiento, las redes, la seguridad y la recuperación descritos en el centro de Kubernetes de Mr.PlanB. Las herramientas agénticas añaden otra superficie de control a esa infraestructura.
Kubernetes ofrece a los agentes un entorno operativo
kagent se define como un framework nativo de Kubernetes para agentes de IA. El atractivo es evidente. Kubernetes ya proporciona un modelo de control declarativo, APIs, espacios de nombres, descubrimiento de servicios, programación de pods, secretos, políticas y un amplio ecosistema de automatización. Un agente creado para este entorno se puede desplegar y gestionar usando muchos de los mismos mecanismos que los equipos de plataforma ya aplican a las aplicaciones.
Esto crea un patrón muy útil para las operaciones. Un agente puede empaquetarse como una carga de trabajo gestionada, recibir permisos con un alcance explícito, conectarse a herramientas aprobadas y observarse igual que otros servicios. En lugar de conceder a un sistema externo de automatización acceso irrestricto al clúster, los equipos pueden situar la automatización dentro de un contexto controlado de Kubernetes.
Empaquetar un agente de esta forma no lo vuelve seguro por defecto, aunque sí hace más visibles sus límites. RBAC, cuentas de servicio, políticas de red, controles de admisión, secretos y datos de auditoría pasan a formar parte del diseño del agente. Los ingenieros de plataforma necesitan saber qué puede leer un agente, qué puede modificar, a qué herramientas puede llamar y qué ocurre cuando un modelo genera una recomendación errónea.
OpenChoreo apunta a una capa de plataforma superior
OpenChoreo aborda el problema desde otra dirección. El proyecto describe una plataforma de desarrollo para Kubernetes con abstracciones, un portal de desarrolladores, CI/CD, GitOps y observabilidad. El objetivo es reducir la complejidad directa de Kubernetes a la que se enfrentan los desarrolladores de aplicaciones, preservando la gobernanza de los equipos de plataforma.
Esa idea gana interés cuando se incorporan agentes de IA. Los humanos ya no son los únicos consumidores de la API de una plataforma. Un agente puede necesitar desplegar un componente, inspeccionar un entorno, solicitar un recurso o reaccionar ante un evento operativo. Las abstracciones de mayor nivel pueden delimitar esas acciones con más eficacia que conceder a cada proceso automatizado acceso directo a objetos de clúster de bajo nivel.
El agente termina actuando como un cliente nuevo de la plataforma más que como un añadido de IA pegado a Kubernetes. Desarrolladores, pipelines, operadores y agentes pueden interactuar con la misma infraestructura subyacente mediante interfaces y límites de permisos distintos.
La ingeniería de plataformas se cruza con la infraestructura de IA
Aquí es donde la infraestructura de IA y la ingeniería de plataformas empiezan a solaparse. Ejecutar modelos con eficiencia es solo una parte del reto. Los equipos también necesitan despliegues repetibles, gestión de secretos, almacenamiento, redes, observabilidad, políticas, identidades, escalabilidad y recuperación.
La guía de cargas de trabajo de IA y GPU en Kubernetes aborda la parte de infraestructura: detección de aceleradores, programación, grupos de nodos, drivers, rendimiento de almacenamiento, redes, datos de modelos, resiliencia y costes. Los frameworks de agentes se sitúan por encima de muchas de esas preocupaciones. Si un agente invoca un servicio de inferencia, el modelo subyacente sigue necesitando capacidad de GPU y acceso a datos fiables. Si un agente ejecuta tareas operativas, el clúster todavía requiere controles que eviten que un fallo de automatización se convierta en una caída de la plataforma.
Los agentes de IA también pueden acelerar el ritmo de los cambios. Un administrador humano puede realizar un puñado de cambios meditados durante una ventana de mantenimiento. Un agente automatizado puede inspeccionar, decidir y actuar mucho más rápido. Esa mayor rapidez solo resulta útil si los permisos, la validación, la reversión y la auditabilidad cuentan con la misma madurez.
La elección entre Kubernetes gestionado y bare metal sigue importando
Las decisiones clásicas de infraestructura siguen presentes con las herramientas agénticas, y pesan todavía más. Los equipos deben decidir qué parte del plano de control de Kubernetes y de la infraestructura de soporte quieren gestionar por su cuenta.
La comparativa entre Kubernetes gestionado y bare metal enfoca esa elección en torno al control, el acceso al hardware, el rendimiento, el coste, el personal, las actualizaciones, la seguridad y la carga operativa. Las cargas de trabajo de IA pueden empujar a los equipos en ambas direcciones. Los servicios gestionados reducen parte del mantenimiento de la plataforma, mientras que el bare metal ofrece un control más estricto sobre aceleradores, redes de alta velocidad, almacenamiento y proximidad de los datos.
Los frameworks de agentes pueden operar en cualquiera de los dos modelos, pero las responsabilidades ante fallos varían. En un servicio gestionado, el proveedor de nube suele asumir partes del plano de control, mientras que el cliente mantiene la responsabilidad sobre cargas de trabajo, identidades, políticas y datos. En bare metal, el equipo de plataforma asume mucha más parte del stack y debe planificar directamente las actualizaciones, la disponibilidad, las redes, el almacenamiento y la recuperación.
Los agentes deberían empezar con atribuciones reducidas
La forma más práctica de adoptar agentes suele ser gradual. Los equipos de infraestructura no necesitan empezar permitiendo que un agente de IA resuelva incidencias en producción de manera automática. El análisis en modo solo lectura, la asistencia en la resolución de problemas, la consulta de runbooks, las consultas de inventario y las acciones controladas fuera de producción ofrecen una experiencia valiosa manteniendo un radio de impacto reducido.
A medida que aumenta la confianza, los equipos pueden introducir barreras de aprobación y operaciones de escritura estrictamente delimitadas. El objetivo debe ser que las acciones de los agentes resulten observables y reversibles. Una plataforma debería poder responder qué agente actuó, qué identidad utilizó, qué recursos cambiaron, qué pruebas motivaron la acción y cómo se puede revertir el cambio.
Se trata de una mentalidad DevOps bien conocida aplicada a un actor nuevo. La infraestructura como código hizo que los cambios fueran más repetibles. GitOps formalizó el estado deseado y los flujos de revisión. Las operaciones agénticas plantean ahora la cuestión de cuánta toma de decisiones se puede automatizar sin perder el control.
La próxima plataforma de Kubernetes podría tener dos clases de usuarios
kagent y OpenChoreo son señales tempranas de una tendencia más amplia. Las plataformas de Kubernetes se diseñaron originalmente para operadores y cargas de trabajo de aplicaciones. Luego, la ingeniería de plataformas creó mejores interfaces para desarrolladores. Los agentes de IA introducen ahora otra clase de usuario capaz de consumir esas mismas abstracciones mediante programación y a gran velocidad.
No todos los entornos de Kubernetes necesitan un framework de agentes, pero los equipos de plataforma deberían empezar a considerar a los agentes como participantes de la infraestructura, con identidades, permisos, dependencias, costes y modos de fallo propios.
Los equipos que más se beneficien serán probablemente aquellos que mantengan unos cimientos predecibles y sólidos: propiedad clara del clúster, almacenamiento fiable, cargas de trabajo observables, credenciales bajo control, recuperación probada y límites de automatización bien definidos. Sobre esa base, los agentes de IA pueden convertirse en otra herramienta para operar sistemas complejos, en lugar de ser una nueva fuente de complejidad descontrolada.
Publicado originalmente en el blog de Mr.PlanB.