This page shows you how to configure your Google Kubernetes Engine (GKE) Autopilot deployments to request nodes that are backed by Arm architecture.
About Arm architecture in Autopilot
Autopilot clusters offer
compute classes
for workloads that have specific hardware requirements. Some of these compute
classes support multiple CPU architectures, such as amd64 and arm64.
Use cases for Arm nodes
Nodes with Arm architecture offer more cost-efficient performance than similar x86 nodes. You should select Arm for your Autopilot workloads in situations 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 running your 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 then
initialize the
gcloud CLI. If you previously installed the gcloud CLI, get the latest
version by running the
gcloud components updatecommand. Earlier gcloud CLI versions might not support running the commands in this document.
- Review the requirements and limitations for Arm nodes.
- To use the
autopilot-armComputeClass, ensure that your cluster is running GKE version 1.35.3-gke.1389000 or later. - Ensure that you have quota for the C4A, N4A, or Tau T2A Compute Engine machine types.
- Ensure that you have a Pod with a container image that's built for Arm architecture.
How to request Arm nodes in Autopilot
To tell Autopilot to run your Pods on Arm nodes, use one of the following methods, depending on your requirements. You specify these using a nodeSelector or node affinity rule:
- For general-purpose workloads: Request the container-optimized Arm platform by specifying both of the following:
cloud.google.com/compute-class: autopilot-armkubernetes.io/arch: arm64
For workloads with specific hardware requirements: Specify one of the following:
kubernetes.io/arch: arm64. GKE places Pods onC4Amachine types by default for clusters running version 1.31.3-gke.1056000 and later. If the cluster is running an earlier version, GKE places Pods onT2Amachine types.cloud.google.com/machine-family: ARM_MACHINE_SERIES. ReplaceARM_MACHINE_SERIESwith an Arm machine series likeC4A,N4A, orT2A. GKE places Pods on the specified series.
By default, using any of the labels except Performance lets GKE
place other Pods on the same node if there's availability capacity on that node.
To request a dedicated node for each Pod, add the
cloud.google.com/compute-class: Performance label to your manifest alongside
the architecture or machine-family labels. For details, see
Optimize Autopilot Pod performance by choosing a machine
series.
Or, you can use the Scale-Out label with the arm64 label to request T2A.
You can also request Arm architecture for Spot Pods.
When you deploy your workload, Autopilot does the following:
- Automatically provisions Arm nodes to run your Pods.
- Automatically taints the new nodes to prevent non-Arm Pods from being scheduled on those nodes.
- Automatically adds a toleration to your Arm Pods to allow scheduling on the new nodes.
Example request for Arm architecture
The following example specifications show you how to use a node selector or a node affinity rule to request Arm architecture in Autopilot.
nodeSelector
The following example manifest requests an Autopilot container-optimized Arm node:
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-arm
spec:
replicas: 3
selector:
matchLabels:
app: nginx-arm
template:
metadata:
labels:
app: nginx-arm
spec:
nodeSelector:
cloud.google.com/compute-class: autopilot-arm
kubernetes.io/arch: arm64
containers:
- name: nginx-arm
image: nginx
resources:
requests:
cpu: 2000m
memory: 2Gi
To request specific hardware instead of Autopilot container-optimized nodes, replace
autopilot-arm with Performance or Scale-Out in the nodeSelector.
nodeAffinity
You can use node affinity to request Arm nodes.
The following example manifest requests an Autopilot container-optimized Arm node:
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-arm
spec:
replicas: 3
selector:
matchLabels:
app: nginx-arm
template:
metadata:
labels:
app: nginx-arm
spec:
terminationGracePeriodSeconds: 25
containers:
- name: nginx-arm
image: nginx
resources:
requests:
cpu: 2000m
memory: 2Gi
ephemeral-storage: 1Gi
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: cloud.google.com/compute-class
operator: In
values:
- autopilot-arm
- key: kubernetes.io/arch
operator: In
values:
- arm64
To request specific hardware instead of Autopilot container-optimized nodes, replace
autopilot-arm with Performance or Scale-Out in the nodeAffinity rules.
Recommendations
- Build and use multi-arch images as part of your pipeline. Multi-arch images ensure that your Pods run even if they're placed on x86 nodes.
- Explicitly request architecture and compute classes in your workload manifests. If you don't, Autopilot uses the default architecture of the selected compute class, which might not be Arm.
Availability
You can deploy Autopilot workloads on Arm architecture in
the following regions: us-east1, us-west1, and europe-west1.
Troubleshooting
For common errors and troubleshooting information, refer to Troubleshooting Arm workloads.
What's next
- Learn more about Autopilot cluster architecture.
- Learn about the lifecycle of Pods.
- Learn about the available Autopilot compute classes.
- Read about the default, minimum, and maximum resource requests for each platform.