Google Kubernetes Engine provides managed Kubernetes control planes with Autopilot and Standard operating modes. Autopilot manages more node infrastructure and enforces a stronger managed posture; Standard exposes more node and cluster configuration.
GKE earns its operational cost when a team needs Kubernetes APIs, controllers, scheduling behavior, multi-container workload patterns, or platform portability that a simpler managed runtime cannot provide.
Autopilot reduces node administration and bills according to its workload model, with constraints that support the managed environment. Standard is appropriate when node pools, machine families, privileged behavior, accelerators, or specialized networking require direct control.
Regional topology, release channel, maintenance windows, private control-plane access, fleet policy, and upgrade behavior should be chosen before applications depend on the cluster.
Requests guide scheduling and cost; limits constrain resource use. Missing requests make placement and autoscaling unreliable, while very tight limits can create throttling or termination under normal bursts.
Readiness gates traffic, liveness can restart a stuck container, and startup probes protect slow initialization. Workload Identity Federation for GKE maps Kubernetes service accounts to Google Cloud access without mounting long-lived keys.
kubectl apply -f deployment.yaml
kubectl autoscale deployment orders-api \
--cpu-percent=70 --min=2 --max=8
kubectl get deployment,pods,hpa
kubectl describe hpa orders-apiWhen a pod is pending, inspect events, requests, node capacity, affinity, taints, volumes, and quota. For crash loops, compare exit code, previous logs, command, configuration, probes, and dependency availability.
A production platform also needs policy enforcement, image provenance, network policy, secret handling, observability, backup of stateful dependencies, upgrade rehearsals, and a clear boundary between platform and application teams.
GKE Autopilot manages nodes, scaling infrastructure, and many security defaults while charging primarily from requested Pod resources and selected compute behavior. Standard mode exposes node pools and more infrastructure choices. Choose Autopilot for compatible workloads when reduced node operations is valuable; choose Standard when the workload needs unsupported privileges, specialized node control, or an operational model the team is prepared to own.
Mode choice does not remove Kubernetes responsibilities. Teams still own workload manifests, requests and limits, probes, disruption behavior, RBAC, network policy, application identity, data protection, observability, and release safety. Autopilot admission constraints can reject privileged or host-dependent workloads; test third-party agents and storage drivers before committing.
Define cluster boundaries from trust, environment, blast radius, tenancy, regional topology, policy, and team ownership. Namespaces organize and scope many controls but do not provide every form of hard isolation. A single very large cluster can concentrate failure and authorization risk, while many tiny clusters multiply upgrades, policy, networking, and observability work.
Resource requests drive scheduling and, in Autopilot, influence provisioned compute and billing. Limits constrain runtime use. Set both from observed CPU, memory, ephemeral storage, latency, and burst behavior; a missing request hides capacity needs, while a low memory limit creates repeated out-of-memory restarts. Vertical and horizontal autoscaling require clear ownership so two controllers do not fight over the same signal.
Readiness decides whether a Pod receives Service traffic, liveness decides whether a stuck container should restart, and startup probes protect slow initialization from premature liveness failure. Probes should test the narrow condition they control. A liveness probe that depends on an unavailable database can restart an entire healthy fleet and amplify the outage.
Topology spread constraints, affinity, anti-affinity, taints, tolerations, ComputeClasses, and node selectors influence placement. Express availability intent without making the Pod unschedulable when a zone or hardware class is scarce. Inspect pending Pod events and scheduler reasons before increasing cluster size or weakening constraints.
Kubernetes RBAC authorizes actions against the cluster API, while Google Cloud IAM authorizes Google resources and controls cluster discovery or administrative operations. Workload Identity Federation for GKE lets a Kubernetes workload obtain Google credentials without node-wide service-account keys. Bind each Kubernetes service account to only the Google permissions its workload requires.
Apply Pod Security standards or stronger admission policy, run as a non-root user where possible, drop capabilities, use read-only filesystems, pin image digests, and scan artifacts. Secrets stored in Kubernetes are not automatically a complete secret-management strategy; restrict etcd and API access, consider Secret Manager integration, and rotate consumers as well as secret values.
VPC-native clusters allocate routable Pod addresses from secondary ranges. NetworkPolicy or supported policy enforcement limits Pod traffic but needs a default-deny and explicit-allow design, DNS allowance, observability, and testing. Firewall rules, Services, Ingress or Gateway resources, load balancers, and Cloud NAT operate at different layers. Trace a connection through every layer before changing them.
GKE upgrades control planes and nodes to supported versions according to release channels and maintenance policy. Autopilot upgrades are automatic; Standard also uses managed control-plane upgrades and commonly auto-upgraded nodes. Read release notes, check deprecated Kubernetes APIs, test the next version in a representative cluster, and use maintenance windows and exclusions for timing rather than attempting to avoid upgrades indefinitely.
A PodDisruptionBudget limits voluntary simultaneous disruption but does not guarantee availability during node failure, application crash, or a bad rollout. Combine multiple replicas, topology spread, correct readiness, sufficient spare capacity, graceful termination, and a Deployment strategy. A restrictive budget with no headroom can block node upgrades, while one replica cannot remain available during every disruption.
During termination, stop accepting new work, complete or checkpoint bounded work, close connections, flush telemetry, and exit before the grace period. Test node drain, node auto-upgrade, zone loss, image pull failure, unavailable secret, exhausted Pod range, and control-plane access failure. Observe business service levels throughout the exercise rather than declaring success when Kubernetes objects return to Ready.
Infrastructure-as-code can recreate cluster configuration, but it does not automatically restore persistent volume data, application custom resources, external DNS, secrets, or database state. Inventory which resources are authoritative inside Kubernetes and which are projections from another system. Back up only with a tested restore target and compatible storage behavior.
A recovery exercise should create or select a clean cluster, restore policy and workload objects in dependency order, recover data, reconnect external services, and validate user journeys. Avoid restoring obsolete node-specific settings or compromised credentials blindly. Confirm admission policy and Workload Identity bindings before workloads start processing.
Measure cluster creation, image pull, data restore, DNS change, cache warm-up, and backlog drain separately. Retain manifests and backup catalogs outside the failed cluster boundary. If recovery depends on a custom operator, verify its image and custom resource definitions are available before restoring objects it controls.
Review volume snapshot consistency with the application that owns the data. A storage snapshot taken without quiescing writes may be crash-consistent but still require database or filesystem recovery. For stateful sets, preserve the mapping between identity and volume where the application expects it, and rehearse restore under a different cluster identifier.
A deployment loses availability when nodes drain during an upgrade.
Constraints: The workload needs two replicas, has a disruption budget, and takes 40 seconds to become ready.
Decision: Add a truthful readiness probe, spread replicas, define a compatible disruption budget, and rehearse a surge upgrade.
Verification: Requests remain successful while pods reschedule and no unavailable count exceeds the budget.
Failure test: Make readiness depend on a failed downstream service and confirm the rollout pauses rather than shifting traffic.Expected evidence: Requests remain successful while pods reschedule and no unavailable count exceeds the budget.It changes desired pod replicas. A cluster autoscaling mechanism must separately provide node capacity when existing nodes cannot schedule those pods.
Usually not. Cluster boundaries should follow tenancy, policy, reliability, regional, and operational needs; namespaces and policy can isolate many workloads within a cluster.
Explore 500+ free tutorials across 20+ languages and frameworks.