GKE Dataplane V2 contorna limite de identidades do Cilium em workloads de agentes de IA de alta densidade

O problema está na forma como o GKE Dataplane V2 (eBPF, baseado em Cilium) trata identidade de rede. Ele mapeia os labels de cada pod para uma identidade numérica. Controladores e orquestradores de agentes costumam colocar labels únicos por pod, como agent-id, timestamps ou claim-uid. Resultado: uma identidade nova para cada sandbox. Essa alocação é serial e atualiza mapas eBPF, o que pode pausar a criação de pods. Além disso, o cluster tem teto de 65.536 identidades.

O Google descreve duas saídas. A primeira é mover metadados de alta cardinalidade que não participam de selectors nem de agrupamento de recursos de labels para annotations, já que a identidade é calculada só a partir de labels. A segunda é aplicar filtros de exclusão de labels via 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 compartilham uma única identidade Cilium. O post relata 300 sandboxes por segundo com latência abaixo de um segundo. Para cargas mais pesadas, o Agent Substrate já incorpora essas recomendações e, num benchmark com 200.000 agentes, sustentou 500 ativações por segundo com latência de suspend e resume abaixo de 500 ms.

Em 17 de setembro de 2026, o CEVIU noticiou o lançamento do Agent Substrate no GKE, com foco em rodar milhões de sandboxes. Em 28 de outubro de 2026, na matéria "Como a rede do GKE escala para sustentar alta densidade de agentes de IA concorrentes", a cobertura abordou o desafio de rede nessa escala. Agora o foco é o mecanismo concreto: labels para annotations e filtros de exclusão do Cilium, com números de provisionamento (300 sandboxes por segundo).

Para quem opera plataformas de agentes no GKE, isso vira checklist de revisão de manifests e controllers: label que só serve para rastreio deve ir para annotation. Se o framework que você usa injeta labels dinâmicos, o filtro de exclusão funciona como rede de proteção. É uma leitura editorial, mas o ganho esperado é menos pods travados em criação e menos tempo de GPU ou TPU ociosa.