This page describes the compute classes that you can use to run Google Kubernetes Engine (GKE) Autopilot workloads that have specific hardware requirements. For instructions, refer to Run Autopilot Pods on specific compute classes.
Overview of Autopilot compute classes
By default, GKE Autopilot Pods run on a compute platform that is optimized for general-purpose workloads such as web serving and medium-intensity batch jobs. This general platform provides a reliable, cost-optimized hardware configuration that can handle the requirements of most workloads.
If you have workloads that have unique hardware requirements, such as performing
machine learning or AI tasks, running real-time high traffic databases, or
needing specific CPU platforms and architecture, Autopilot offers
compute classes. These compute classes are a curated subset of the
machine series, and offer
flexibility beyond the default Autopilot compute class. For example,
Scale-Out compute class uses VMs that turn off simultaneous multi-threading and
are optimized for scaling out.
You can request nodes backed by specific compute classes based on the requirements of each of your workloads. Similar to the default general-purpose compute class, Autopilot manages the sizing and resource allocation of your requested compute classes based on your running Pods. You can request compute classes at the Pod-level to optimize cost-efficiency by choosing the best fit for each Pod's needs.
Choose a specific CPU architecture
If your workloads are designed for specific CPU platforms or architectures, you
can optionally select those platforms or architectures in your Pod
specifications. For example, if you want your Pods to run on nodes that use the
Arm architecture, you can choose
arm64 within the
Scale-Out compute class.
GKE Autopilot Pods are priced based on the nodes where the Pods are scheduled. For pricing information for general-purpose workloads and Spot Pods on specific compute classes, and for information on any committed use discounts, refer to Autopilot mode pricing.
Spot Pods on general-purpose or specialized compute classes do not qualify for committed use discounts.
When to use specific compute classes
The following table provides a technical overview of the compute classes that Autopilot supports and example use cases for Pods running on each platform. If you don't request a compute class, Autopilot places your Pods on the general-purpose compute platform, which is designed to run most workloads optimally. Autopilot changes the underlying machine types for a compute class over time if other configurations become available.
|Workload requirement||Compute class||Description||Example use cases|
|Workloads that don't require specific hardware||General-purpose||
Autopilot uses the general-purpose compute class if you don't request a different compute class in your Pod specification. You can't explicitly select this compute class.
|CPU or memory requests larger than the general-purpose compute class maximums or specific CPU platforms||
|Single thread-per-core computing and horizontal scaling||
How to select a compute class in Autopilot
For detailed instructions, refer to Choose compute classes for Autopilot Pods.To tell Autopilot to place your Pods on a specific compute class, specify the `cloud.google.com/compute-class` label in a nodeSelector or a node affinity rule, such as in the following examples:
apiVersion: apps/v1 kind: Deployment metadata: name: hello-app spec: replicas: 3 selector: matchLabels: app: hello-app template: metadata: labels: app: hello-app spec: nodeSelector: cloud.google.com/compute-class: "COMPUTE_CLASS" containers: - name: hello-app image: us-docker.pkg.dev/google-samples/containers/gke/hello-app:1.0 resources: requests: cpu: "2000m" memory: "2Gi"
COMPUTE_CLASS with the name of the
based on your use case, such as
apiVersion: apps/v1 kind: Deployment metadata: name: hello-app spec: replicas: 3 selector: matchLabels: app: hello-app template: metadata: labels: app: hello-app spec: terminationGracePeriodSeconds: 25 containers: - name: hello-app image: us-docker.pkg.dev/google-samples/containers/gke/hello-app:1.0 resources: requests: cpu: "2000m" memory: "2Gi" ephemeral-storage: "1Gi" affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: cloud.google.com/compute-class operator: In values: - "COMPUTE_CLASS"
COMPUTE_CLASS with the name of the
based on your use case, such as
When you deploy the workload, Autopilot does the following:
- Automatically provisions nodes backed by the specified configuration to run your Pods.
- Automatically adds taints to the new nodes to prevent other Pods from scheduling on those nodes. The taints are unique to each compute class. If you also select a CPU architecture, GKE adds a separate taint unique to that architecture.
- Automatically adds tolerations corresponding to the applied taints to your deployed Pods, which lets GKE place those Pods on the new nodes.
For example, if you request the
Scale-Out compute class for a Pod:
- Autopilot adds a taint specific to
Scale-Outfor those nodes.
- Autopilot adds a toleration for that taint to the
Pods that don't request
Scale-Out won't get the toleration. As a result,
GKE won't schedule those Pods on the
If you don't explicitly request a compute class in your workload specification, Autopilot schedules Pods on nodes that use the default general-purpose compute class. Most workloads can run with no issues on the general-purpose compute class.
How to request a CPU architecture
In some cases, your workloads might be built for a specific architecture, such as Arm. Some compute classes support multiple CPU architectures. You can request a specific architecture alongside your compute class request by specifying the following label in your node selector or node affinity rule, such as in the following example:
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: COMPUTE_CLASS kubernetes.io/arch: ARCHITECTURE containers: - name: nginx-arm image: nginx resources: requests: cpu: 2000m memory: 2Gi
ARCHITECTURE with the CPU architecture that you
want, such as
If you don't explicitly request an architecture, Autopilot uses the default architecture of the specified compute class.
Arm architecture on Autopilot
Autopilot supports requests for nodes that use the Arm CPU architecture. Arm nodes are more cost-efficient than similar x86 nodes while delivering performance improvements. For instructions to request Arm nodes, refer to Deploy Autopilot workloads on Arm architecture.
Ensure that you're using the correct images in your deployments. If your Pods use Arm images and you don't request Arm nodes, Autopilot schedules the Pods on x86 nodes and the Pods will crash. Similarly, if you accidentally use x86 images but request Arm nodes for the Pods, the Pods will crash.
Autopilot validations for compute class workloads
Autopilot validates your workload manifests to ensure that the compute class and architecture requests in your node selector or node affinity rules are correctly formatted. The following rules apply:
- No more than one compute class.
- No unsupported compute classes.
- The GKE version must support the compute class.
- No more than one selected architecture.
- The compute class must support the selected architecture.
If your workload manifest fails any of these validations, Autopilot rejects the workload.
Compute class regional availability
The following table describes the regions in which specific compute classes and CPU architectures are available:
|Compute class availability|
Arm architecture (
x86 architecture (
If a compute class is available in a specific region, the hardware is available in at least two zones in that region.
Default, minimum, and maximum resource requests
When choosing a compute class for your Autopilot workloads, make sure that you specify resource requests that meet the minimum and maximum requests for that compute class. For information about the default requests, as well as the minimum and maximum requests for each compute class, refer to Resource requests and limits in GKE Autopilot.
- Learn how to select specific compute classes in your Autopilot workloads.
- Read about the default, minimum, and maximum resource requests for each platform.