Before we talk about GKE, we need to understand the two ideas it is built on: containers and Kubernetes.

Start with the container

A container is a small, sealed package that holds one application and everything that application needs to run. That includes the program itself, its libraries, and its settings. Because everything is inside the package, the app behaves the same on your laptop, on a test server, and in a giant data center.

Why does this matter? Before containers, teams often heard the sentence, “It works on my machine!” An app would run perfectly for the developer and then fail on the production server because of one tiny difference, such as a missing library. Containers remove that problem by shipping the whole environment with the app.

Then meet Kubernetes

One container is easy to manage. But a real product may have hundreds or thousands of containers. Someone has to decide where each one runs, restart the ones that crash, add more when traffic grows, and connect them to each other. Doing that by hand is impossible at scale.

Kubernetes (often shortened to K8s) is an open-source system that does this job automatically. Google created it, based on lessons learned from an internal system called Borg, which Google had used for more than ten years to run its own products. Google released Kubernetes to the world in 2014, and today it is the most widely used container manager on the planet.

And now, GKE

Kubernetes is powerful, but running it yourself is hard. You must install it, secure it, patch it, upgrade it, and keep its brain healthy at all times. GKE is Google Cloud’s managed Kubernetes service. Google runs the hard parts for you, and you focus on your applications.

GKE began life in 2015 under the name Google Container Engine. It was renamed Google Kubernetes Engine in 2017. Since then it has added many features, with the biggest change being Autopilot mode, introduced in 2021, where Google even manages the worker computers for you.

The problems GKE solves

• Too much manual work. GKE automates placement, restarts, scaling and upgrades.
• Fragile servers. If a machine dies, GKE moves your app somewhere else.
• Slow releases. Rolling updates let you ship new versions without taking your site offline.
• Wasted money. Autoscaling adds capacity only when you need it and removes it when you do not.
• Security burden. Google patches the control plane and offers strong built-in protections.

GKE speaks the language of Kubernetes. Learn these building blocks once and the rest of this guide will feel easy.

Kubernetes has its own vocabulary. Each word names one simple idea. Here are the ones you will meet again and again.

More objects worth knowing

• ReplicaSet: A helper that makes sure the right number of identical pods exist. Deployments use it behind the scenes.
• StatefulSet: Like a deployment, but for apps that must remember who they are, such as databases. Each pod keeps a steady name and its own storage.
• DaemonSet: Runs one copy of a pod on every node, which is useful for log collectors and monitoring agents.
• Job and CronJob: A job runs a task once until it finishes. A cron job runs a task on a schedule, like a nightly report.
• Namespace: A named room inside a cluster that separates teams or projects, so the payments team and the search team do not trip over each other.
• PersistentVolume and PersistentVolumeClaim: Storage that survives even when a pod disappears. The claim is a request, and the volume is the actual disk.

The most important idea: desired state

Kubernetes works on a simple principle. You tell it what you want, not how to do it. You say, “Keep five copies of the checkout app running.” Kubernetes compares what you asked for with what is actually happening, and it keeps fixing any gap. This loop of checking and fixing is called reconciliation, and it is the heart of everything Kubernetes does.

This is why Kubernetes feels almost alive. If a node loses power at three in the morning, nobody has to wake up. The system notices that only four copies are running, sees that it wanted five, and starts one more on a healthy node.

A GKE cluster has two big halves: a control plane that Google manages, and worker nodes that run your apps.

The control plane

The control plane is a group of programs that act as the cluster’s brain. In GKE, Google hosts and operates these programs in its own managed project. You never log in to those machines, and you are never charged for patching them. The important parts are:

• API server: The front desk of the cluster. Every request, from you, from your tools, and from the nodes, goes through it. It checks who you are, checks what you are allowed to do, and records your wishes.
• State store (etcd): A reliable database that remembers everything about the cluster, such as which deployments exist and what they should look like. If this memory were lost, the cluster would forget its own plan.
• Scheduler: The matchmaker. When a new pod needs a home, the scheduler picks the best node based on free space, rules, and preferences.
• Controller manager: A collection of small watchers. One watches deployments, another watches nodes, another watches services. Each one compares reality to the plan and fixes differences.
• Cloud controller: The translator that talks to Google Cloud, for example asking for a load balancer or a disk when your app needs one.

The worker nodes

