Before we talk about GKE, we need three simple ideas: a container, an orchestrator, and a managed service.

Start with the problem

Every application is a pile of code that needs a computer to run on. A small website might need one computer. A big service like a video app or a ride-hailing app needs thousands of programs running at once, spread across hundreds of computers. Those programs must find each other, share traffic fairly, restart when they crash, and update without the users noticing. Doing this by hand is like running a huge hotel with a single receptionist: it works for five guests and collapses at five thousand.

What is a container?

A container is a sealed box that holds one program together with everything that program needs to run: its code, its libraries, and its settings. The box runs the same way on a laptop, on a test machine, and on a production server. The blueprint used to make a container is called an image. You build an image once, then start as many identical containers from it as you like.

What is Kubernetes?

If you have ten containers, you can start them yourself. If you have ten thousand, you need a manager. Kubernetes (often written K8s) is open-source software that acts as that manager. You tell it what you want, for example “keep five copies of my checkout program running at all times”, and it makes that true and keeps it true. If a computer dies, Kubernetes starts replacement copies elsewhere. If traffic grows, it can add more copies. A group of computers managed together by Kubernetes is called a cluster.

What does “managed” mean?

Kubernetes itself is complicated to install and to keep healthy. It has a “brain” made of several programs that must be upgraded, backed up, secured and kept available around the clock. A managed service means a cloud company runs that hard part for you. GKE is Google’s managed Kubernetes service. Google runs the brain of the cluster, patches it, scales it, and fixes it when it breaks. You focus on your own applications.

GKE sits on top of more than twenty years of lessons learned from running giant systems at Google.

Google runs services like Search, Gmail and YouTube for billions of people. In the early 2000s its engineers built an internal system called Borg to start, stop and supervise millions of jobs across enormous fleets of machines. Borg taught Google hard lessons: pack many workloads onto shared machines to save money, describe what you want instead of giving step-by-step orders, and let software heal itself because humans are too slow. A second internal system, Omega, tested new ideas on scheduling.

In 2014 Google released a fresh, open-source system built on those lessons and called it Kubernetes, a Greek word for a ship’s helmsman. Releasing it openly was a big decision. It allowed other companies, and later every major cloud, to adopt the same standard. Kubernetes was handed to a neutral home, the Cloud Native Computing Foundation, so that no single company would own it.

Kubernetes has its own vocabulary. Learn these ten words and the rest of the guide will feel easy.

Why Pods and not just containers?

Sometimes a program needs a small helper beside it, such as a tool that collects its logs or a proxy that handles secure connections. Putting both in one Pod guarantees they always land on the same machine and can talk to each other over a private local connection. Most Pods contain just one main container, and that is perfectly normal.

Pods are disposable

This is the single most important mindset shift. A Pod is not a pet. It can be killed and replaced at any moment: because a machine failed, because you shipped a new version, or because the cluster is making room. Its IP address changes when it is replaced. That is why Services exist. You never talk to a Pod directly; you talk to the Service in front of it.

Declarative thinking

In Kubernetes you describe the desired state, such as “five copies of version 2.1 of my app”. You do not write the steps to get there. Kubernetes constantly compares the real world to your description and corrects any difference. Engineers call this a reconciliation loop, and it is the beating heart of the whole system.

A GKE cluster has two halves: a brain that Google runs, and a body of machines that run your work.

The control plane: the brain

The control plane is a set of programs that make decisions for the cluster. In GKE, Google hosts it in a Google-managed project, so you never see those machines and never patch them. It contains:

• API server: the front door. Every command, whether from an engineer, a tool or another program, goes through it. It checks who you are and whether you are allowed to do the thing you asked.
• Datastore (etcd in the open-source design): the cluster’s memory, holding every desired state and current fact. It is replicated so that losing one copy does not lose the cluster’s memory.
• Scheduler: decides which node should run each new Pod, based on free capacity, rules and preferences.
• Controller manager: a collection of small robots, each watching one kind of object and fixing differences between desired and real state.
• Cloud controller: the translator that creates Google Cloud things, such as load balancers and disks, when Kubernetes objects ask for them.

The nodes: the body

Nodes are Compute Engine virtual machines in your own Google Cloud project. Each node runs a few standard programs:

• kubelet: the node’s local manager. It receives instructions from the control plane and makes sure the right containers are running on its machine.
• Container runtime: the program that actually starts containers (containerd in GKE).
• Networking components: set up Pod addresses and enforce traffic rules, so Pods on different nodes can reach each other.
• Agents for logs and metrics: send observations to Google’s monitoring services.

