You can useComputeClasses to run Google Kubernetes Engine (GKE)Autopilot workloads in your GKE Standard modeclusters. This document describes the methods that you can use to run yourworkloads in Autopilot mode and helps you to decide when to run aworkload in a specific mode.

This information is intended for the following people:

• Cloud architects who want to optimize operational costs inorganizations.
• Platform administrators who want to reduce the overhead of manualinfrastructure management.
• Site reliability engineers (SREs) who want to shift infrastructuremaintenance, upgrades, and scaling to Google Cloud when possible.

You should already be familiar with the following concepts:

• Autopilot mode
• ComputeClasses

About GKE Autopilot

Autopilot is amode of operation in GKE in whichGoogle manages your node infrastructure, scaling, security, and pre-configuredfeatures. Autopilot mode is optimized for running most productionworkloads in an environment that applies recommended settings for security,reliability, performance, and scalability. To decide between Autopilotmode and Standard mode based on your requirements, seeAbout GKE modes of operation.

You can use Autopilot mode in the following ways:

• Create a cluster that uses Autopilotmode:Google manages the entire cluster and applies best practices for automation,reliability, security, and costs.
• Run workloads in Autopilot mode in Standard clusters:you deploy Autopilot ComputeClasses and select them in workloads.Google manages the nodes that GKE creates for those specificworkloads in anAutopilot-managed nodepool. Youcontrol the cluster and can run your own Standard node poolsalongside the nodes that GKE manages.

About Autopilot mode for ComputeClasses

A ComputeClass is a Kubernetes custom resource that defines a list of nodeconfigurations, like machine types or feature settings. You can select specificComputeClasses in Kubernetes workload specifications. When a workload thatselects a ComputeClass needs a new node, GKE attempts toprovision the node with one of the configurations that the ComputeClassdeclares. GKE tries each configuration in the ComputeClass inorder and falls back to the next configuration if node creation fails. For moreinformation, seeAbout custom ComputeClasses.

To run Autopilot workloads in your GKE Standardclusters, you enable Autopilot mode in a ComputeClass and select thatComputeClass in specific workloads. Google manages any new nodes thatGKE provisions for these workloads, similar to how Google managesthe nodes in Autopilot clusters. Most of the benefits and securityfeatures of Autopilot mode apply to those workloads and the host nodes.

Autopilot mode ComputeClasses provide cluster administrators withadditional flexibility to choose the level of control that you want overspecific workloads and infrastructure in your cluster, such as in the followingways:

• You can let GKE fully manage specific workloads by running themin Autopilot mode.
• You retain full control over workloads and infrastructure that don't useAutopilot mode, such as manually created node pools.
• You can set an Autopilot ComputeClass as thedefault for your cluster or namespace,so that workloads run in Autopilot mode unless they explicitlyrequest a different option.

These options let cluster admins decide on the level and the scope with whichthey use Autopilot.

Benefits of Autopilot ComputeClasses in Standard clusters

Running some of your workloads in Autopilot mode provides benefitslike the following:

• Reduce infrastructure management costs: Google upgrades, maintains,configures, and fine-tunes specific nodes for you.
• Use the Autopilot pricing model: workloads that use anAutopilot ComputeClass are billing using the Autopilotpricing model. This pricing model includes per-Pod billing for workloadsthat don't request specific hardware. For more information, see thePricing section.
• Improve scaling and security posture:Autopilot workloads get benefits like access to thecontainer-optimized compute platform,improved default security constraints, and node autoscaling based on resourcerequests. The nodes for those workloads use features like node auto-upgradesand automatic repairs.
• Improve reliability: the GKEservice-level agreement (SLA)includes a Pod uptime service-level objective (SLO) for Autopilot.

Many of these benefits are also provided by Autopilot clusters, whichalso provide a more managed experience than Standard clusters andinclude multiple security, networking, and resource management benefits. Formore information, seeAutopilot overview.

Hardware selection in Autopilot ComputeClasses

In Autopilot ComputeClasses, you can select specific hardware for yournodes (like GPUs or machine types), or you can let GKE place Podson a general-purpose, container-optimized compute platform. The general-purposeoption is recommended for most production workloads that don't require specifichardware to run well.

The following table describes these configuration options, how to choose one ina ComputeClass, and how this choice affects your billing model:

Configuration of Autopilot in ComputeClasses

You can use Autopilot mode in a Standard cluster by using abuilt-in Autopilot ComputeClass that GKE provides,or by enabling Autopilot in any custom ComputeClass that you create.The following sections describe each option.

Built-in Autopilot ComputeClasses

GKE configures specific Autopilot ComputeClasses foryou. You canselect these built-in Autopilot classesin any eligible cluster. The built-in Autopilot ComputeClasses inStandard clusters use thepodFamily priority rule to run Pods onthe container-optimized compute platform. For more information, seeAbout built-in ComputeClasses in GKE.

Custom Autopilot ComputeClasses

You can enable Autopilot in any custom ComputeClass that you manage.This option is useful if your workloads have specific hardware requirements.Theautopilot field in theComputeClass custom resource lets you enable ordisable Autopilot in a specific ComputeClass.

To enable Autopilot in an existing ComputeClass, you must delete it,update the configuration, and then recreate the ComputeClass in your cluster.Your changes apply to any new nodes that GKE creates forworkloads that you deploy after you update the Autopilot ComputeClass.

For more information about enabling Autopilot in your customComputeClasses, seeSelect specific hardware for your Autopilot Pods.

Pricing

GKE Autopilot pricing applies to the nodes and workloadsthat GKE creates for an Autopilot ComputeClass. Thefollowing table describes the billing model that applies to differentAutopilot ComputeClass configurations in your Standard modeclusters.

Autopilot pricing applies only to the workloads and nodes that use anAutopilot ComputeClass. Your Standard mode cluster and anyother node pools that you run continue to useGKE Standard mode pricing.

Pre-configured settings for nodes managed by Autopilot

Before you enable Autopilot mode in your ComputeClasses, know what toexpect from the nodes that GKE creates to run theAutopilot workloads. Google configures specific features and securityconstraints in Autopilot nodes. As a result, workloads that deploy andfunction correctly in your Standard mode nodes might be rejected byAutopilot mode if they don't meet the security requirements ofAutopilot.

The following table describes the feature configurations that override thecorresponding settings in your Standard cluster. If a configurationisn't in this table, the Autopilot nodes use the Standardcluster setting. For example, Workload Identity Federation for GKE isn't in this table, whichmeans that the Workload Identity Federation for GKE setting of the Standard clusterapplies to the Autopilot nodes that GKE creates.

Resource requests for Autopilot workloads

For Autopilot workloads to run efficiently, GKE enforcescertain minimum and maximum values for CPU, memory, and ephemeral storagerequests in your Pods. GKE also applies default requests to Pods that don't explicitly request one of these resources.The specific values for the minimum, maximum, and default resource requirementsin GKE Autopilot workloads vary based on the type ofhardware that your Pods use.

For ephemeral storage, the default value if you don't request ephemeral storageis the same for all ComputeClasses and hardware selections. For moreinformation, seeDefault resource requests.

The following table provides links to the CPU and memory requirements for yourPod requests, depending on the type of hardware:

What's next

• Deploy workloads in Autopilot mode in Standard clusters
• About custom ComputeClasses