Nodes are the machines that actually run your containers. Every node has a few standard helpers:

• Kubelet: The node’s own manager. It listens to the API server, starts the pods it was assigned, and reports back whether they are healthy.
• Container runtime: The engine that unpacks container images and runs them. GKE uses containerd.
• Networking agent: Sets up pod addresses and traffic rules on the node. In modern GKE clusters this is often Dataplane V2, which is based on eBPF and Cilium technology.
• Node operating system: GKE nodes use a hardened, minimal system called Container-Optimized OS, built to run containers safely with little extra software.

flowchart TB
  Dev["Developer or CI/CD Pipeline"] --> API
  Users["End Users"] --> LB["Cloud Load Balancer"]
  subgraph CP["GKE Control Plane - managed by Google"]
    API["API Server"]
    ETCD["State Store"]
    SCH["Scheduler"]
    CM["Controller Manager"]
    API --- ETCD
    API --- SCH
    API --- CM
  end
  subgraph VPC["Your VPC Network"]
    subgraph N1["Node 1 in Zone A"]
      K1["Kubelet"]
      P1["Pods"]
    end
    subgraph N2["Node 2 in Zone B"]
      K2["Kubelet"]
      P2["Pods"]
    end
    subgraph N3["Node 3 in Zone C"]
      K3["Kubelet"]
      P3["Pods"]
    end
  end
  API --> K1
  API --> K2
  API --> K3
  LB --> P1
  LB --> P2
  LB --> P3

Read the figure from the top. A developer or an automated pipeline sends a request to the API server. The control plane records the plan and tells the kubelets on the nodes what to run. Meanwhile, real users arrive through a Google Cloud load balancer, which spreads their traffic across pods in different zones. A zone is one isolated data center area inside a Google Cloud region, so spreading across three zones protects you if one zone has trouble.

Where GKE connects to the rest of Google Cloud

The first big decision when you create a cluster is who manages the worker nodes: you, or Google.

Standard mode

In Standard mode, Google manages the control plane, but you manage the nodes. You choose the machine type, the size of each group of nodes (called a node pool), the disk type, and how the pool scales. You get deep control, and you pay for the whole virtual machine whether it is busy or idle.

Autopilot mode

In Autopilot mode, Google manages both the control plane and the nodes. You simply describe your pods and how much CPU and memory each one needs. Google finds or creates the right capacity automatically, applies security best practices, and bills you for the resources your pods request rather than for entire machines.

Google now recommends Autopilot as the starting point for most new clusters. Autopilot offers compute classes, which are ready-made choices for different jobs, such as general-purpose work, balanced work, scale-out work, and accelerated work for GPUs. You pick a class by label and Google supplies matching hardware.

Let us follow what really happens from the moment you say “run my app” to the moment users can reach it.

Many people imagine that Kubernetes runs your app the instant you ask. In truth, it is a chain of small, polite conversations between separate programs. Nobody gives direct orders. Each piece watches the API server and acts when something changes. This design is called a watch and react model, and it is why Kubernetes is so resilient.

sequenceDiagram
  participant D as Developer
  participant A as API Server
  participant S as Scheduler
  participant K as Kubelet on Node
  participant R as Artifact Registry
  D->>A: Submit Deployment
  A->>A: Save desired state
  A->>S: New pods need a node
  S->>A: Assign pod to chosen node
  A->>K: Run this pod
  K->>R: Pull container image
  R-->>K: Image layers
  K->>A: Report pod is Running

What about when something breaks?

Because every part keeps watching, repair is automatic. If a container crashes, the kubelet restarts it. If a whole node stops reporting, the node controller marks it unhealthy after a short wait, and the pods that lived there are recreated on other nodes. On GKE, node auto-repair goes one step further: it replaces the broken machine itself so the cluster returns to full strength.

Two journeys matter: the journey of a pod from birth to retirement, and the journey of a user request from the internet to your code.

The life of a pod

A pod is not immortal. It is born, it works, and it eventually goes away. Understanding each stage helps you debug problems quickly.

The life of a rolling update

When you release a new version, a deployment does not switch everything at once. It uses a rolling update. It starts a few new pods, waits until they are ready, then removes a few old pods, and repeats. At every moment, enough healthy pods are serving users. If the new version fails its health checks, the rollout pauses, and you can roll back to the previous version.

The journey of a request

Now follow a customer who opens your shopping website:

1. The browser looks up your domain name and receives the address of a Google Cloud load balancer.
2. The load balancer receives the request at one of Google’s edge locations and chooses a healthy backend.
3. The request travels into your VPC network and reaches a pod, often directly, thanks to a feature called container-native load balancing.
4. The web pod needs product data, so it calls an internal service by name. Cluster DNS turns that name into the service’s steady address.
5. The service forwards the call to one of several healthy backend pods.
6. The backend pod reads from a database, such as Cloud SQL or Spanner, and returns the answer along the same path.

Every step in this chain is designed so no single part is a single point of failure. That is the heart of reliable system design.

Networking is where most beginners feel lost. We will take it one layer at a time.

Every pod gets its own address

Kubernetes has a simple rule: every pod gets its own IP address, and every pod can talk to every other pod without tricks. GKE clusters are VPC-native, which means pod addresses come from a special range inside your Google Cloud network called an alias IP range. Because the addresses are real VPC addresses, other Google Cloud services can reach pods directly, and firewall rules and routing work naturally.

When you create a cluster, you plan three address ranges: one for the nodes, one for the pods, and one for services. Planning these with enough room is important, because running out of addresses is painful to fix later.

Services: a steady phone number

Pod addresses change whenever pods are replaced. A Service solves that by giving a group of pods one fixed address and one DNS name. There are three common kinds:

• ClusterIP: Reachable only inside the cluster. This is the default and is perfect for internal calls between microservices.
• NodePort: Opens a port on every node. It is rarely used directly in GKE.
• LoadBalancer: Asks Google Cloud to create a real load balancer with a public or private address that sends traffic to your pods.

Getting visitors in: Ingress and Gateway

For websites and APIs, you usually want smarter routing than one load balancer per service. You want rules such as “requests for /shop go to the shop service, and requests for /pay go to the payment service.” GKE offers two ways to describe such rules:

• Ingress: The older, simpler standard. GKE turns it into a Google Cloud HTTP(S) load balancer.
• Gateway API: The newer, more expressive standard that Kubernetes is moving toward. It separates the job of the platform team, who own the gateway, from the app teams, who own the routes. It also supports traffic splitting, which helps with gradual rollouts.

Container-native load balancing

Older load balancers sent traffic to a node, and then the node forwarded it again to a pod, which added an extra hop. With network endpoint groups (NEGs), the Google load balancer learns the pod addresses and sends traffic straight to the pod. This reduces delay and spreads load more evenly.

flowchart LR
  U["Internet Users"] --> GLB["Google Cloud Load Balancer"]
  GLB --> NEG1["NEG in Zone A"]
  GLB --> NEG2["NEG in Zone B"]
  NEG1 --> PA1["Web Pod A1"]
  NEG1 --> PA2["Web Pod A2"]
  NEG2 --> PB1["Web Pod B1"]
  NEG2 --> PB2["Web Pod B2"]
  PA1 --> SVC["Internal Service ClusterIP"]
  PA2 --> SVC
  PB1 --> SVC
  PB2 --> SVC
  SVC --> BE["Backend Pods"]

Dataplane V2 and network policy

By default, any pod can talk to any other pod. That is convenient but risky. A network policy is a rule set that says which pods may talk to which. For example, only the checkout pods may talk to the payment pods. GKE’s Dataplane V2 enforces these rules using eBPF, a modern technology built into the operating system kernel that is fast and gives better visibility into traffic.

Private clusters and outbound traffic

In a private cluster, nodes have only internal addresses and cannot be reached from the public internet. If those nodes need to download things from outside, you use Cloud NAT, which lets machines make outbound requests without being reachable from outside. You can also limit who can reach the control plane by using authorized networks, which act like a guest list for the API server.

Containers forget everything when they stop. To keep data, you need storage that lives outside the pod.

How storage is requested

Your app does not ask for a specific disk. Instead it creates a PersistentVolumeClaim, which is a polite request: “I need 100 gigabytes of fast storage.” A StorageClass describes the type of disk to create, and GKE’s CSI driver (a standard plug-in for storage) creates the real Google Cloud disk and attaches it to the right node. This is called dynamic provisioning, and it means no human has to create disks by hand.

Choices of storage

Running databases on GKE