flowchart TB
  U["Engineer or CI tool"] --> API
  subgraph CP["Google-managed control plane"]
    API["API Server"]
    ET["Cluster datastore"]
    SCH["Scheduler"]
    CM["Controller Manager"]
    CCM["Cloud Controller"]
    API --- ET
    API --- SCH
    API --- CM
    API --- CCM
  end
  subgraph PROJ["Your Google Cloud project"]
    subgraph NP1["Node pool A"]
      N1["Node 1 with kubelet"] --> P1["Pods"]
      N2["Node 2 with kubelet"] --> P2["Pods"]
    end
    subgraph NP2["Node pool B"]
      N3["Node 3 with kubelet"] --> P3["Pods"]
    end
  end
  API --> N1
  API --> N2
  API --> N3
  CCM --> LB["Cloud Load Balancer"]
  LB --> P1
  LB --> P3
  P1 --> LOG["Cloud Logging and Monitoring"]
  AR["Artifact Registry"] --> N1
    

Read the diagram from the top. An engineer sends a request to the API server. The API server stores it, the scheduler picks a node, and the kubelet on that node pulls the container image from Artifact Registry and starts it. When a Service of type load balancer is requested, the cloud controller asks Google Cloud to create a real load balancer that forwards traffic into the Pods.

Who is responsible for what?

GKE offers two ways to operate a cluster. The difference is how much of the machine layer you want to own.

Standard mode

In Standard mode you design the nodes yourself. You pick the machine type, the number of machines, the disks, the zones, and when and how upgrades happen. You are billed for the virtual machines in your node pools, whether they are busy or idle. This gives you the most control, and also the most responsibility.

Autopilot mode

In Autopilot mode Google also manages the nodes. You never create node pools. You simply tell the cluster how much CPU and memory each Pod needs, and Google finds or creates capacity for it. Autopilot applies many security and reliability settings by default and bills mainly for the resources your Pods request rather than for whole machines.

Let us follow one small request through the machinery to see how the pieces cooperate.

Suppose you ask GKE for “three copies of my shopping-cart service, version 2”. Here is the journey, step by step.

sequenceDiagram
  participant E as Engineer
  participant A as API Server
  participant D as Datastore
  participant C as Controllers
  participant S as Scheduler
  participant K as Kubelet on node
  E->>A: Submit Deployment with 3 replicas
  A->>A: Authenticate, authorize, validate
  A->>D: Save desired state
  C->>A: Watch and see new Deployment
  C->>A: Create ReplicaSet and 3 Pods
  S->>A: Watch and see unassigned Pods
  S->>A: Bind each Pod to a node
  K->>A: Watch and see Pod assigned to me
  K->>K: Pull image and start containers
  K->>A: Report Pod running and ready
    

The hub-and-spoke secret

Notice that the scheduler, controllers and kubelets never talk directly to each other. Each one watches the API server for changes it cares about, does its small job, and writes the result back. This design makes the system easy to extend and easy to recover: if a component crashes, it restarts, reads the current state, and carries on.

What happens when something breaks?

If a node dies, the control plane stops hearing from its kubelet. After a short grace period it marks the node as unhealthy and the Pods there as lost. The ReplicaSet controller sees that only two of three copies exist and creates a replacement, which the scheduler places on a healthy node. You did not issue any command. The loop did its job. On Standard clusters, GKE node auto-repair also replaces the broken machine itself.

Networking is where most beginners get lost, so we will take it one layer at a time.

Every Pod gets its own address

Kubernetes promises that every Pod has its own IP address and can talk to every other Pod without tricks. GKE delivers this using a VPC-native design. Your cluster uses ranges of addresses inside your Google Cloud network, called alias IP ranges. One range is reserved for nodes, one for Pods and one for Services. Because Pod addresses are real addresses in your network, other Google Cloud resources can reach them directly and network tools understand them.

Services: a stable address for a moving crowd

Since Pods come and go, clients need a fixed address. A Service provides it. The common types are:

• ClusterIP: reachable only from inside the cluster. Used for service-to-service calls.
• NodePort: opens a port on every node. Rarely used directly today.
• LoadBalancer: asks Google Cloud to create a load balancer with a public or internal address.

