Kubernetes on GKE — Google Cloud Complete Guide 2026

Introduction

Why This Matters

Google Kubernetes Engine (GKE) is the managed Kubernetes service that Google itself uses to run Search, Gmail, and YouTube. It was the first major managed Kubernetes offering and remains the most feature-rich in 2026 — offering Autopilot mode, Workload Identity, multi-cluster gateways, and deep integration with Google Cloud services like Cloud SQL, Pub/Sub, and Secret Manager.

GKE is the top choice for teams that prioritize operational simplicity, cluster security, and Google's AI/ML ecosystem (TPU node pools, Vertex AI integration).

Prerequisites and Tooling

# Install Google Cloud CLI
curl https://sdk.cloud.google.com | bash
exec -l $SHELL
 
# Initialize and authenticate
gcloud init
gcloud auth application-default login
 
# Set project and region defaults
gcloud config set project my-project-id
gcloud config set compute/region us-central1
gcloud config set compute/zone us-central1-a
 
# Enable required APIs
gcloud services enable container.googleapis.com
gcloud services enable compute.googleapis.com
 
# Install kubectl via gcloud
gcloud components install kubectl
 
# Verify
gcloud version
kubectl version --client

GKE Autopilot vs Standard Mode

Feature	Autopilot	Standard
Node management	Google manages nodes	You manage nodes
Pricing	Per-pod resource	Per-node
Node customization	Limited	Full control
Best for	Simpler ops, cost efficiency	Custom node configs, GPUs
Security defaults	Hardened by default	Manual hardening needed

Autopilot is recommended for most production workloads in 2026 — Google manages capacity, patching, and scaling automatically.

Creating a GKE Autopilot Cluster

# Create an Autopilot cluster (recommended for most workloads)
gcloud container clusters create-auto my-cluster \
  --region us-central1 \
  --release-channel regular
 
# Get credentials and configure kubectl
gcloud container clusters get-credentials my-cluster --region us-central1
 
# Verify the cluster
kubectl get nodes
kubectl cluster-info

Creating a GKE Standard Cluster

For workloads requiring custom node configurations, GPUs, or spot instances:

# Create a Standard cluster with a custom node pool
gcloud container clusters create my-standard-cluster \
  --region us-central1 \
  --release-channel regular \
  --num-nodes 3 \
  --machine-type e2-standard-4 \
  --disk-size 100 \
  --enable-autoscaling \
  --min-nodes 1 \
  --max-nodes 10 \
  --enable-ip-alias \
  --workload-pool=my-project-id.svc.id.goog \
  --enable-shielded-nodes \
  --no-enable-basic-auth
 
# Add a spot node pool for cost savings
gcloud container node-pools create spot-pool \
  --cluster my-standard-cluster \
  --region us-central1 \
  --machine-type e2-standard-4 \
  --spot \
  --num-nodes 0 \
  --enable-autoscaling \
  --min-nodes 0 \
  --max-nodes 20

Workload Identity

Workload Identity is GKE's native way to give Kubernetes pods access to Google Cloud APIs without managing service account keys.

# Create a Google Cloud Service Account
gcloud iam service-accounts create my-app-sa \
  --display-name "My App Service Account"
 
# Grant it Cloud Storage permissions
gcloud projects add-iam-policy-binding my-project-id \
  --member "serviceAccount:my-app-sa@my-project-id.iam.gserviceaccount.com" \
  --role "roles/storage.objectViewer"
 
# Bind the GCP SA to a Kubernetes SA
gcloud iam service-accounts add-iam-policy-binding \
  my-app-sa@my-project-id.iam.gserviceaccount.com \
  --role roles/iam.workloadIdentityUser \
  --member "serviceAccount:my-project-id.svc.id.goog[my-namespace/my-ksa]"
 
# Create the Kubernetes Service Account with annotation
kubectl create serviceaccount my-ksa -n my-namespace
kubectl annotate serviceaccount my-ksa \
  -n my-namespace \
  iam.gke.io/gcp-service-account=my-app-sa@my-project-id.iam.gserviceaccount.com

Use the annotated my-ksa service account in your Pod spec — the Google Cloud client libraries automatically use the bound identity.

GKE Ingress and Load Balancing