You can run databases inside GKE using a StatefulSet. Each pod keeps a stable name, such as db-0, db-1, and its own disk that follows it around. Many companies also use operators, which are special programs that know how to run a certain database, handling backups and failover automatically.

However, a very common design choice is to keep the cluster for stateless apps and use managed databases such as Cloud SQL, AlloyDB, Spanner, or Firestore for data. Then the cluster can be replaced or resized freely, and Google handles database backups and patches.

Scaling means adding or removing capacity to match demand. GKE can do it at two levels, and often both together.

Level one: scale the pods

• Horizontal Pod Autoscaler (HPA): Adds or removes copies of a pod based on measurements such as CPU use, memory use, or a custom number like requests per second. More visitors means more copies.
• Vertical Pod Autoscaler (VPA): Adjusts how much CPU and memory each pod asks for. It is helpful when you are unsure about the right size.

Level two: scale the nodes

• Cluster Autoscaler (Standard mode): When pods cannot be scheduled because nodes are full, it adds nodes to a node pool. When nodes sit mostly empty, it removes them.
• Node auto-provisioning: Goes further by creating whole new node pools with the right machine shape automatically.
• Autopilot: You do not think about nodes at all. Google adds capacity when pods appear.

flowchart TD
  M["Metrics: CPU, memory, custom"] --> HPA["Horizontal Pod Autoscaler"]
  HPA -->|"adds pod copies"| PODS["More Pods Requested"]
  PODS -->|"nodes are full"| PEND["Pending Pods"]
  PEND --> CA["Cluster Autoscaler or Autopilot"]
  CA -->|"adds capacity"| NODES["New Nodes Ready"]
  NODES -->|"pods get scheduled"| RUN["Pods Running and Serving"]

Other helpful scaling tools

• Spot VMs: Discounted machines that Google may reclaim at short notice. Perfect for fault-tolerant jobs such as batch processing.
• Pod disruption budgets: A promise that says, “During upgrades or scale-downs, never take away more than one of my web pods at a time.”
• Multidimensional scaling: Combines horizontal and vertical ideas so apps can scale on more than one signal.
• Pod topology spread: Tells the scheduler to spread copies across zones and nodes, so one failure cannot take them all.

Scaling for AI and heavy computing

GKE supports nodes with GPUs and Google’s own TPUs, which are chips built for machine learning. Teams use these for training models, running inference, and batch simulations. Features such as GPU sharing, queued capacity requests, and compact placement help use these expensive machines wisely.

A good cloud system is not one that never fails. It is one that keeps serving customers when parts of it fail.

Layers of protection

• Regional control plane: Control plane copies live in three zones, so the brain survives a zone outage and can be upgraded without downtime.
• Multi-zone nodes: Spread node pools over several zones so your app has hands in more than one building.
• Node auto-repair: GKE checks node health and replaces unhealthy machines on its own.
• Probes and restarts: Kubernetes restarts failed containers and stops sending traffic to pods that are not ready.
• Multiple replicas: Running at least two or three copies of every important service avoids single points of failure.

Google publishes uptime commitments for GKE. At the time of writing, a regional cluster’s control plane carries a 99.95 percent monthly target, and a zonal cluster carries a lower one. Autopilot also has a commitment for pods spread across zones. These numbers can change, so always read the current service level agreement before you promise anything to your own customers.

Upgrades without drama

Kubernetes releases a new minor version about three times a year, and each version is supported for a limited time. Falling behind means losing security fixes. GKE helps through release channels:

Controlling when upgrades happen

You can set maintenance windows, which are preferred hours when upgrades may happen, such as Sunday at 2 AM. You can also set maintenance exclusions, which block upgrades during sensitive times like a holiday sales event. For node pools, GKE supports surge upgrades, which add a few extra nodes before replacing old ones, and blue-green upgrades, which build a full second set of nodes and switch over only when it is healthy, keeping the old set ready for a quick return.

Designing for disaster

For very important systems, one region may not be enough. Teams run clusters in two or more regions and use a global load balancer to send users to the closest healthy one. Multi-cluster services and multi-cluster gateways help traffic cross clusters, and fleets let you manage many clusters as a group. Backups of cluster state and persistent data, such as Backup for GKE, protect against mistakes like an accidental delete.

Security works best in layers, like a castle with a moat, walls, guards, and locked rooms. GKE offers a layer for each part of that castle.

Who you are: identity and access