Inside the cluster, a built-in DNS service lets Pods find each other by name, such as “payments” instead of an IP address, so developers never hard-code addresses.

Bringing the internet in: Ingress and Gateway

For web traffic, you usually want one public entrance that routes by address and path: shop pages go to one Service, API calls go to another. GKE supports the older Ingress object and the newer, more expressive Gateway API. Both create Google’s global load balancers, which accept traffic at Google’s edge locations around the world and carry it over Google’s private backbone. With container-native load balancing, the load balancer sends requests straight to Pods using network endpoint groups, skipping an extra hop through the nodes. That lowers delay and spreads traffic more evenly.

flowchart LR
  USER["User on the internet"] --> DNS["DNS name"]
  DNS --> ARMOR["Cloud Armor rules"]
  ARMOR --> GLB["Global external load balancer"]
  GLB --> GW["Gateway and routing rules"]
  GW --> NEG1["Endpoint group zone A"]
  GW --> NEG2["Endpoint group zone B"]
  NEG1 --> POD1["Pod 1"]
  NEG1 --> POD2["Pod 2"]
  NEG2 --> POD3["Pod 3"]
  POD1 --> SVC["Internal Service for payments"]
  SVC --> POD4["Payments Pod"]
  POD4 --> NAT["Cloud NAT for outbound calls"]
  NAT --> EXT["External API"]
    

Controlling who may talk to whom

By default, any Pod can talk to any other Pod. That is convenient and also dangerous: one hacked Pod could probe everything. Network policies are firewall rules for Pods, such as “only the checkout Pods may call the payments Pods”. GKE’s modern networking layer, called Dataplane V2, is built on eBPF technology from the Linux kernel and has network policy enforcement built in. It also gives better visibility into traffic and is used by default in Autopilot.

Private clusters and outbound access

In a private cluster, nodes have no public IP addresses, so they cannot be reached directly from the internet. The control plane can also be limited to trusted address ranges. Private nodes still need to download images and call outside services, which is done through Cloud NAT, a managed gateway for outbound-only traffic.

Going bigger: many clusters

Large companies often run several clusters, in different regions for resilience or for different teams. Google offers fleet features, multi-cluster Services and multi-cluster Gateways so these clusters can be treated as a group, with traffic steered to the closest healthy one.

Containers forget everything when they stop. If your program needs to remember, you need storage that outlives the container.

Ephemeral versus persistent

A container’s own filesystem is ephemeral: it vanishes when the Pod is replaced. That is fine for temporary scratch files and terrible for a database. Persistent storage lives outside the Pod and can be attached to a new Pod after the old one is gone.

The three objects behind persistent storage

What storage options does GKE offer?

Zones matter for disks

A standard persistent disk lives in one zone, and a Pod using it must run in that same zone. If that zone has trouble, the disk is unavailable. Regional disks keep a copy in two zones, so a replacement Pod can start in the other zone. This is a classic trade-off: regional disks cost more and write a little slower, but survive a zone failure.

Should databases run inside the cluster?

You can run databases on GKE, and many teams do for specialized needs. But databases are the hardest workloads to run safely: backups, failover, upgrades and tuning all demand care. A common, sensible pattern is to run the stateless parts of your system, the web servers and workers, on GKE, and use managed database services such as Cloud SQL, Spanner or Firestore for the data. Then Google handles the hard parts of the data layer, too.

Backing up the cluster itself

Backup for GKE can capture both the cluster’s configuration and the data on persistent volumes, so you can restore into the same or another cluster after a mistake or a disaster. Treat it as a safety net for the stateful pieces you chose to run yourself.

Two journeys matter: the journey of a user’s request, and the life story of a Pod.

The journey of one user request

Imagine a shopper taps “Add to cart” in a mobile app. The request leaves the phone and arrives at Google’s nearest edge location. A global load balancer checks security rules, picks a healthy region and zone, and forwards the request straight to a ready Pod running the cart service. That Pod may call other Services inside the cluster, such as inventory or pricing, using their internal names. Each call is balanced across the healthy Pods behind that Service. The cart Pod then writes to a managed database, builds a response, and sends it back along the same path. The whole trip often takes a fraction of a second.

The life story of a Pod

A Pod moves through clear phases, and understanding them makes debugging much easier.

