Kubernetes será "el sistema operativo de la IA": La apuesta de Google con GKE Agent Sandbox e Hypercluster
En la reciente Google Cloud Next '26, el mensaje fue clarito, fuerte y un poco intimidante: Kubernetes ya no es solo un orquestador de contenedores; es el "sistema operativo para la era de la IA". Mientras algunos de nosotros todavía estamos tratando de solucionar un ImagePullBackOff, Google está preparando GKE para gestionar un millón de chips aceleradores y ejecutar código de "agentes autónomos muy confiables" (léase OpenClaw) a gran escala.
Los anuncios se centraron en dos pilares gigantes:
- GKE Agent Sandbox para la ejecución segura de múltiples agentes
- GKE Hypercluster para una infraestructura que ya roza lo absurdo.
El auge de los poco confiables "agentes autónomos" (léase OpenClaw)
Ya pasamos la etapa de los chatbots. Los flujos de trabajo de IA multi-agente han subido más de un 300% últimamente y, como era de esperarse, darle a un LLM las llaves para ejecutar código es una pesadilla de seguridad cuyas consecuencias ya son visibles, evidenciado en la impresionante frecuencia y cantidad de CVEs, explloits, vulnerabilidades y leaks ocurridos en los últimos meses.
La respuesta de Google es GKE Agent Sandbox. Esto no es solo un nombre de marketing, es una capa de aislamiento a nivel de kernel potenciada por gVisor, la misma tecnología de sandboxing que Google usa para evitar que Gemini se muerda la cola.
Nuevos componentes de Kubernetes
Google no solo está envolviendo contenedores; están introduciendo tres nuevos componentes de Kubernetes -lanzadas originalmente como un subproyecto de SIG Apps- para estandarizar cómo viven y respiran los agentes:
- Sandbox: El recurso principal de la carga de trabajo (workload).
- SandboxTemplate: El blueprint de seguridad (piénsalo como la configuración de "no dejes que el agente se escape").
- SandboxClaim: Un recurso transaccional para solicitar entornos de ejecución desde frameworks como LangChain o ADK, conceptualmente similar a un
persistentVolumeClaim
Para solucionar el problema del "cold start" que tanto nos pena en las ejecuciones tipo serverless, GKE ahora usa "warm pools" de pods pre-provisionados, bajando la latencia a niveles de sub-segundos. Si estás corriendo sobre los procesadores Axion personalizados de Google, ellos aseguran una ventaja de precio-rendimiento del 30% frente a otros hyperscalers.
Hypercluster: Un millón de chips, un solo control plane
Si el Agent Sandbox se trata de lo "micro", GKE Hypercluster se trata de lo "macro". Actualmente en GA privada, Hypercluster permite que un solo control plane de GKE gestione hasta un millón de chips aceleradores a través de 256.000 nodos.
Aunque la escala es brígida (intimidante) , la preocupación por el "blast radius" (radio de explosión) es real. Gestionar un millón de chips desde un solo punto de falla es una movida arriesgada, lo que probablemente explica por qué Google lo mantiene en GA privada por ahora.
Para asegurar estas cargas de trabajo masivas, Google se apoya en el Titanium Intelligence Enclave. Esta arquitectura basada en hardware y "sin acceso de administrador" garantiza que ni siquiera los administradores de la plataforma —la gente a la que le pagan para que mantenga la cuestión andando— puedan ver los weights de los modelos propietarios o los prompts. Todo se mantiene sellado criptográficamente.
Solucionando el cuello de botella de la inferencia
Escalar no sirve de nada si la latencia de inferencia hace que los usuarios sientan que volvieron al internet de los 90. Google introdujo dos funciones clave para que los tokens sigan fluyendo:
1. Predictive Latency Boost
Basado en el proyecto llm-d (que ahora es un proyecto Sandbox de la CNCF), esta función usa ruteo basado en ML. En vez de depender de un round-robin "fome" o de un agendamiento heurístico, el GKE Inference Gateway predice qué nodo tendrá el menor time-to-first-token (TTFT) y rutea el tráfico según eso. Google dice que esto reduce la latencia hasta en un 70%.
2. Automatic KV Cache Tiering
Las ventanas de contexto (context window) son devoradoras de memoria. GKE ahora soporta almacenamiento por niveles (tiering) automático de KV Cache entre RAM, SSD local y Google Cloud Storage (GCS).
- Offloading a RAM: 50% de ganancia en throughput para 10K prompts.
- Offloading a SSD: Casi un 70% de mejora en throughput para 50K prompts.
Reinforcement Learning (RL) y autoscaling basado en intención
En cuanto a Reinforcement Learning (RL), Google anunció RL Scheduler y RL Sandbox. Estas herramientas optimizan las cargas de trabajo de evaluación de recompensas manteniendo el mismo aislamiento a nivel de kernel de Agent Sandbox.
Finalmente, el Horizontal Pod Autoscaler (HPA) por fin va a andar más rápido. El Intent-based autoscaling reduce los tiempos de reacción de 25 segundos a apenas 5 segundos. Lo logra sacando las métricas directamente de los pods en vez de esperar a que el stack de monitoreo externo se dé cuenta de que tu cluster se está incendiando.
Nicolás Georger
Resumen: El diferenciador open-source
Quizás lo más interesante de todo es el compromiso de Google con el camino del código abierto. Al convertir el Agent Sandbox en un proyecto de Kubernetes SIG, están apostando a que el mismo Kubernetes debería ser el runtime de los agentes. A diferencia de las soluciones propietarias, cualquier cluster de Kubernetes que cumpla con los estándares podría, en teoría, correr estas primitivas de agentes.
Ya sea que necesites gestionar un millón de H100s o solo quieras asegurarte de que tu agente de IA no tire un rm -rf / en producción, las actualizaciones del Next '26 de GKE sugieren que el futuro de la IA es, inevitablemente, un archivo YAML.
Referencias y lecturas adicionales
Más contenido:
How the Linux kernel copyfail vulnerability impacts kubernetes: What you need to know and what you can do
copy fail in kubernetes: when your pod escapes to the host with four bytes if you thought containers were a security boundary, cve-2026-31431 ("copy fail") has some unfortunate news for you. discovered by xint, this linux kernel vulnerability lets an unprivileged local user overwrite four controlled bytes in
Leer más →
¿Kubernetes es seguro para inteligencia artificial? Si, pero debes saber estos detalles
Kubernetes es un orquestador increíble, pero es fundamentalmente ciego al caos semántico de la IA. Por eso, confiar únicamente en K8s para la seguridad de un LLM es el equivalente digital a instalar una cerradura biométrica de alta tecnología en una puerta de cartón.
