Google adds GPU & TPU support to GKE Autopilot

Google has added GPU and TPU support to managed DRANET on Google Kubernetes Engine Autopilot clusters, extending automated network resource allocation for accelerator-based workloads in its managed Kubernetes service.

GKE Autopilot users can now set up Pods that request network interfaces for TPUs and Remote Direct Memory Access, or RDMA, without managing the underlying nodes directly. The feature works through a combination of Autopilot clusters, custom ComputeClass definitions and ResourceClaimTemplate objects that tie workloads to the required networking resources.

Autopilot is Google's managed mode for GKE, in which the company handles node management, scaling, security settings and other cluster configuration tasks. Managed DRANET lets users request and allocate networking resources for Pods, including interfaces needed for accelerator-based workloads.

The Autopilot configuration starts with a Virtual Private Cloud network and a regional cluster. Users then create a custom ComputeClass for the chosen accelerator type, either GPU or TPU, and add a ResourceClaimTemplate that defines the relevant networking device class.

For GPU deployments, the example setup uses an Nvidia B200 configuration on an a4-highgpu-8g machine type with eight GPUs and an automatic accelerator network profile. It also includes a specific reservation setting that ties resource creation to a named reservation in the user's project.

For TPU deployments, the example ComputeClass uses a TPU v6e slice with a count of eight and a 2x4 topology in a specified zone. In both cases, the ComputeClass enables networking under the dra section of the node pool configuration.

Network claims

A key part of the setup is the ResourceClaimTemplate, which differs by accelerator. GPU workloads using RDMA reference the device class mrdma.google.com, while TPU workloads use the non-RDMA device class netdev.google.com.

That distinction reflects the different networking requirements of the two workload types. In practice, the resource claim links the Pod to the network device allocated on the underlying infrastructure.

The GPU deployment example shows a two-replica application serving the Gemma 4 31B model with vLLM. The manifest requests 10 CPUs, 1000Gi of memory, 1Ti of ephemeral storage and eight Nvidia GPUs per container, while also referencing the RDMA claim and the ComputeClass created earlier.

It also includes startup, liveness and readiness probes, a shared memory volume and a secret containing a Hugging Face token used to download the model. The node selector points the deployment to the ComputeClass configured for managed DRANET networking.

Scale-up path

According to Google, launching the deployment triggers a scale-up operation in GKE Autopilot. The service reads the ComputeClass, provisions the required node type and applies the managed DRANET network configuration, while the claim binds the Pod to the accelerator resources on that node.

The same pattern applies to TPU workloads, even though the network device class differs. This gives users a common operational model for deploying accelerator-based applications on Autopilot, rather than requiring separate networking steps for each hardware type.

The addition is relevant to developers and infrastructure teams building AI inference or training services on Kubernetes, particularly those seeking Google-managed cluster operations while still accessing low-level accelerator networking. It also reflects the growing importance of RDMA and similar high-throughput interconnects in modern AI systems, where network performance can shape the efficiency of multi-accelerator deployments.

By combining automated cluster operations with explicit resource claims for networking, Google is trying to bridge the gap between managed Kubernetes simplicity and the more specialised infrastructure demands of accelerator-heavy workloads. The published examples show that users still need to define several infrastructure objects, but node lifecycle management and much of the cluster setup remain under Google's control.

The approach also underlines how cloud providers are packaging accelerator access into Kubernetes-native abstractions. Instead of asking users to attach and configure network resources manually, the model relies on declarative specifications that can be versioned and deployed alongside applications.

In the GPU example, the workload references both the ResourceClaimTemplate and the ComputeClass in a single deployment manifest, allowing the cluster to provision the correct machine type, attach the requested networking resources and schedule the application to the appropriate nodes.