Como a rede do GKE escala para sustentar alta densidade de agentes de IA concorrentes

O problema descrito pelo Google é de cardinalidade. Controllers e orquestradores de agentes costumam colocar labels únicos em cada pod (como agent-id, timestamps ou claim-uid). O GKE Dataplane V2, baseado em eBPF, converte o conjunto de labels em uma identidade numérica, então cada sandbox ganha a sua. Com muita rotatividade, essa alocação serial pode pausar brevemente a criação de pods enquanto os eBPF maps são atualizados, e cargas grandes podem esbarrar no limite de 65.536 identidades de rede por cluster.

A saída tem duas frentes. A primeira é mover metadados de alta cardinalidade que não participam de service selectors nem de agrupamento de recursos para annotations, já que as identidades saem dos labels. A segunda é aplicar filtros de exclusão de labels do Cilium, por exemplo no ConfigMap cilium-config-emergency-override, no namespace kube-system, com regras como !agents.x-k8s.io/sandbox-name-hash ou !timestamp. Assim, agentes do mesmo tipo seguem compartilhando uma única identidade. O Google cita 300 sandboxes por segundo com latência abaixo de um segundo. No Agent Substrate, em benchmark com 200.000 agentes, a empresa relata 500 ativações por segundo com latência de suspend e resume abaixo de 500 ms.

Em 23 de março de 2026, o CEVIU noticiou "Executando Agentes no Kubernetes com Agent Sandbox", sobre o projeto voltado a agentes de longa duração com ambientes isolados. Em 17 de setembro de 2026, veio "Google Cloud Lança Agent Substrate para Potencializar Agentes de IA no GKE", com a promessa de milhões de sandboxes. Agora o foco sai do runtime e vai para a rede: o texto de 28 de outubro de 2026 mostra o gargalo de identidades no Dataplane V2 e traz números de benchmark e um caso de cliente com picos acima de 30.000 sandboxes em um cluster.

Para quem opera plataformas de agentes no GKE, isso sugere uma checagem simples: revisar o que seus controllers gravam em labels. Se for ID, timestamp ou hash por pod, vale avaliar mover para annotations ou filtrar no Cilium antes de culpar o scheduler pela lentidão de provisionamento. É uma leitura nossa, mas o custo de GPU e TPU ociosas esperando sandbox sobe junto com esse atraso.