Google GKE

Summary

• Definition: GKE is Google Cloud's managed Kubernetes, offered in two modes - Autopilot, where Google manages nodes per pod, and Standard, where you manage node pools.
• Insight: GKE ships the most opinionated defaults of the big three, so the fastest safe cluster is usually an Autopilot cluster on the regular release channel.
• Key Concepts: Autopilot vs Standard, Workload Identity Federation, release channels, node auto-provisioning, GKE Dataplane V2.
• When to Use: Pick GKE when you want strong defaults, fast upgrades, and the least node toil, especially on a small platform team.
• Limitations: Autopilot blocks privileged pods and most DaemonSet patterns; per-pod billing punishes idle over-requesting.

Recipe

Create an Autopilot cluster on a release channel and let Google handle nodes.

gcloud container clusters create-auto prod \
  --region us-central1 \
  --release-channel regular

For Standard mode, you choose the node pool shape yourself:

gcloud container clusters create prod-std \
  --region us-central1 \
  --release-channel regular \
  --enable-dataplane-v2 \
  --workload-pool=my-project.svc.id.goog \
  --num-nodes 2

Fetch credentials and confirm the node runtime:

gcloud container clusters get-credentials prod --region us-central1
kubectl get nodes -o wide

The CONTAINER-RUNTIME column reports containerd. Docker is your build tool, not the node runtime.

Working Example

Give a pod scoped Google Cloud permissions with Workload Identity Federation, no service account keys involved.

Bind the Kubernetes ServiceAccount to an IAM service account:

gcloud iam service-accounts add-iam-policy-binding \
  gcs-reader@my-project.iam.gserviceaccount.com \
  --role roles/iam.workloadIdentityUser \
  --member "serviceAccount:my-project.svc.id.goog[payments/gcs-reader]"

Annotate the ServiceAccount and run the workload under it:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: gcs-reader
  namespace: payments
  annotations:
    iam.gke.io/gcp-service-account: gcs-reader@my-project.iam.gserviceaccount.com
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: reporter
  namespace: payments
spec:
  replicas: 2
  selector:
    matchLabels: { app: reporter }
  template:
    metadata:
      labels: { app: reporter }
    spec:
      serviceAccountName: gcs-reader
      containers:
        - name: reporter
          image: us-docker.pkg.dev/my-project/apps/reporter@sha256:abc
          securityContext:
            runAsNonRoot: true
            allowPrivilegeEscalation: false
            capabilities:
              drop: ["ALL"]
          resources:
            requests: { cpu: "100m", memory: "128Mi" }
            limits: { cpu: "500m", memory: "256Mi" }

The metadata server exchanges the pod's ServiceAccount token for short-lived Google credentials. Nothing long-lived is mounted.

Deep Dive

Autopilot vs Standard

Autopilot removes node pools from your mental model. You submit pods, Google provisions and patches the compute, and you are billed for pod requests rather than node hours.

Standard keeps node pools visible and configurable, which you need for GPUs with custom drivers, privileged agents, or specific machine families.

Autopilot enforces hardened defaults - no privileged containers, no host namespaces, no arbitrary hostPath mounts - so it is effectively Pod Security Standards restricted with guardrails you cannot forget to turn on.

The practical rule: start on Autopilot, and move to Standard only when a concrete requirement forces it.

Workload Identity Federation

Workload Identity Federation is the only sanctioned way to reach Google APIs from a pod. It maps namespace/serviceaccount pairs to IAM service accounts through the cluster's workload identity pool.

Autopilot enables it by default. On Standard you pass --workload-pool at cluster creation and enable it per node pool.

The alternative - mounting a JSON service account key as a Secret - creates a long-lived credential that never rotates and leaks through backups. Do not do it.

Release channels

Channels control how fast your cluster tracks upstream Kubernetes. Rapid gets new minors first, Regular follows after bake time, Extended holds a version far longer for slow-moving compliance workloads.

Channels auto-upgrade the control plane and nodes within the channel's version window. Maintenance windows and exclusions constrain when, not whether.

Pin production to Regular. Run a Rapid cluster in staging so you meet deprecations before they reach prod.

Networking and Dataplane V2

GKE Dataplane V2 is an eBPF dataplane built on Cilium. It implements Services and NetworkPolicy without kube-proxy iptables churn, and adds network policy logging.

VPC-native clusters give pods routable alias IPs from a secondary subnet range. Size that pod range at creation - resizing it later is painful.

Private clusters put nodes on internal addresses only, with Private Service Connect or an authorized-networks list fronting the control plane endpoint.

Node auto-provisioning

On Standard, node auto-provisioning creates and deletes node pools automatically based on pending pod requirements, rather than only scaling pools you predefined.

It is the closest Standard equivalent to Autopilot's compute model, and a reasonable middle ground when you need some node control but not pool babysitting.

Gotchas

Autopilot rejects DaemonSets that need privilege or host access, so third-party security and log agents may need an Autopilot-certified build or a move to Standard.

Autopilot rounds and enforces resource requests, and bills on them. Over-requested pods cost real money immediately rather than showing up as low node utilization later.

Release-channel auto-upgrades will move your control plane. Set maintenance windows and PodDisruptionBudgets, or upgrades will surprise you during business hours.

The cluster's pod IP range is fixed at creation. Undersizing it caps cluster growth and forces a rebuild.

Deleting a Service of type LoadBalancer does not always reclaim static IPs or firewall rules you created out of band. Manage those in Terraform.

Alternatives

Use EKS when you are AWS-native and want IRSA or Pod Identity with VPC CNI addressing.

Use AKS when Microsoft Entra ID is your identity backbone and you want Entra-to-RBAC integration.

Stay on GKE Standard rather than Autopilot when you need GPUs with custom drivers, privileged DaemonSets, Windows nodes, or sole-tenant hardware.

FAQs

Is Autopilot just Standard with a different bill? No. Autopilot changes the responsibility line - Google owns node provisioning, patching, and security posture, and you lose node-level access in exchange.

Does GKE run Docker on nodes? No. GKE nodes run containerd via CRI. Docker builds the images you push to Artifact Registry.

Can I convert a Standard cluster to Autopilot? Not in place. Create a new Autopilot cluster and migrate workloads.

Which release channel should production use? Regular. It gets versions after bake time while still keeping you inside the supported minors.

Do I still need NetworkPolicy on Autopilot? Yes. Autopilot hardens pod security, not east-west traffic. Default-deny policies remain your job.

What replaces service account keys? Workload Identity Federation. Keys should not exist in a modern GKE cluster.

Related

• Amazon EKS
• Azure AKS
• Cloud Selection ADR
• What "Managed" Does and Doesn't Cover
• Managed K8s Best Practices

Stack versions: This page was written for Kubernetes 1.36.2, Docker Engine 29.6.1 (BuildKit default), containerd (CRI runtime on nodes), Helm 3, Compose v2, Argo CD (latest - verify at build), and Gateway API (GA - verify controller support at build).