Managed vs Self-Managed Kubernetes on GCP: GKE Autopilot vs Standard

Simple explanation

There are three ways to run Kubernetes on GCP. They differ in how much Google manages for you.

Think of it like housing. Self-managed Kubernetes is building a house from raw materials: you pour the foundation, wire the electricity, and fix every leak yourself. GKE Standard is buying a house: the structure is solid and professionally built, but you handle the interior, the lawn, and the maintenance schedule. GKE Autopilot is renting a fully serviced apartment: you move in, arrange your furniture, and someone else handles everything from plumbing to landscaping.

• Self-managed Kubernetes means you install and run Kubernetes yourself on Compute Engine VMs. You own everything: the control plane, the worker nodes, upgrades, networking, certificates, and monitoring. Google provides the VMs. The rest is on you.
• GKE Standard means Google runs the Kubernetes control plane (API server, etcd, scheduler). You manage the worker nodes through node pools, choosing machine types, configuring autoscaling, and approving upgrades.
• GKE Autopilot means Google manages both the control plane and node operations. You define Pod specifications with resource requests, and Google provisions the right infrastructure automatically. This is the closest Kubernetes gets to a serverless experience.

What each option manages

How it works

Self-managed: you own every component

Running Kubernetes on Compute Engine VMs means installing and operating the full stack yourself. The control plane (API server, etcd, scheduler, controller manager) runs on VMs you provision. etcd is the cluster’s state store. If it goes down, nothing schedules. A highly available etcd cluster needs at least 3 nodes spread across failure domains.

You choose and install a CNI plugin (Calico, Cilium, Flannel) for pod networking, generate and rotate TLS certificates for all components, provision worker VMs with the kubelet and container runtime, and run every Kubernetes upgrade manually. A version upgrade means draining nodes, upgrading packages, and confirming pod rescheduling across control plane and workers, all without disrupting production traffic.

GKE Standard: managed control plane, your nodes

With GKE Standard, Google runs the entire control plane on managed infrastructure, redundant across zones. You never touch etcd, configure certificates, or worry about API server availability.

You manage worker nodes through node pools: choose machine types, set autoscaling policies, attach GPUs, and select OS images. GKE can auto-upgrade nodes on a release channel (Rapid, Regular, or Stable) during maintenance windows you define. VPC-native networking is the default, so Pod IPs are real VPC addresses and Pods communicate with other GCP services natively.

# Create a GKE Standard cluster with auto-upgrade enabled
gcloud container clusters create my-cluster \
  --region us-central1 \
  --num-nodes 2 \
  --machine-type e2-standard-2 \
  --release-channel regular \
  --enable-autoupgrade \
  --enable-autorepair \
  --project my-project

GKE Autopilot: workload-first model

GKE Autopilot removes node management entirely. You define Pod specifications with resource requests and limits. Google provisions the right node capacity, handles bin-packing, runs upgrades, and enforces security guardrails automatically.

Autopilot enforces security policies by default: containers must declare resource requests, host namespace access is restricted, and most privileged containers are blocked. Google maintains an allowlist for partner workloads (monitoring agents, security tools) that need elevated permissions. Billing is per Pod resource request, so Pods not running cost nothing.

# Create a GKE Autopilot cluster
gcloud container clusters create-auto my-autopilot-cluster \
  --region us-central1 \
  --project my-project

Three-way comparison

When to use each option

When GKE Autopilot is the right choice

Autopilot is the right default for most Kubernetes workloads on GCP. Choose it when:

• You are running standard stateless or stateful web services and do not need custom node configurations
• Your team wants to focus on deploying applications, not managing infrastructure
• Workloads are bursty and Autopilot’s per-Pod billing keeps idle costs at zero
• You want hardened security defaults without manually configuring Pod Security Standards
• You are running microservices that use standard Kubernetes Deployments, Services, and Ingress
• You want monitoring and logging integrated by default

Example: A team running 5 microservices behind an HTTP load balancer with a Cloud SQL backend. Autopilot provisions exactly the capacity needed, auto-upgrades the cluster, and bills only for the Pods that are running.

