GKE: Standard vs Autopilot

GCP Basics · Containers & Serverless – Cloud Run, Cloud Run Functions, GKE and Cloud Build · Lesson 3 of 5

GKE runs managed Kubernetes; Autopilot manages nodes for you and bills per Pod, Standard gives full node control; use regional clusters, private nodes, release channels and Workload Identity Federation for GKE.

Google Kubernetes Engine (GKE) runs the Kubernetes control plane for you. In Autopilot mode Google also runs the nodes; in Standard mode you manage node pools.

flowchart TB
  DEV["kubectl apply"] --> CP["GKE control plane<br/>regional, managed by Google"]
  CP --> NP["Nodes: Autopilot managed<br/>or Standard node pools"]
  NP --> POD["Pods with KSA shop-api"]
  POD -- "Workload Identity Federation" --> GSA["IAM: read Cloud SQL, Pub/Sub"]
  CP --> UPG["Release channel Regular<br/>auto-upgrades in maintenance window"]
  %% step DEV: You deploy with kubectl, Helm or GitOps, exactly as on any Kubernetes cluster.
  %% step CP: The control plane (API server, etcd, scheduler) is run, patched and scaled by Google; regional clusters replicate it across three zones.
  %% step NP: Autopilot provisions nodes from your Pod requests; Standard lets you choose machine types and node pools.
  %% step POD: Pods run as Kubernetes service accounts.
  %% step GSA: Workload Identity Federation for GKE lets those Kubernetes service accounts get IAM permissions without keys.
  %% step UPG: Release channels upgrade control plane and nodes automatically within your maintenance windows.

Autopilot vs Standard

	Autopilot	Standard
Nodes	Managed by Google	You create and size node pools
Billing	Per Pod resource requests (vCPU, memory, storage)	Per node VM, used or not
Security	Hardened defaults (no privileged Pods, no SSH to nodes), Workload Identity on	You configure
Flexibility	Some restrictions (DaemonSets, node access)	Full control: GPUs, custom images, special kernels
Use	Default for most teams	Special hardware or node-level needs

Cluster design choices

Regional cluster (control plane and nodes across three zones) for production; zonal for cheap tests.
VPC-native networking with secondary ranges for Pods and Services (module 03).
Private nodes (no external IPs, egress via Cloud NAT) and a restricted control-plane endpoint (DNS-based endpoint or authorized networks).
Release channel (Rapid, Regular, Stable, Extended) plus maintenance windows and exclusions.
Workload Identity Federation for GKE instead of node service account keys.
Scaling: Horizontal Pod Autoscaler, Vertical Pod Autoscaler, cluster autoscaler / node auto-provisioning (Standard).
Gateway API and container-native load balancing connect Services to Cloud Load Balancing.

gcloud container clusters create-auto shop-gke --region=asia-southeast1   --network=vpc-shop --subnetwork=snet-gke --enable-private-nodes --release-channel=regular
gcloud container clusters get-credentials shop-gke --region=asia-southeast1
kubectl get nodes

Workload Identity Federation for GKE

gcloud projects add-iam-policy-binding dl-lab-prod --role=roles/cloudsql.client   --member="principal://iam.googleapis.com/projects/123456789/locations/global/workloadIdentityPools/dl-lab-prod.svc.id.goog/subject/ns/shop/sa/shop-api"

Command	Meaning
`gcloud container clusters list`	Clusters
`gcloud container node-pools create gpu-pool --cluster=… --accelerator=type=nvidia-l4,count=1`	GPU node pool (Standard)
`gcloud container clusters upgrade shop-gke --master --region=…`	Manual control-plane upgrade

Traps: Autopilot bills Pod requests, so oversized requests cost money; a zonal cluster’s control plane is unavailable during its upgrades; using the default Compute Engine service account for nodes gives Pods far too much access.