Deploying to GKE Autopilot vs Standard Mode

Overview and What You Will Learn

In this lab, you will create both an Autopilot and a Standard mode GKE cluster, deploy the same simple application to each, and directly compare what each mode requires you to manage versus what Google handles automatically.

Why This Matters in Production

A small platform team adopts GKE Standard mode and spends significant ongoing effort sizing node pools, patching node OS versions, and tuning cluster autoscaling parameters - work that Autopilot would have handled entirely on their behalf, for a workload that never actually needed the specific node-level control Standard mode provides.

Core Principles

Both modes run the same Kubernetes API and accept the same workload definitions, but they differ fundamentally in who manages the underlying compute nodes.

Detailed Step-by-Step Practical Lab

1. Create a project and enable GKE:

2. Create an Autopilot cluster - notice no node pool configuration is specified at all:

3. Create a Standard mode cluster, explicitly specifying node pool configuration:

4. Deploy the same simple application to both clusters:

5. Compare node visibility between the two clusters:

Note

In Autopilot, you cannot directly SSH into or manage individual nodes the way you can in Standard mode - Google manages the node layer entirely, which is precisely the trade-off Autopilot makes for reduced operational overhead.

6. Check how each cluster is billed differently by reviewing the cluster's node pool configuration:

7. Clean up:

Production Best Practices & Common Pitfalls

Common Mistake

Choosing Standard mode by default out of familiarity with managing Kubernetes nodes directly, without checking whether the workload actually needs node-level control - like specific node taints, custom kernel parameters, or GPU node pools with fine-grained configuration - that Autopilot doesn't expose.

Tip

Start new GKE workloads on Autopilot unless a specific, concrete reason requires Standard mode's node-level control. Autopilot's per-pod billing model and zero node management overhead make it the lower-effort default for most containerized workloads.

• Autopilot enforces certain security and configuration best practices by default that Standard mode leaves as configuration choices - like disabling legacy metadata endpoints and requiring Workload Identity for pod-to-GCP-API authentication, rather than allowing a less secure default.
• Standard mode remains the right choice for workloads needing very specific node configurations - GPU workloads with precise driver requirements, DaemonSets needing privileged node access, or cost optimization strategies requiring exact control over node bin-packing density.

Quick Reference & Troubleshooting Commands