GKE integrates with Google Cloud Load Balancing via the GKE Ingress controller.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-app-ingress
  namespace: my-app
  annotations:
    kubernetes.io/ingress.class: "gce"
    kubernetes.io/ingress.global-static-ip-name: "my-static-ip"
    networking.gke.io/managed-certificates: "my-cert"
spec:
  rules:
    - host: myapp.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: my-app-service
                port:
                  number: 80

Provision a static IP and managed certificate:

# Reserve a global static IP
gcloud compute addresses create my-static-ip --global
 
# Create a Google-managed SSL certificate
kubectl apply -f - <<EOF
apiVersion: networking.gke.io/v1
kind: ManagedCertificate
metadata:
  name: my-cert
  namespace: my-app
spec:
  domains:
    - myapp.example.com
EOF

Cluster Autoscaling and Node Auto-Provisioning

# Enable Node Auto-Provisioning on a Standard cluster
gcloud container clusters update my-standard-cluster \
  --region us-central1 \
  --enable-autoprovisioning \
  --min-cpu 4 \
  --max-cpu 100 \
  --min-memory 16 \
  --max-memory 400
 
# Cluster Autoscaler adjusts existing node pools automatically
# (enabled at cluster creation with --enable-autoscaling)
 
# Vertical Pod Autoscaler for resource recommendation
kubectl apply -f https://github.com/kubernetes/autoscaler/releases/latest/download/vertical-pod-autoscaler.yaml

Useful GKE Operations

# List all clusters in a region
gcloud container clusters list --region us-central1
 
# Upgrade cluster control plane
gcloud container clusters upgrade my-standard-cluster \
  --region us-central1 \
  --master
 
# Upgrade a node pool
gcloud container clusters upgrade my-standard-cluster \
  --region us-central1 \
  --node-pool default-pool
 
# Resize a node pool manually
gcloud container clusters resize my-standard-cluster \
  --num-nodes 5 \
  --region us-central1 \
  --node-pool default-pool
 
# Delete a cluster
gcloud container clusters delete my-cluster --region us-central1

Common Mistakes

Choosing Standard when Autopilot fits — Autopilot covers 90% of production workloads with less operational overhead and better security defaults.
Not enabling Workload Identity — storing service account JSON keys in Secrets is a security risk; Workload Identity eliminates the need for keys entirely.
Using zonal clusters for production — always create regional clusters (spread across 3 zones) to survive zone outages.
Ignoring release channels — use the regular channel for production; it provides tested, stable minor version upgrades with no manual intervention.
Not setting resource requests — in Autopilot mode, pods without resource requests are rejected; in Standard mode, they break the Cluster Autoscaler.

Best Practices

Use Autopilot for new clusters — it enforces security best practices by default (no privileged containers, read-only root filesystem) and bills per pod.
Enable Binary Authorization — require all container images to be signed and verified before deployment to prevent supply chain attacks.
Use Container Registry or Artifact Registry — store images in Google Artifact Registry for tight IAM integration and vulnerability scanning.
Enable GKE Dataplane V2 — uses eBPF for networking with built-in network policy enforcement and observability.
Leverage Google-managed certificates — they auto-provision and renew TLS certificates for GKE Ingress without manual cert management.

Key Takeaways

GKE Autopilot manages nodes, patching, and scaling automatically — recommended for most production workloads in 2026.
Workload Identity eliminates the need for service account key files by binding Kubernetes Service Accounts to Google Cloud Service Accounts.
Regional clusters (3 zones) provide high availability; zonal clusters have a single control plane and are only appropriate for dev/test.
GKE Ingress with Google-managed certificates provides fully automated TLS provisioning tied to a global load balancer.
The regular release channel delivers stable Kubernetes minor version upgrades automatically without manual patching.
Node Auto-Provisioning in Standard mode creates new node pools of the right machine type when pods cannot be scheduled.
Always set resource requests and limits — required in Autopilot and needed for accurate Cluster Autoscaler decisions in Standard mode.
Binary Authorization and Shielded Nodes enforce supply chain security at the cluster level with minimal configuration overhead.

Introduction#

Why This Matters#

Prerequisites and Tooling#

GKE Autopilot vs Standard Mode#

Creating a GKE Autopilot Cluster#

Creating a GKE Standard Cluster#

Workload Identity#

GKE Ingress and Load Balancing#

Cluster Autoscaling and Node Auto-Provisioning#

Useful GKE Operations#

Common Mistakes#

Best Practices#

Key Takeaways#

Related reading