Cluster FieldbookGKE platform architect
GKE · Platform ArchitectureView Markdown source

Scheduling, capacity, and autoscaling

Scheduling places Pods on capacity that satisfies resources and placement rules.

Four scaling loops

  • Horizontal Pod Autoscaler (HPA) changes Pod replicas from metrics.
  • Vertical Pod Autoscaler (VPA) recommends or changes Pod requests.
  • Cluster autoscaler changes Standard node-pool size.
  • Node auto-provisioning or Autopilot creates suitable capacity.

These loops interact. HPA cannot help if Pods are unschedulable and no capacity can arrive. Scaling from zero may add startup delay. Downstream systems may fail before the cluster reaches its maximum.

Placement

Use node selectors or affinity for required hardware. Use taints and tolerations to reserve capacity. Use topology spread and Pod anti-affinity for fault distribution. Avoid rules so strict that Pods cannot schedule during failure.

Resources

Set requests from measured usage plus headroom. A too-low CPU request harms scheduling and HPA behavior; a too-high request wastes capacity. Memory limits can cause OOM kills. CPU limits can throttle. Treat defaults as a starting point.

Priority

PriorityClass helps important Pods schedule under pressure, but preemption can remove lower-priority work. Reserve it for explicit business importance and test overload behavior.

Architect test

Load-test the entire scaling path: metrics collection, HPA reaction, node provisioning, image pulling, startup, readiness, downstream capacity, and scale-down. A YAML value is not proof of elasticity.

Cluster FieldbookIndependent study material · verify production details in Google Cloud documentation