flowchart TD
  A["Deployment applied"] --> B["Pod created: Pending"]
  B --> C{"Node with free room?"}
  C -- "No" --> D["Autoscaler adds capacity"]
  D --> E["Image pulled"]
  C -- "Yes" --> E
  E --> F["Containers start"]
  F --> G{"Startup and readiness probes pass?"}
  G -- "No" --> H["Not in Service, may restart"]
  H --> G
  G -- "Yes" --> I["Receives traffic"]
  I --> J{"Update or node drain?"}
  J -- "No" --> I
  J -- "Yes" --> K["Removed from Service, graceful shutdown"]
  K --> L["Replacement Pod created"]
    

Configuration and secrets in the flow

Programs should not have passwords baked into their images. ConfigMaps hand ordinary settings to Pods at start time, while Secrets carry sensitive values. Because the same image can run in test and production with different settings, you build once and deploy everywhere.

Scaling means matching capacity to demand: more when busy, less when quiet. GKE can do this at three levels.

Level 1: more or fewer Pods

The Horizontal Pod Autoscaler (HPA) watches a signal, usually CPU use, memory, or a custom number such as requests per second or queue length, and changes the number of Pod copies to keep that signal near a target. This is called scaling out and in.

Level 2: bigger or smaller Pods

The Vertical Pod Autoscaler (VPA) studies how much CPU and memory Pods really use and recommends, or applies, better resource sizes. This is scaling up and down, and it fixes the common mistake of guessing numbers once and never revisiting them.

Level 3: more or fewer machines

When Pods have nowhere to run, the cluster autoscaler adds nodes. When nodes sit mostly empty, it removes them. In Standard mode, node auto-provisioning can even create new node pools with suitable machine shapes by itself. In Autopilot, this whole level is handled by the platform.

How fast can it react?

Adding Pods is quick, often seconds. Adding a new machine takes longer, typically minutes, because a virtual machine must boot, join the cluster and pull images. If a traffic spike is sharp and predictable, such as a sale at noon, scale in advance, or keep a little spare headroom. Many teams run small placeholder Pods at low priority that are evicted instantly when real work arrives, so real Pods never wait for a new machine.

Performance habits that matter

• Set requests and limits honestly. A request is the amount reserved for the Pod; a limit is the ceiling. Requests drive scheduling and, in Autopilot, billing.
• Keep images small. Smaller images download faster, which speeds up scaling and recovery.
• Spread work across zones. It avoids hotspots and improves resilience.
• Mind CPU limits. Very tight CPU limits can cause throttling that looks like random slowness.
• Test under load. Autoscaling rules should be proven by experiment, not hope.

Scale limits

A single GKE cluster can be very large. Google has demonstrated clusters of tens of thousands of nodes for demanding jobs such as AI training. For ordinary services, the practical limits are usually address ranges, quotas and how many objects the control plane must track. When one cluster is not enough, split by region, team or environment.

High availability means staying up when parts fail. In the cloud, parts fail all the time, so the design must expect it.

Zones and regions

A region is a geographic area, such as Mumbai or Frankfurt. Inside it are several zones, which are separate data center groups with independent power and cooling. A zone can fail while the others keep working.

Zonal versus regional clusters

flowchart TB
  GLB["Global Load Balancer"] --> ZA
  GLB --> ZB
  GLB --> ZC
  subgraph REG["One region with a regional cluster"]
    CPX["Control plane replicas in three zones"]
    subgraph ZA["Zone A"]
      NA["Nodes with 2 Pods"]
    end
    subgraph ZB["Zone B"]
      NB["Nodes with 2 Pods"]
    end
    subgraph ZC["Zone C"]
      NC["Nodes with 2 Pods"]
    end
    CPX --- NA
    CPX --- NB
    CPX --- NC
  end
  NA --> DB["Regional managed database"]
  NB --> DB
  NC --> DB
    

Tools that keep Pods available

• Replicas: never run just one copy of anything important.
• Topology spread and anti-affinity rules: tell the scheduler to spread copies across zones and nodes instead of piling them in one place.
• Pod disruption budgets (PDBs): a promise to the platform such as “at least two copies must stay up during voluntary maintenance”. Upgrades and drains respect it.
• Probes: detect and sideline unhealthy Pods quickly.
• Resource requests: ensure Pods are not crammed onto nodes without room to breathe.

Upgrades without downtime

Kubernetes releases new versions several times a year, and old versions stop being supported. GKE organizes this with release channels, called Rapid, Regular and Stable, which trade freshness for proven stability, plus an Extended option for longer support. You choose a channel, and Google upgrades the control plane and, if enabled, the nodes. You can set maintenance windows so upgrades happen at quiet hours, and maintenance exclusions to avoid them during a big sales period.

