Real-life scenario: Global Service Platform

This fictional scenario shows how a GKE architect supports a global enterprise.

Situation

ToolWorks sells equipment in 55 countries. Customer web/mobile channels use APIs running on GKE. SAP owns orders and product prices, Salesforce owns sales activity, and Workday owns employee/territory data. Campaign traffic grows ten times. Teams currently deploy manually and one bad cluster role can affect all applications.

Goals: faster delivery, 99.95% checkout availability, controlled personal data, no duplicate orders, recovery within one hour with no more than five minutes of data loss, and clear platform cost.

Architecture decision

Use separate production and non-production projects in a governed folder, Shared VPC, central logging/security projects, and regional Autopilot clusters. Autopilot reduces node operations; no workload has a proven node-level need. Fleets group clusters, while Config Sync and Policy Controller roll out platform configuration through audit, canary, and enforcement stages.

Cloud Load Balancing and Gateway API expose services; Cloud Armor protects the public edge. Private nodes, Cloud NAT, Private Google Access, Dataplane V2, and default-deny NetworkPolicy control paths. Each workload has a dedicated Kubernetes service account mapped through Workload Identity Federation.

Artifact Registry holds scanned immutable images. CI builds once and produces provenance. Binary Authorization permits approved images. Cloud Deploy canaries releases and stops promotion when SLO burn is high.

Enterprise integration

Customer APIs commit channel transactions to a managed database and publish orders to Pub/Sub. A GKE worker consumes idempotently and calls the governed SAP integration API. Pub/Sub buffers campaign spikes and failed messages enter a dead-letter path with reconciliation. Salesforce and Workday changes arrive through approved APIs/files into normalized events. No service reads another system's database directly.

Reliability

Deployments use at least three replicas, topology spread, readiness/startup probes, graceful termination, and disruption budgets. HPA scales from request and queue signals. Autopilot provides capacity; load tests include cold scale-up. Cloud SQL/Spanner design follows data requirements and the agreed RPO.

Backup for GKE protects Kubernetes resources and eligible volumes; IaC rebuilds clusters and cloud services; registries preserve images. A prepared secondary region receives restored configuration/data during scheduled game days. DNS and traffic failover are tested, not assumed.

Operations and outcomes

Cloud Monitoring dashboards show checkout SLO, latency, Pub/Sub backlog, SAP errors, Pod restarts, unschedulable Pods, rollout status, security findings, and cost per order. Measure duplicate orders, recovery time, deployment frequency, change failure rate, policy violations, and idle requested CPU.

Important trade-offs

Autopilot removes node management but limits privileged/node-level patterns.
Async SAP integration protects checkout but introduces a pending order state.
A fleet creates consistency but a bad global policy creates wide blast radius.
Multi-region recovery meets the business target but requires rehearsed data, identity, secrets, DNS, and operations—not only a second cluster.