65.536 es el número máximo de identidades de red que admite un clúster con GKE Dataplane V2, y una carga de agentes que pone una etiqueta distinta a cada pod puede acercarse a esa cifra. Google lo contó el 28 de octubre de 2026 en un artículo sobre cómo escalar sandboxes de agentes en GKE. El cuello de botella no está en el ancho de banda ni en las IP, sino en algo tan cotidiano como los labels de los pods.
Por qué un label puede frenar el arranque de un pod
Dataplane V2 es el plano de datos de GKE basado en Cilium y eBPF. Para aplicar las políticas de red no mira la IP de cada pod, sino una identidad numérica que calcula a partir de su conjunto de labels: los pods con los mismos labels comparten identidad, y las reglas eBPF se escriben una vez para todos ellos.
El problema aparece cuando un controlador propio etiqueta cada pod con algo único: el id del agente, una marca de tiempo o el claim-uid de la reserva. Cada combinación nueva obliga a crear una identidad nueva. Según Google, esa asignación se hace en serie y actualiza los mapas eBPF, así que con mucha rotación puede pausar la creación de pods. Y la rotación en estas cargas es extrema: Google habla de laboratorios que piden hasta un millón de sandboxes de ejecución de código simultáneos y de flujos de aprendizaje por refuerzo que levantan y tiran miles por minuto.
Un Deployment normal no sufre esto porque Cilium ya ignora por defecto los labels que Kubernetes genera por instancia, como pod-template-hash, controller-uid o statefulset.kubernetes.io/pod-name. Lo que no puede adivinar es que agent-id o timestamp son igual de irrelevantes para la seguridad.
Las dos medidas que propone Google
La primera es de diseño: los datos que no participan en un selector de Service ni agrupan recursos no deberían ser labels, sino anotaciones. Las identidades se calculan solo con labels, de modo que mover ahí el id del agente o la marca de tiempo elimina la identidad por pod sin perder la trazabilidad.
La segunda sirve cuando no controlas quién pone los labels, por ejemplo cuando los añade un framework: filtros de exclusión en el ConfigMap cilium-config-emergency-override de kube-system, con reglas como !agents.x-k8s.io/sandbox-name-hash o !timestamp. Con ellas, todos los sandboxes de un mismo tipo de agente vuelven a compartir una sola identidad de Cilium.
Con las dos medidas, Google cifra el resultado en 300 sandboxes por segundo con latencia inferior al segundo, y cita a un cliente que gestiona cientos de miles de entornos aislados entre varios clústeres, con picos de más de 30.000 sandboxes en uno solo.
Cómo se configura en Cilium fuera de GKE
Si gestionas Cilium tú mismo, la documentación del proyecto describe el mismo mecanismo con la clave labels del ConfigMap cilium-config (o la opción de Helm --set labels=...). Los patrones son expresiones regulares ancladas al inicio de la clave, así que los puntos se escapan y !timestamp también excluiría timestamp-utc:
apiVersion: v1
kind: ConfigMap
metadata:
name: cilium-config
namespace: kube-system
data:
# Se suma a las exclusiones por defecto de Cilium
labels: "!agents\\.x-k8s\\.io/sandbox-name-hash !timestamp$"Las identidades existentes no cambian al guardar el ConfigMap: hay que reiniciar los agentes (y también el operador si es él quien gestiona las identidades). El operador recoge después las identidades antiguas que ya no use nadie.
kubectl rollout restart -n kube-system ds/ciliumLa cautela que importa: un label excluido deja de contar para la identidad, así que una NetworkPolicy que seleccione pods por ese label ya no podrá distinguirlos. Antes de excluir nada, busca ese label en tus políticas.
Qué se puede aprender
Los labels forman parte del contrato de red, no son metadatos gratis. En cualquier plano de datos que aplique políticas por identidad, cada label que añades a un pod puede cambiar cómo se evalúa su tráfico. Quien escribe controladores u operadores debería reservar los labels para lo que se selecciona y llevar a anotaciones todo lo que solo sirve para rastrear.
Es la misma lección que la cardinalidad en Prometheus, trasladada a la red: un valor único por instancia multiplica el estado que el sistema tiene que mantener. Y igual que con las métricas, se arregla mejor en origen (el controlador) que con filtros a posteriori.
Qué no es trasladable
La mayoría de los clústeres no se acercan a 65.536 identidades: el problema necesita a la vez mucha rotación y labels únicos por pod. Donde sí puede aparecer fuera de la IA es en controladores que crean pods efímeros con un label por instancia, como runners de CI o entornos por pull request.
Lo que Google presenta para escalar más allá, Agent Substrate, es un producto de GKE que aplica estas recomendaciones y además se salta los límites del scheduler de Kubernetes. Sus cifras (200.000 agentes, 500 activaciones por segundo y suspensión y reanudación en menos de 500 ms) no son algo que se pueda reproducir con Cilium por tu cuenta.
Fuentes
- How GKE networking scales to support high densities of concurrent AI agents, Google Cloud Blog, 28 de octubre de 2026.
- Limiting Identity-Relevant Labels, documentación de Cilium.