For node upgrades, GKE can use surge upgrades, which add a few extra nodes first and then replace old ones gradually, or blue-green upgrades, which build a full new set of nodes and move traffic over with a quick way back. Both rely on your PDBs and probes being correct to avoid interruptions.

Self-healing at the node level

Node auto-repair checks node health regularly. If a node keeps reporting failures, GKE drains it and recreates it. Combined with Pod-level restarts and Deployment controllers, this forms layers of healing: container, Pod, node.

Beyond one cluster

If a whole region is lost, even a regional cluster is gone. Businesses that cannot accept that run a second cluster in another region and steer traffic with a global load balancer or multi-cluster Gateway. This is more work and more cost, so match it to the real business need. Always pair it with tested backups and a written recovery plan.

Good cloud security is built in layers, so that one mistake does not become a disaster.

Layer 1: who can do what (identity and access)

Two permission systems work together. Cloud IAM decides what a person or service may do to Google Cloud resources, such as creating clusters. Kubernetes RBAC (role-based access control) decides what they may do inside a cluster, such as reading Pods in one namespace. The golden rule is least privilege: give each person and program only the exact permissions they need, nothing more.

Layer 2: how Pods prove who they are

Your applications often need to call Google services, such as reading a storage bucket. The old way was to save a long-lived key file inside the cluster, which is risky because keys leak. The modern way is Workload Identity Federation for GKE. A Pod is linked to an identity, and Google Cloud issues short-lived credentials automatically, with no key files to copy or lose.

Layer 3: shrinking the attack surface

• Private clusters keep nodes off the public internet.
• Authorized networks limit which addresses may reach the control plane.
• Shielded GKE nodes use verified boot and integrity checks to resist tampering.
• Hardened node images with minimal software and automatic patches.
• Network policies limit Pod-to-Pod conversations.

Layer 4: trusting only what you built

Many attacks arrive through software supply chains: a poisoned library or an altered image. Defenses include scanning images for known weaknesses in Artifact Registry, signing images that passed your pipeline, and using Binary Authorization so the cluster refuses to run any image that lacks a valid signature. Keep images small and based on minimal, trusted bases.

Layer 5: containing the damage

• Pod Security Standards block risky settings, such as running as the all-powerful root user or asking for host-level access.
• GKE Sandbox adds an extra isolation layer, based on gVisor, for running untrusted code.
• Separate namespaces and node pools for sensitive workloads limit how far a break-in can spread.

Layer 6: protecting secrets and data

Kubernetes Secrets are encoded, not strongly protected by default. GKE can encrypt them at the application layer with keys you control in Cloud KMS, or you can keep secrets in Secret Manager and bring them into Pods when needed. Data on disks is encrypted by default, and you can choose to manage the keys yourself. Never place passwords inside images or source code.

Layer 7: seeing and responding

Turn on audit logging so every action against the API server is recorded. Use Google’s security posture and vulnerability reports to find misconfigurations, and send alerts for suspicious events such as a new administrator role or a Pod with powerful settings.

You cannot fix what you cannot see. Observability is the practice of making a running system explain itself.

The three kinds of signals

What GKE gives you

• Cloud Logging: collects container output and cluster events automatically, so a program that simply prints messages already has searchable logs.
• Cloud Monitoring: gathers system metrics for nodes, Pods and containers, with ready-made GKE dashboards, uptime checks and alerting.
• Managed Service for Prometheus: Prometheus is the popular open-source metrics system in the Kubernetes world. Google offers a managed version, so you can collect and query Prometheus-style metrics without running the storage yourself.
• Cloud Trace: follows requests across services when your programs are set up to send trace data.
• Audit logs: record who changed what in the cluster.

What to watch

A helpful method is to watch four things for every service, often called the golden signals:

• Latency: how long requests take, especially the slowest few percent.
• Traffic: how many requests arrive.
• Errors: what share of requests fail.
• Saturation: how full the resources are, such as CPU, memory and connection pools.

For the cluster itself, also watch Pods stuck in Pending, containers restarting repeatedly, nodes under memory pressure, unused or exhausted address space, and upgrade events.

Alerts that people can act on

