Google Cloud Platform
Advanced 18 min read Google Cloud Platform

Google Kubernetes Engine (GKE)

GKE is managed Kubernetes on GCP: Google runs the control plane and you run the data plane as node pools. Learn node pools and autoscaling, Deployments, Services and Ingress, the Horizontal Pod Autoscaler, Workload Identity for IAM, and Artifact Registry for storing images.

GKEKubernetescontrol planenode poolAutopilotHPAIngressWorkload IdentityArtifact RegistryDeployment
Prerequisites: Compute Engine & IAM VPC & Networking
Introduction

What is this?

Google Kubernetes Engine (GKE) is managed Kubernetes on GCP. Google operates the highly available control plane — API server, etcd and scheduler — and you run the data plane as node pools of Compute Engine VMs, or let Autopilot manage the nodes entirely. You deploy workloads as Deployments, Services and Ingress objects, scale replicas with the Horizontal Pod Autoscaler, and grant pods GCP permissions with Workload Identity. Artifact Registry stores the container images nodes pull at deploy time.

Motivation

Why do you need it?

  • GKE is where Google runs Kubernetes internally, making it the most battle-tested managed K8s platform.
  • Managed node pools and Autopilot remove the operational burden of the control plane and node management.
  • Workload Identity gives pods scoped IAM permissions without storing keys.
  • Artifact Registry is the secure image store close to the cluster for fast, private pulls.
  • GKE plus HPA, Ingress and Workload Identity is the standard production pattern and a top interview topic.
Think about it

Mental model

Imagine

A hotel run by the parent brand

Think of

GKE and Artifact Registry

GKE is the hotel group: the building's core systems — elevators, boiler, security office (control plane) — are maintained by the brand. You staff the floors (node pools) or let Autopilot housekeeping run them for you. Your restaurant (app) books rooms (Pods) via the reservations desk (Deployment), and guests find it through the front desk (Service) and a doorman directing by name (Ingress). The pantry (Artifact Registry) holds every recipe (image); the chef's badge (Workload Identity) unlocks exactly the shelves it needs.

Mechanics

How it works

  • You create a cluster; GKE provisions a highly available managed control plane and node pools of Compute Engine VMs running containerd.
  • Node pools autoscale by adding or removing nodes based on pending pods; the Horizontal Pod Autoscaler scales replicas on CPU, memory or custom metrics.
  • You deploy workloads as Deployments, Services and Ingress objects; the scheduler places pods onto nodes with capacity.
  • Workload Identity maps Kubernetes service accounts to IAM roles so pods call Google APIs with temporary credentials from the metadata server.
  • Container images live in Artifact Registry repositories; nodes authenticate and pull them at deploy time.

Deploying a containerized workload to GKE via Artifact Registry.

Push image to Artifact Registry
gcloud container clusters create
kubectl applies a Deployment
HPA scales replicas
Ingress routes traffic
Workload Identity
Reference

Key commands

gcloud container clusters create my-cluster --region=us-central1 --num-nodes=3

Create a regional cluster with three nodes.

gcloud container clusters get-credentials my-cluster --region=us-central1

Write kubeconfig credentials so kubectl works against the cluster.

gcloud container node-pools list --cluster=my-cluster

List the cluster's node pools and their machine types.

gcloud container clusters resize my-cluster --node-pool=default-pool --num-nodes=5

Manually resize a node pool.

gcloud artifacts repositories create my-repo --repository-format=docker --location=us-central1

Create a Docker repository in Artifact Registry.

kubectl get pods --all-namespaces

List pods across every namespace in the cluster.

Hands-on

Examples

Create a GKE cluster and deploy a workload

Create a GKE cluster and deploy a workload
$ gcloud container clusters create my-cluster \
    --region=us-central1 --num-nodes=3
