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.