Alert on symptoms users feel, such as high error rate or slow checkout, rather than on every internal blip. Too many noisy alerts train people to ignore them. Each alert should say what is wrong, how serious it is, and where to look first. Link it to a short runbook, which is a written list of steps for handling that situation.

Deployment is how new code reaches users. Good pipelines make it boring, frequent and safe.

The pipeline in plain words

CI (continuous integration) means every code change is automatically built and tested. CD (continuous delivery or deployment) means a tested change is automatically released through stages, such as test, staging and production. On Google Cloud, a typical flow looks like this:

flowchart LR
  DEV["Developer pushes code"] --> REPO["Source repository"]
  REPO --> BUILD["Cloud Build: build and test"]
  BUILD --> SCAN["Image scan and signing"]
  SCAN --> AR["Artifact Registry"]
  AR --> DEPLOY["Cloud Deploy or GitOps tool"]
  DEPLOY --> STG["Staging cluster"]
  STG --> GATE{"Tests and approval pass?"}
  GATE -- "Yes" --> PROD["Production cluster"]
  GATE -- "No" --> STOP["Stop and notify team"]
  PROD --> OBS["Monitoring and alerts"]
  OBS --> ROLLBACK{"Healthy?"}
  ROLLBACK -- "No" --> RB["Automatic rollback"]
    

Release strategies

GitOps: the repository is the truth

In GitOps, the desired state of the cluster is stored in a version-controlled repository. A tool inside the cluster, such as Config Sync or Argo CD, continuously compares the repository with reality and fixes any drift. Changes happen through reviewed pull requests. This gives you history, approvals, easy rollbacks, and a clear answer to “who changed this and when?”.

Packaging tools

Real applications need many Kubernetes objects at once. Tools such as Helm and Kustomize bundle these objects and let you vary settings between environments. Teams pick one approach and stay consistent.

Safe rollout checklist

• Use image tags that never change meaning, such as a version number or a unique build ID, instead of a floating label like “latest”.
• Define readiness probes and Pod disruption budgets before the first production release.
• Use database changes that work with both the old and the new version of the code.
• Automate a rollback trigger tied to error-rate alerts.
• Keep staging as close to production as you can afford.

No tool is perfect. A good architect knows both what GKE gives and what it costs.

GKE versus other ways to run code

The honest decision guide

If your application is a single small service, Cloud Run or a similar serverless option is often simpler and cheaper. Choose GKE when you run many services that must talk to each other, need fine control over networking and scheduling, run long-lived or stateful workloads, need special hardware, or want one standard platform for many teams. The strongest reason to pick Kubernetes is not that it is fashionable, but that you truly need what it does.

Cloud bills grow quietly. Understanding where the money goes is the first step to keeping it sensible.

What you pay for

• Cluster management fee: a small hourly fee per cluster, with a monthly free-tier credit applied per billing account. Check the current pricing page for exact figures, as they can change.
• Compute: in Standard, the virtual machines in your node pools. In Autopilot, the CPU, memory and storage requested by your Pods.
• Storage: disks, file shares and snapshots.
• Networking: load balancers, and data leaving a zone, a region or Google Cloud. Traffic between zones can cost money, which surprises many teams.
• Observability: log ingestion and metric storage beyond free allowances.

Where waste hides

Ways to spend less

• Right-size requests using real usage data and the Vertical Pod Autoscaler recommendations.
• Use Spot VMs for fault-tolerant work such as batch jobs. Spot machines are much cheaper but can be taken back by Google with short notice, so the workload must tolerate interruption.
• Commit for steady load. Committed use discounts reward predictable baseline usage with lower prices.
• Scale to zero or small in non-production environments at night and on weekends.
• Pack nodes well in Standard by picking machine shapes that match your Pods.
• Label everything by team and product, and turn on cost allocation so each team sees its own share.
• Review regularly. Budgets and alerts catch surprises early.

Where a Pod lands, and how much room it gets, decides both its performance and your bill. This chapter goes one level deeper than the basics.

Requests and limits, once more with feeling

Every container can declare two numbers for CPU and for memory. The request is the amount the scheduler reserves: it will only place the Pod on a node that still has that much unreserved room. The limit is the ceiling the container may not exceed. CPU is a squeezable resource: a container that hits its CPU limit is slowed down, or throttled. Memory is not squeezable: a container that goes beyond its memory limit is killed, and you will see the reason reported as “out of memory”.

Quality of service classes

Kubernetes sorts Pods into three classes, which decide who is sacrificed first when a node runs short of memory.

