---
title: "How GKE works"
chapter: "02"
---

# How GKE works

A GKE cluster has a Kubernetes **control plane** and **worker capacity**.
Google manages the control plane. Your workloads run in Pods on managed compute.

## Responsibility boundary

Google operates control-plane infrastructure and the managed GKE service. The
customer still owns identities, IAM and RBAC, workload code, container images,
Pod security, network policy, data protection, configuration, availability
design, and incident response. In Standard, the customer also makes more node
and node-pool decisions. In Autopilot, Google manages nodes, scaling, security
settings, and many defaults.

## Regional and zonal clusters

Autopilot clusters are regional. A regional Standard cluster replicates its
control plane across zones and can spread nodes across zones. A zonal Standard
cluster has a lower-availability control-plane design. Production systems should
start from business availability requirements, not the cheapest cluster shape.

## VPC-native networking

GKE is normally VPC-native: Pods and Services use alias IP ranges. Plan Pod,
Service, node, and control-plane address space early. IP exhaustion is an
architecture problem, not a late operations detail.

## GKE and Google Cloud

GKE commonly integrates with Artifact Registry, Cloud Load Balancing, Cloud
DNS, Cloud NAT, Cloud Armor, IAM, Secret Manager, Cloud KMS, Cloud Logging,
Cloud Monitoring, Managed Service for Prometheus, Cloud SQL, Spanner, Pub/Sub,
and Backup for GKE.

## Design question

Do not ask only “How many clusters?” Ask which failures, trust boundaries,
environments, teams, versions, quotas, and network domains must be isolated.
Every extra cluster improves some isolation but adds fleet, delivery, upgrade,
policy, and observability work.