GKE Autopilot Internals: What Google Actually Runs for You

The invoice was $4,870. For a *staging* cluster. The dev cluster, maybe 60 deployments mostly idle at 3 AM, had tripled over two quarters while nobody watched. I cross-referenced requests against actual usage and found the culprit in ten minutes: a fleet of tiny Go services whose Helm charts defaulted to cpu: 500m, memory: 2Gi — requests nobody had questioned because "Standard just bin-packs it."

On Autopilot, that default *is* the bill.

Quick answer: GKE Autopilot bills per pod on resource requests (with enforced minimums, rounding, and limits forced equal to requests), then provisions whatever nodes fit — you never see the packing efficiency, so sloppy requests are pure margin for Google. Compute classes are the real node API for picking Arm, Spot, or GPU capacity. Upgrades are mandatory and PDB-gated but not PDB-vetoable, and there's no in-place conversion back to Standard. Autopilot is excellent for well-tuned, spiky workloads and quietly 2x for idle, over-requested ones.

The billing model is the product

Autopilot's core mechanic: you're charged for pod resource *requests* per second; Google handles bin-packing. CPU requests round up to the nearest 0.25 vCPU. If a container declares no requests, Autopilot injects defaults — 500m CPU and 2 GiB memory for the Balanced class. Minimums are 250m CPU and 512 MiB memory, and the CPU-to-memory ratio must sit between 1:1 and 1:6.5 or admission rejects the pod.

The detail that changes how you write specs: Autopilot sets limits equal to requests. Always. Your pods run effectively Guaranteed QoS, which means no bursting. A JVM that spikes to 2x steady-state CPU at startup gets throttled until you raise the request, then you pay for spike capacity forever.

resources:
  requests:
    cpu: "250m"        # rounds to 0.25 vCPU, billed 24/7
    memory: "512Mi"    # minimum for Balanced
    ephemeral-storage: "1Gi"  # yes, this is billed too

That last line is real: ephemeral-storage requests are metered per GiB-hour, which surprised one team I know when a log-spewing debug deployment showed up on the invoice.

Compute classes are the real node API

"No node pools" doesn't mean no node choice. The cloud.google.com/compute-class node selector is Autopilot's provisioning API:

Class	Hardware	When to reach for it
Balanced (default)	x86, general purpose	Everything boring
Scale-Out	Arm (T2A), one pod per node	Web-tier replicas, per-pod isolation
Performance	C-family, high clock	Latency-sensitive workloads
Accelerator	T4/L4/A100/H100	GPU inference and training
Spot	Preemptible, steep discount	Batch, CI runners, anything retryable

Two things bite. First, Scale-Out runs one pod per node by design, great for noisy-neighbor isolation, terrible if you assumed density. Second, Spot pods get roughly 25 seconds of termination notice; if your shutdown takes 60 seconds, Spot SIGKILLs you mid-request.

GPU pods bill for the whole GPU plus pod resources; drivers install automatically, but you can't touch containerd config or kernel parameters. If your inference stack needs a vm.max_map_count bump, you're filing a feature request, not a PR.

What "no node management" actually means

The nodes exist. kubectl get nodes shows them, named gk3-* on Dataplane V2 clusters (Cilium underneath, which is why network policy just works). You can't SSH in, can't taint them, can't run privileged anything. Admission rejects hostNetwork: true, hostPID, capabilities like SYS_ADMIN, and most hostPath volumes.

DaemonSets have improved, unprivileged user DaemonSets work on recent versions, but your vendor agent still has to fit inside those constraints. I've watched a monitoring vendor's eBPF agent get rejected at admission for three sprints before we swapped to their approved partner build. Google's own per-node DaemonSets bill like any pod, so agent overhead that amortized across a fat Standard node now bills out per pod.

Upgrades roll through whether you're ready or not

Node auto-upgrade is on, permanently. You steer with release channels, maintenance windows, and exclusions, but the train doesn't stop. GKE surge-provisions a fresh node, drains the old one, and respects your PDBs, for about an hour. Then it evicts anyway.

