Deploy Autopilot workloads on Arm architecture

This page shows you how to configure your Google Kubernetes Engine (GKE)Autopilot deployments to request nodes that are backed by Armarchitecture.

About Arm architecture in Autopilot

Autopilot clusters offercompute classesfor workloads that have specific hardware requirements. Some of these computeclasses support multiple CPU architectures, such asamd64 andarm64.

Use cases for Arm nodes

Nodes with Arm architecture offer more cost-efficient performance than similarx86 nodes. You should select Arm for your Autopilot workloads insituations such as the following:

  • Your environment relies on Arm architecture for building and testing.
  • You're developing applications for Android devices that run on Arm CPUs.
  • You use multi-arch images and want to optimize costs while runningyour workloads.

Before you begin

Before you start, make sure that you have performed the following tasks:

  • Enable the Google Kubernetes Engine API.
    • Enable Google Kubernetes Engine API
  • If you want to use the Google Cloud CLI for this task,install and theninitialize the gcloud CLI. If you previously installed the gcloud CLI, get the latest version by running thegcloud components update command. Earlier gcloud CLI versions might not support running the commands in this document.Note: For existing gcloud CLI installations, make sure to set thecompute/regionproperty. If you use primarily zonal clusters, set thecompute/zone instead. By setting a default location, you can avoid errors in the gcloud CLI like the following:One of [--zone, --region] must be supplied: Please specify location. You might need to specify the location in certain commands if the location of your cluster differs from the default that you set.

How to request Arm nodes in Autopilot

To tell Autopilot to run your Pods on Arm nodes, specify one of thefollowing labels in anodeSelectorornodeaffinityrule:

  • kubernetes.io/arch: arm64. GKE places Pods onC4A machinetypes by default for clusters running version 1.31.3-gke.1056000 and later.If the cluster is running an earlier version, GKE places PodsonT2A machine types.
  • cloud.google.com/machine-family:ARM_MACHINE_SERIES.ReplaceARM_MACHINE_SERIES with an Arm machineseries likeC4A,N4A, orT2A. GKE places Pods on thespecified series.

By default, using either of the labels lets GKE place other Podson the same node if there's availability capacity on that node. To request adedicated node for each Pod, add thecloud.google.com/compute-class:Performance label to your manifest. For details, seeOptimizeAutopilot Pod performance by choosing a machineseries.

Or, you can use theScale-Out label with thearm64 label to requestT2A.You can also request Arm architecture forSpot Pods.

When you deploy your workload, Autopilot does the following:

  1. Automatically provisions Arm nodes to run your Pods.
  2. Automatically taints the new nodes to prevent non-Arm Pods from beingscheduled on those nodes.
  3. Automatically adds a toleration to your Arm Pods to allow scheduling onthe new nodes.

Example request for Arm architecture

The following example specifications show you how to use a node selector or anode affinity rule to request Arm architecture in Autopilot.

nodeSelector

The following example manifest shows you how to request Arm nodes in anodeSelector:

apiVersion:apps/v1kind:Deploymentmetadata:name:nginx-armspec:replicas:3selector:matchLabels:app:nginx-armtemplate:metadata:labels:app:nginx-armspec:nodeSelector:cloud.google.com/compute-class:Performancekubernetes.io/arch:arm64containers:-name:nginx-armimage:nginxresources:requests:cpu:2000mmemory:2Gi

nodeAffinity

You can usenode affinityto request Arm nodes. You can also specify the type of node affinity to use:

  • requiredDuringSchedulingIgnoredDuringExecution: Must use the specifiedcompute class and architecture.
  • preferredDuringSchedulingIgnoredDuringExecution: Use the specifiedcompute class and architecture on a best-effort basis. For example, if anexisting x86 node is allocatable, GKE places your Pod onthe x86 node instead of provisioning a new Arm node. Unless you're using amulti-arch image manifest, your Pod will crash. We strongly recommend thatyou explicitly request the specific architecture that you want.

The following example manifestrequires thePerformance class and Armnodes:

apiVersion:apps/v1kind:Deploymentmetadata:name:nginx-armspec:replicas:3selector:matchLabels:app:nginx-armtemplate:metadata:labels:app:nginx-armspec:terminationGracePeriodSeconds:25containers:-name:nginx-armimage:nginxresources:requests:cpu:2000mmemory:2Giephemeral-storage:1Giaffinity:nodeAffinity:requiredDuringSchedulingIgnoredDuringExecution:nodeSelectorTerms:-matchExpressions:-key:cloud.google.com/compute-classoperator:Invalues:-Performance-key:kubernetes.io/archoperator:Invalues:-arm64

Recommendations

  • Build and use multi-arch imagesas part of your pipeline. Multi-arch images ensure that your Pods runeven if they're placed on x86 nodes.
  • Explicitly request architecture and compute classes in your workloadmanifests. If you don't, Autopilot uses the default architecture ofthe selected compute class, which might not be Arm.

Availability

You can deploy Autopilot workloads on Arm architecture inGoogle Cloud locations that support Arm architecture. For details, seeAvailable regions and zones.

Troubleshooting

For common errors and troubleshooting information, refer toTroubleshooting Arm workloads.

What's next

Except as otherwise noted, the content of this page is licensed under theCreative Commons Attribution 4.0 License, and code samples are licensed under theApache 2.0 License. For details, see theGoogle Developers Site Policies. Java is a registered trademark of Oracle and/or its affiliates.

Last updated 2026-02-18 UTC.