Google eases GKE Dataplane V2 limits for AI agents

Google has outlined changes to GKE Dataplane V2 to support large numbers of concurrent AI agent sandboxes. The work is intended to address network identity limits in Kubernetes-based environments.

The changes focus on how GKE handles pod labels and network identities when large numbers of short-lived code execution environments are created and removed in quick succession. AI agent workloads, particularly reinforcement learning systems, may require thousands of isolated sandboxes to start and stop every minute, and some research users are seeking infrastructure for up to one million concurrent sandboxes.

The issue centres on how GKE Dataplane V2, which uses eBPF-based networking, maps pod labels to numeric identities for security policy enforcement. In workloads where each pod receives unique labels, such as agent identifiers, timestamps or claim references, the platform may need to assign a distinct identity to each sandbox. That process can slow pod creation and push workloads closer to the cluster-wide ceiling of 65,536 network identities.

Identity limits

Google has split identifying data from metadata that does not need to be part of service selection or core resource grouping. Under this approach, users are encouraged to move high-cardinality fields from pod labels to annotations, since annotations are not used by GKE Dataplane V2 when calculating network identities.

This removes the need to generate a separate network identity for each pod when the differing fields are not relevant to security identity calculation. In effect, identical agent types can share a single identity even if other metadata differs between sandboxes.

A second measure filters dynamic labels out of identity calculation. Users can configure exclusion rules in Cilium so labels such as sandbox hashes or timestamps are ignored when network identities are created.

This is intended to prevent linear growth in identity counts when orchestration frameworks add large numbers of unique labels to individual pods. Google says it also helps avoid the 65,536 identity limit associated with Cilium-based identity management in these environments.

Density targets

Google linked the networking changes to a broader effort to increase density and reduce start-up delays for AI agent infrastructure. It says GKE can deliver 300 sandboxes per second at sub-second latency for fully isolated agents when high-cardinality metadata is removed from identity calculations.

The company also highlighted Agent Sandbox on GKE as the isolation layer for dynamic code-execution environments. For workloads with large numbers of idle sessions, Agent Substrate on GKE builds on those foundations and is designed to restore agent state in less than a second.

In benchmark testing cited by Google, Agent Substrate sustained 500 activations per second while running 200,000 agents, with suspend and resume latency below 500 milliseconds. Google says the product also bypasses some Kubernetes scheduling limits for users seeking higher scale and density.

The update reflects a broader infrastructure challenge in AI operations as customers move from request-response systems to autonomous workflows that require persistent or rapidly recreated execution environments. In those settings, delays in sandbox creation can leave GPUs and TPUs idle while orchestration layers wait for supporting infrastructure to become available.

Google said one customer using Agent Substrate has orchestrated hundreds of thousands of secure environments across clusters and handled spikes of more than 30,000 sandboxes on a single cluster. It did not name the customer in material released alongside the update.

Google framed the GKE Dataplane V2 changes as a way to preserve existing network security controls while scaling to more demanding AI workloads. Rather than altering the underlying security model, the approach centres on reducing the amount of per-pod uniqueness included in identity calculations.

That distinction matters for teams building agent systems with high pod churn, because labels often serve several operational purposes at once. Some are needed for grouping and service matching inside Kubernetes, while others are simply metadata added by developer tools, controllers or workload managers. Google's guidance is to keep only identity-relevant fields in labels and move the rest elsewhere.

According to Google, this would cut provisioning latency, raise compute density and reduce wasted accelerator time in large clusters running AI agents. The architectural changes are intended to make large-scale agent operations more economically viable by limiting infrastructure bottlenecks tied to network identity management.