I got paged for exactly this: a singleton in-memory cache, replicas: 1, maxUnavailable: 0 on the PDB, sitting in a cluster mid-upgrade. The drain stalled, the hour elapsed, the pod died, and every request during the cold-cache window timed out. The fix wasn't fighting the upgrade; it was accepting that singletons without graceful failover are a self-inflicted wound on Autopilot. The PDB won't save you.

During maintenance windows I keep conndeck open on the node view, watching surge nodes appear and drains complete in real time beats refreshing kubectl get nodes -w over VPN.

The escape hatch that isn't

There is no "convert to Standard" button. The autopilot flag is fixed at creation, both directions. Migrating out means a new cluster, redeploying from your GitOps repo, and a DNS or load balancer cutover, a long afternoon for stateless services, a real migration project for anything holding local state. Don't let a proof-of-concept Autopilot cluster become load-bearing by accident.

Where Autopilot quietly costs 2x

The raw premium is around 30-40% per vCPU-hour versus equivalent on-demand n2/e2 capacity. That alone is fine, you're buying operations. It becomes 2x through composition:

1. Over-requested, idle workloads. Standard absorbs slack in shared node headroom; Autopilot bills every requested millicore forever. A service requesting 1 vCPU that uses 80m costs 12x its actual consumption.
2. Tiny pods hitting minimums and defaults. A 100m-CPU sidecar gets billed at 250m. A chart defaulting to 2 GiB gets billed at 2 GiB. Multiply across 60 dev deployments and you get my staging invoice.
3. Agents and sidecars. Log shippers and APM agents that amortized as one DaemonSet on Standard now bill their full request per node, and every mesh sidecar carries a 250m floor, 200 meshed pods means 50 vCPU of sidecar before your app does anything.

The counterpoint is real: spiky, right-sized workloads often come out *cheaper* on Autopilot because you stop paying for the 30% node headroom and kube-system overhead Standard makes you carry. The tool isn't expensive. Sloppy requests on it are.

Frequently asked questions

Is GKE Autopilot more expensive than Standard?

Per unit of compute, yes: Autopilot's Balanced class is roughly 30-40% more per vCPU-hour than equivalent n2 or e2 on-demand capacity, and you're billed on pod requests, not usage. For tightly packed, well-tuned workloads the premium can be offset by not paying for node headroom and idle kube-system overhead. For idle or over-requested workloads, the gap regularly reaches 2x because you pay for every millicore you asked for around the clock.

Can you convert a GKE Autopilot cluster to Standard?

No. There is no in-place conversion in either direction; the autopilot flag is fixed at cluster creation. The escape hatch is provisioning a new Standard cluster and migrating workloads with your GitOps repo or backup tooling, which is mostly painless for stateless apps and a real project for anything holding local state. Treat the Autopilot decision as one-way and prototype there accordingly.

Does GKE Autopilot support DaemonSets?

Yes, but only unprivileged user DaemonSets since roughly GKE 1.29, and they run under tight constraints: no host namespaces, no hostPath outside an allowlist, and no extra Linux capabilities. Google also runs its own DaemonSets you can't touch, and several vendor agents ship as approved partner deployments. If your observability agent needs NET_ADMIN, hostNetwork, or host mounts for eBPF, it will be rejected at admission.

How do upgrades work in GKE Autopilot?

Nodes auto-upgrade on the cluster's release channel cadence and you can't disable it, only steer timing with maintenance windows and exclusions. GKE surge-provisions replacement nodes, drains the old ones, and honors your PodDisruptionBudgets during the drain. If a PDB blocks eviction for about an hour, GKE force-evicts anyway, so PDBs slow the rollout but never veto it.

If you remember one thing

Autopilot isn't "Kubernetes without nodes." It's Kubernetes where the node decisions moved into your pod specs and your invoice. Right-size requests from real usage data, pick compute classes on purpose, design for eviction because upgrades don't negotiate, and it's a genuinely good deal. Skip it, and you'll meet your resource requests again: line-item by line-item, at the end of the quarter.