For important production services, many teams aim for requests equal to limits on memory, and a request somewhat below the limit on CPU. This avoids surprise kills while still allowing short bursts of speed.

Steering Pods with rules

Priority and preemption

Not all Pods are equally important. A priority class gives each Pod a rank. If a high-priority Pod cannot find room, the scheduler may evict lower-priority Pods to make space. This is how the “placeholder Pod” trick from the scaling chapter works: low-priority dummy Pods hold spare room and are pushed out the moment real work needs it.

Keeping teams fair: quotas and limit ranges

In a shared cluster, one careless team could grab all the capacity. A ResourceQuota caps the total CPU, memory, storage or number of objects a namespace may use. A LimitRange sets default and maximum sizes for individual Pods or containers, so a forgotten setting does not become a huge one. Together they act like a household budget plus a rule that no single purchase may exceed a set amount.

Bin packing and why it matters

Putting Pods onto nodes is a packing puzzle. If Pods are too large relative to nodes, you leave awkward gaps that no Pod can fill. If they are too tiny, you waste effort. In Standard mode, choose node sizes that fit several Pods snugly. In Autopilot, the platform packs for you, which is one reason many teams find it easier.

A single cluster is a great start. Large organizations eventually run many, and they need ways to manage them as one family.

Why more than one cluster?

• Resilience: a second region protects against the loss of a whole region.
• Proximity: clusters near users reduce delay.
• Isolation: separate clusters for production, testing, and sensitive workloads limit the blast radius of mistakes.
• Regulation: some data must stay in a specific country, so a cluster must live there.
• Team autonomy: big organizations give each business unit its own cluster.

Fleets: treating clusters as a group

A fleet is a logical group of clusters that you manage together. Registering clusters into a fleet unlocks shared features: one place to see health, shared identity concepts across clusters, consistent configuration pushed from a repository, and policy applied everywhere at once. The enterprise edition of GKE builds on this idea with additional governance, security and multi-cluster tools aimed at larger organizations, and it can also extend to clusters outside Google Cloud. Check Google’s documentation for the current feature list, since packaging evolves.

Multi-cluster networking

Two helpful features are multi-cluster Services, which let a Service in one cluster be discovered and used from another, and multi-cluster Gateway, which lets one global load balancer spread user traffic across clusters in different regions. If a region has trouble, traffic shifts to the healthy clusters.

flowchart TB
  USERS["Users worldwide"] --> GLB["Global load balancer with multi-cluster Gateway"]
  GLB --> C1
  GLB --> C2
  subgraph FLEET["One fleet"]
    subgraph C1["Cluster in Region 1"]
      A1["Pods in three zones"]
    end
    subgraph C2["Cluster in Region 2"]
      A2["Pods in three zones"]
    end
  end
  REPO["Git repository with shared configuration"] --> C1
  REPO --> C2
  POL["Fleet-wide policy"] --> C1
  POL --> C2
  A1 --> DB["Multi-region database"]
  A2 --> DB
    

The hard part is data

Stateless Pods are easy to run in two regions. Data is not. Keeping two regions in step requires either a database built for multiple regions, or a careful plan for which region owns which data. Decide early whether you need active-active (both regions serve users) or active-passive (one region waits as a standby), because the cost and complexity differ greatly.

GKE is not only for web services. It is also a popular home for training and serving machine learning models and for large batch jobs.

Why these workloads are different

Web services run forever and respond to requests. Batch jobs start, do a big piece of work, and finish. Machine learning adds expensive special hardware: GPUs (graphics processors, very good at the math used in AI) and TPUs (Google’s own chips designed for AI). Because this hardware costs a lot, the goal is to keep it busy and to release it immediately when work ends.

The building blocks

Checkpoints: the secret to cheap training

A long training job may run for days. If a machine fails or a Spot machine is taken back, you do not want to start from zero. A checkpoint is a saved snapshot of the job’s progress, written to durable storage every so often. After an interruption, a new Pod loads the latest checkpoint and carries on. This one habit turns unreliable cheap machines into a dependable, affordable fleet.

Feeding the hardware

An idle GPU waiting for data is wasted money. Training data should live in fast storage close to the cluster: Cloud Storage with a mounting driver for large datasets, or a shared file system for many readers. Watch GPU utilization in your dashboards, and treat low numbers as a sign of a data or network bottleneck rather than of a hardware shortage.