When GKE Standard is the right choice

GKE Standard gives you full control over nodes while Google handles the control plane. Choose it when:

• You need GPU-attached nodes for ML training or inference workloads
• Your monitoring or security agents require DaemonSets with privileged access (and are not on Autopilot’s allowlist)
• You need custom machine types, specific OS images (e.g., Ubuntu instead of Container-Optimized OS), or kernel parameter tuning
• You are running workloads that require host networking or specific Linux capabilities Autopilot restricts
• You need fine-grained control over node pool placement, taints, and tolerations
• You want to use private clusters with full control over node network configuration

Example: An ML platform team running training jobs on A100 GPU nodes alongside a CPU node pool for API servers, with a custom Prometheus agent DaemonSet that requires host-level metrics access.

Rare cases where self-managed Kubernetes still makes sense on GCP

Self-managed Kubernetes on Compute Engine is almost always the wrong choice when GKE is available. The engineering cost of operating your own control plane (etcd management, certificate rotation, manual upgrades, CNI maintenance) is substantial and ongoing. But there are narrow exceptions:

• Custom Kubernetes distributions: Your organisation standardises on OpenShift, RKE2, or k3s and needs that specific distribution running on GCP infrastructure.
• Multi-cloud operational consistency: You run an identical Kubernetes toolchain across AWS, Azure, and GCP and need the same bootstrap process everywhere for operational uniformity.
• Control plane customisation: You need API server flags, custom admission controllers, or scheduler configurations that GKE does not expose.
• Regulatory or air-gapped requirements: Specific compliance frameworks require full control over every cluster component, including the control plane, for audit purposes.

If none of these apply, use GKE. For multi-cloud Kubernetes with a managed control plane, consider Google Distributed Cloud (formerly Anthos) before resorting to raw self-managed clusters.

Autopilot vs Standard: the GKE decision

Most teams comparing managed Kubernetes options on GCP are choosing between these two GKE modes, not considering self-managed. Here is the short version:

Start with Autopilot. It provides the full Kubernetes API, removes all node management, and bills per Pod resource request. For standard web services, APIs, batch jobs, and stateful workloads, Autopilot handles everything.

Move to GKE Standard when you hit a specific Autopilot limitation:

• You need GPU node pools for ML workloads
• Your workload requires privileged containers or host-level access that Autopilot blocks
• You need custom machine types or OS images not available in Autopilot
• You want to run Windows Server containers
• Your DaemonSets or system agents are not on Autopilot’s partner allowlist

Cost considerations

Self-managed: cheap on paper, expensive in practice

Self-managed Kubernetes costs only VM time on the invoice. But the hidden cost is engineering time. A production-grade self-managed cluster needs at least 3 control plane VMs for etcd quorum, plus dedicated time for upgrades, certificate rotation, backups, and incident response. For most organisations, the fully loaded cost of engineering hours far exceeds any GKE management fee.

GKE Standard: cluster fee plus node costs

GKE Standard charges a cluster management fee for the managed control plane, plus standard Compute Engine pricing for the worker node VMs. Check the current GKE pricing page for the latest rates. Google periodically adjusts fees and free-tier eligibility. Node costs scale with the machine types and node count you choose, and Committed Use Discounts apply to nodes.

GKE Autopilot: pay for what your Pods use

Autopilot bills based on the CPU and memory your Pods request. You do not pay for idle node capacity, only for Pods that are scheduled. For bursty workloads with variable traffic, Autopilot is often cheaper than Standard because there is no over-provisioned node capacity sitting idle. For workloads running at consistently high utilisation around the clock, costs are comparable to a well-tuned Standard cluster.

The real cost comparison

When comparing costs, include operational overhead, not just the invoice. GKE Autopilot reduces cost in engineering hours spent on node management, upgrade planning, and capacity tuning. GKE Standard gives you more levers to optimise (spot VMs, committed use discounts, right-sizing node pools) but requires the expertise to use them. Self-managed clusters have the highest operational cost by far.