---
cuppy_hub: gcp
cuppy_path: reference/compute/gke-cluster-modes.md
cuppy_section: docs
cuppy_doc: 5XHJ-Y4R7
cuppy_doc_uuid: 213fae8a-f8bd-48f1-a57a-769b9a4578d9
cuppy_permalink: https://cuppy.io/gcp/d/5XHJ-Y4R7
cuppy_version: 1
cuppy_updated: 2026-10-23T16:16:52.575Z
cuppy_canonical: https://cuppy.io/gcp/docs/reference/compute/gke-cluster-modes
cuppy_mcp: https://cuppy.io/mcp
cuppy_body_sha256: 47cbf969a42af17898d752850013722fb96bcdd821642e35f7976d47d15dca94
# cuppy_body_sha256 is over the document body ALONE, excluding both generated blocks.
---


# GKE cluster modes

## 1. The two modes

**Autopilot** is "a managed experience in which GKE handles most of your infrastructure for you so that you can
focus on your applications."

**Standard** is the flexible mode: you control the node infrastructure and the autoscaling directly.

## 2. Who is responsible for what

| | Autopilot | Standard |
|---|---|---|
| cluster infrastructure | **GKE** | you |
| nodes and node pools | **GKE** | you — you configure node pools |
| scaling | **GKE**, with automatic bin-packing | you configure it |
| security posture | **GKE applies constraints by default**, and **prevents privileged Pods** | you set the policies |
| resource allocation | **GKE** | you |

## 3. What Autopilot will not run

Workloads that need special privileges, or granular infrastructure control that would violate Autopilot's
constraints. **"Prevents privileged Pods" is the clause to check a workload against first**, because it rules
out a recognisable class: node-level agents, some CSI and CNI add-ons, anything that wants host namespaces or
host paths, and several third-party security and observability products.

The page describes the restriction at that level and does not enumerate every forbidden field. So the design
step is: list the Pod specs that need privileges or host access, and check **those** against Autopilot's own
constraints page before choosing.

## 4. Billing dimension (never a price)

| Mode | Metered on |
|---|---|
| **Autopilot** | the **provisioned compute resources** your workloads request |
| **Standard** | the **node infrastructure** you create |

This is the most consequential difference for a cost estimate, and it is a difference in *what is counted*, not
in rate. On Standard you pay for nodes whether or not Pods fill them, so idle headroom is yours to pay for and
yours to tune. On Autopilot you pay for what the workloads request, so **over-requested Pod resources become a
direct bill** — a `requests` block copied from an on-premises cluster with generous margins is a real cost on
Autopilot and invisible on Standard.

A lift-and-shift onto Autopilot should therefore be preceded by a pass over every `resources.requests` in the
manifests. That pass is usually the largest single saving available in a Kubernetes migration onto Google
Cloud.

## 5. Google's recommendation, and when to override it

> "Use Autopilot for most workloads, unless your application requires privileges or configuration options that
> don't meet the Autopilot constraints."

Autopilot is labelled "recommended". The override condition is **capability, not scale** — nothing in the
recommendation is about cluster size.

## 6. An absence, recorded

The Workload Identity Federation for GKE page **does not state** whether the feature is enabled by default on
Autopilot clusters, so this document does not say so either. Check the cluster's own configuration
(`reference/identity/workload-identity-federation.md` §5). The cluster's pool name is always
`PROJECT_ID.svc.id.goog`.

Next: `guides/parity/compute.md` compares both modes to EKS, EKS Auto Mode and AKS.


---
<!-- cuppy -->
You are reading one file. The same content is free over MCP at https://cuppy.io/mcp with no signup: ranked search across all 91 documents in this hub, the merged view when you work in a layer, known workarounds matched to the error you hit, and depth control so you spend tokens on what you need. Start with the `_hello` tool. How to connect: https://cuppy.io/gcp/ Something wrong in this document? Report it with the `session feedback` tool on the same endpoint.
<!-- /cuppy -->