Large-scale jobs

Some jobs span hundreds or thousands of machines that must work together and talk very fast. These need careful placement, with machines close to each other on the network, and a scheduler that starts all the Pods together or not at all. Teams call this gang scheduling. It is a specialist topic, but it shows why GKE can host such heavy work: its scheduler and networking can be tuned for it.

When dozens of teams share a platform, good intentions are not enough. You need automatic rules that say what is allowed.

Policy as code

A policy is a rule such as “every Pod must declare resource requests”, “images must come from our trusted registry”, or “no Service may expose a public load balancer without approval”. With admission control, the API server checks each new object against such rules before saving it, and rejects those that fail. Tools such as Policy Controller, built on the open-source Gatekeeper and Open Policy Agent, let you write these rules once and apply them across clusters.

Layers of guardrails

Compliance basics

Industries such as finance, health and government must prove they follow rules about data protection, access control and record keeping. GKE helps by supporting encryption with customer-managed keys, detailed audit logs, region choice for data residency, and security posture reports. But compliance is a shared job: Google certifies its platform, and you must show that your own configuration and processes meet the standard. Keep written records of who approved what, and keep your policies in version control so auditors can see their history.

Labels and ownership

Every cluster, namespace and workload should carry labels for owner, product, environment and cost center. These small tags power cost reports, incident routing and policy rules. A resource nobody owns is a resource nobody fixes.

Launching a cluster is the easy day. Keeping it healthy for years is the real job, often called day-two operations.

A symptom-first troubleshooting table

Most problems fall into a few families. Start with the symptom, then check the most likely causes in order.

Service level objectives

A service level objective (SLO) is a promise about quality, such as “99.9 percent of requests succeed over a month”. The gap between perfect and the promise is the error budget. If you are spending the budget slowly, you can ship faster. If it is nearly gone, you slow down and fix reliability. SLOs turn arguments about “is the service good enough?” into measurable answers, and they tell you which alerts truly matter.

Incident habits that work

Routine chores

• Review upgrade notices and deprecated features each month.
• Check certificates, secrets and keys that expire.
• Prune unused images, disks, clusters and load balancers.
• Run a restore test of backups on a schedule.
• Revisit access lists, removing people who have moved on.

Most teams do not start from a blank page. They have existing applications on servers or virtual machines. Here is a sensible way to move.

Three common migration styles

Pitfalls to expect

• Hidden dependencies: applications that rely on fixed IP addresses, local files or specific server names.
• State on disk: data written to the machine’s local disk that must move to proper storage.
• Skills gap: teams need training time. Budget for it, and appoint platform champions.
• Too many services too soon: splitting an application into dozens of microservices at the same moment as migrating doubles the risk. Move first, split later if needed.
• Network latency to old systems: parts left behind on premises may now be farther away. Measure before and after.

A pattern is a proven solution to a common problem. An anti-pattern is a popular mistake that looks reasonable but causes pain.

Patterns worth knowing

Anti-patterns to avoid

If you remember only one chapter for real-world work, make it this one.

A practical order of work for a new production cluster

Common mistakes beginners make

• Starting with too much. Adopting every Kubernetes add-on on day one. Begin simple and add features when a real need appears.
• Ignoring requests and limits. This causes both outages and overspending.
• Exposing services accidentally. A LoadBalancer Service creates a real, public entrance unless you ask for an internal one.
• Running as root. Many images default to it. Switch to an unprivileged user.
• Skipping upgrades. Falling many versions behind forces risky big-bang upgrades and may leave you on unsupported software.
• One replica of everything. It makes every update a mini-outage.
• Forgetting about quotas and addresses. The cluster cannot grow beyond them.
• Storing secrets in source code. Anyone with repository access gets the keys.
• No cost visibility. Without labels and budgets, nobody owns the bill.
• Debugging by hand in production. Manual fixes disappear on the next deployment and hide the real cause.

Here is how well-known kinds of organizations use GKE, based on publicly shared stories and common industry practice.

GKE takes the hardest part of Kubernetes, running the brain of the cluster, and hands it to Google, so that your team can spend its energy on the applications that earn money. You describe what you want, and layers of control loops make it true and keep it true: Pods restart, nodes heal, traffic shifts, and capacity grows and shrinks. The platform is powerful, but it rewards discipline. Clear requests, honest probes, tight permissions, tested recovery and steady cost reviews separate calm production clusters from stressful ones.