Creating cluster my-cluster in us-central1...done.
Created [https://container.googleapis.com/v1/projects/my-project/zones/us-central1/clusters/my-cluster].
To inspect the contents of your cluster, run:
  kubectl cluster-info
 
$ gcloud container clusters get-credentials my-cluster --region=us-central1
Fetching cluster endpoint and auth data.
kubeconfig entry generated for my-cluster.
 
$ kubectl create deployment nginx --image nginx:1.27
deployment.apps/nginx created
 
$ kubectl get nodes
NAME                              STATUS   ROLES    AGE   VERSION
gke-my-cluster-default-pool-abc   Ready    <none>   4m    v1.29.3

gcloud container clusters create provisions the managed control plane and a three-node pool. get-credentials merges the cluster into your local kubeconfig so kubectl works immediately. kubectl create deployment schedules an nginx Pod, and kubectl get nodes confirms the pool is Ready.

Real world

In production

  • Run stateless services with Deployments and HPA, and stateful workloads with StatefulSets and PersistentVolumes.
  • Use node pools with different machine types and autoscaling per pool.
  • Attach Workload Identity to every workload so pods get scoped IAM permissions.
  • Keep images in Artifact Registry with vulnerability scanning and private or VPC access.
  • Use Ingress with managed certificates for routing, TLS and canary traffic splits.
Guidelines

Best practices

  • Set resource requests and limits on every container so the scheduler and HPA work correctly.
  • Enable cluster autoscaling and the HPA together for both node and pod scaling.
  • Use Workload Identity instead of service account keys in pods.
  • Upgrade clusters on a schedule and use maintenance windows to avoid surprise node drains.
  • Apply network policies and namespaces to isolate tenants and workloads.
Watch out

Common mistakes

  • Baking service account keys into images or pod environment variables.
  • Running a single-node cluster and losing the app when the node drains.
  • Deploying images tagged latest, so rollbacks and reproducibility break.
  • Forgetting resource requests, then watching one noisy neighbor evict everyone's pods.
  • Enabling autoscaling but leaving no room in quota or zones for new nodes.
Root cause analysis

Common issues

Error
Pod stuck in Pending
Root cause

No node has enough CPU or memory, or cluster autoscaling is disabled.

Fix

Check kubectl describe pod events, node utilization, and enable the node pool autoscaler.

Error
ImagePullBackOff
Root cause

The image tag does not exist, or the node cannot pull from Artifact Registry.

Fix

Verify the image path with gcloud artifacts repositories list and grant the node service account storage access.

Error
AccessDenied when a pod calls Google APIs
Root cause

Workload Identity is misconfigured — wrong service account annotation, IAM binding, or metadata server.

Fix

Check the pod's service account annotation and the IAM binding on the mapped service account.

When things break

Debugging tips

  • kubectl describe pod shows events — unschedulable, image pull and crash loop failures surface there.
  • kubectl get events --sort-by=.lastTimestamp gives the cluster-wide story.
  • For IAM failures, check the pod's service account and the Workload Identity binding.
  • gcloud container clusters describe shows cluster state if kubectl cannot connect.
  • Check node pool health with gcloud container node-pools describe when nodes fail to join.
Interviews

Interview checkpoint

Practice

Hands-on lab

Declare and Validate a GKE Workload Locally
30 min · advanced
In progress
Objectives
  • Create a directory structure for manifests
  • Write a namespace, Deployment and HPA manifest with heredocs
  • Validate manifests against the Kubernetes schema
  • Inspect the manifests like a cluster operator would

Declare and Validate a GKE Workload Locally

30 min · advanced

0/6 steps
0%
sandbox · Linux sandbox
$
Try these commands
Test yourself

Quick quiz

0/3
1

Which component runs the Kubernetes control plane in GKE?

2

Workload Identity lets a pod assume GCP IAM permissions without storing keys.

3

Pods are stuck in Pending and no new nodes appear during a traffic spike. What should you check first?

Quick reference

Cheat sheet

GKE architecture
Control planeAPI server, etcd, scheduler — managed by Google
Node poolGroup of identical VMs running containerd
AutopilotFully managed nodes with no pool config
HPAScales pod replicas on metrics
Workload IdentityPod to IAM role without keys
Artifact Registry
RepositoryRegional store for images and packages
docker pushPush an image after configuring auth
gcloud artifacts repositories listList repositories in the project
Vulnerability scanningFind CVEs in stored images
Go deeper

Official documentation

GKE Overview
docs
GKE Concepts
docs
Autopilot Overview
docs
Workload Identity
docs
Artifact Registry Overview
docs