• Cloud IAM: Controls who can create, change, or delete clusters in Google Cloud.
• Kubernetes RBAC: Controls what a person or program can do inside a cluster, such as reading pods in one namespace but not another. Use the principle of least privilege, which means giving only the permissions that are truly needed.
• Workload Identity Federation for GKE: Lets a pod act as a specific Google Cloud service account without storing any password or key file. The pod proves who it is, and Google hands it short-lived access. This replaces the risky habit of copying key files into pods.

The cluster itself

• Private clusters and authorized networks: Keep nodes and the control plane away from the public internet.
• Shielded GKE nodes: Use secure boot and integrity checks so nodes can prove they have not been tampered with.
• Container-Optimized OS: A minimal, hardened operating system with a small attack surface.
• GKE Sandbox: Uses gVisor to give extra isolation for untrusted code, like a thick glass wall between a risky workload and the node.

The software you run

• Artifact Registry with vulnerability scanning: Checks container images for known security holes.
• Binary Authorization: A gate that only lets signed and approved images run in your cluster, like a security guard checking badges at the door.
• Pod Security Standards: Rules that stop dangerous pod settings, such as running as the all-powerful root user.
• Secrets management: Store passwords in Secret Manager or encrypt Kubernetes Secrets with your own keys from Cloud KMS, instead of leaving them in plain files.

Watching for trouble

The security posture dashboard in GKE scans your workloads and clusters for common mistakes and known weaknesses, and gives plain recommendations. Audit logs record who did what, so you can investigate after something strange happens.

You cannot fix what you cannot see. GKE connects to Google Cloud’s observability tools with very little setup.

The three pillars

What to watch

• The golden signals: latency (how slow), traffic (how much), errors (how often things fail), and saturation (how full things are).
• Pod health: restart counts, pods stuck in Pending, and failing probes.
• Node health: CPU and memory pressure, disk space, and node readiness.
• Autoscaler activity: how often it scales, and whether any pods are waiting for capacity.
• Control plane signals: API server latency and error rates, which tell you whether the brain is under stress.

Alerts that matter

Good alerts wake people up only for real customer pain. An alert like “error rate above two percent for five minutes” is useful. An alert like “one pod restarted once” is noise. Tie alerts to service level objectives (SLOs), which are clear targets such as “99.9 percent of requests succeed.” Cloud Monitoring can track SLOs and the error budget, which is the amount of failure you can still afford this month.

The cloud is pay-as-you-go. That is a gift when you manage it well and a surprise bill when you do not.

What you pay for

• Cluster management fee: At the time of writing, GKE charges a small hourly fee per cluster, about ten cents per hour, in both modes. Google also gives a monthly credit that covers this fee for one zonal or Autopilot cluster per billing account. Check the current pricing page for exact numbers.
• Compute: In Standard mode, you pay for the virtual machines in your node pools. In Autopilot, you pay for the CPU, memory, and storage your pods request.
• Storage: Disks, file shares, and buckets are billed separately.
• Networking: Load balancers, data leaving Google Cloud, and traffic between zones can add up quietly.
• Extras: Logging volume, managed Prometheus samples, and the GKE Enterprise edition, which adds multi-cluster management and extra security features and is priced per vCPU.

Patterns are proven recipes. Anti-patterns are tempting shortcuts that hurt later.

Helpful patterns

Common anti-patterns

These habits come from years of clusters that stayed up and clusters that did not.

Mistakes that surprise beginners

• Pods stuck in Pending. Usually the cause is requests that are larger than any node can offer, a missing quota, or a rule that no node satisfies. The pod’s event messages explain the reason in plain words.
• CrashLoopBackOff. The container keeps starting and failing. Look at its logs and check that its settings and secrets are correct.
• ImagePullBackOff. The node cannot download the image. Check the image name, the registry permissions, and whether a private node has a route to the registry.
• Surprise bills. Often caused by oversized requests, forgotten test clusters, unused load balancers, or very chatty logs.
• Zone-bound disks. A stateful pod cannot start in a zone that does not hold its disk.
• Upgrade pain. Old API versions get removed in newer Kubernetes releases. Test upgrades in a staging cluster first and read deprecation warnings early.

Seeing how real teams use GKE makes the ideas stick.

Common industry patterns

Quick answers to the questions people ask most.

You have now seen GKE from the first container to a multi-region platform. Here is the whole story in one place.