11.4 Horizontal and Vertical Pod Autoscaling in GKE

Why This Topic Matters

The last GKE-specific bullet in exam Domain 4 is "managing Horizontal and Vertical Pod Autoscaling" — and it is tested precisely because the two mechanisms sound similar but solve opposite problems, and combining them incorrectly is a real production failure mode, not just a trivia distinction. Expect ACE scenarios that describe a workload's traffic pattern (spiky vs. steady-but-unpredictable) and ask which autoscaler — or which combination — is the right fit.

Horizontal Pod Autoscaler (HPA): Scaling Out and In

The Horizontal Pod Autoscaler runs a control loop that periodically checks a workload's observed metrics against configured target thresholds and changes the number of Pod replicas accordingly — more replicas under load, fewer when load drops. Three categories of metrics can drive it:

Two mechanics matter for exam scenarios:

• Percentage-based targets require resource requests. If a container has no CPU/memory requests set, HPA cannot compute "current usage as a percentage of requested resources," so percentage targets simply won't function — a common root-cause question on the exam ("HPA isn't scaling at all — why?" → missing resource requests).
• Anti-flapping safeguard. To avoid rapid, repeated scaling in both directions, HPA "chooses the largest recommendation based on the last five minutes" of observed data rather than reacting instantly to every metric fluctuation. When multiple metrics are configured and one becomes temporarily unavailable, HPA will still scale up based on the largest calculable size, but it will not scale down until all metrics are healthy again — a deliberately conservative, availability-favoring default.

Creating an HPA is a one-line imperative command or a declarative object:

kubectl autoscale deployment my-app --cpu-percent=60 --min=2 --max=10

Vertical Pod Autoscaler (VPA): Scaling Up and Down

Where HPA changes replica count, the Vertical Pod Autoscaler changes the CPU and memory requests and limits of the Pods themselves, based on analyzed historical usage. VPA computes a target recommendation plus lower/upper bounds, and applies it according to one of four update modes:

VPA is designed for long-running, relatively homogeneous workloads and needs roughly 24 hours of historical usage data before its recommendations reach high confidence. It is explicitly not a fit for workloads with sudden traffic spikes — horizontal scaling handles those far better, because VPA's Auto mode reacts by recreating Pods, which is disruptive if triggered constantly.

The Conflict Rule and Multidimensional Pod Autoscaling

The single most exam-relevant rule in this section: HPA and VPA must never be configured to scale based on the same metric for the same workload. If HPA is watching CPU utilization to add/remove replicas while VPA is simultaneously watching CPU utilization to resize each Pod's CPU request, the two controllers fight each other — VPA's resizing changes the percentage HPA is measuring against, producing unstable, conflicting scaling decisions.

Multidimensional Pod autoscaling is the supported way to run both at once: split responsibility by dimension. A common, exam-favored pattern is VPA manages memory requests/limits (rightsizing to avoid OOM-kills or wasted memory) while HPA manages replica count based on CPU or a custom/external metric. Each autoscaler owns a distinct resource dimension, so they never contend for the same signal.

HPA vs. VPA vs. Cluster Autoscaler: Don't Confuse the Layers

Exam distractors frequently blend Pod-level autoscaling with node-level (cluster) autoscaling:

Cluster Autoscaler operates one layer below both Pod autoscalers: it doesn't look at Pod metrics directly, but reacts to whether Pods can currently be scheduled onto existing node capacity. All three can run together in a healthy cluster, but each solves a distinct scaling question — Pod count, Pod size, or node count.

Realistic Exam Scenario

A checkout API sees sharp, unpredictable traffic spikes during flash sales, while a nightly batch-reporting job has a steady but hard-to-predict memory footprint that occasionally causes OOM-kills. The ACE-correct design: put HPA on the checkout API, targeting CPU or requests-per-second with a wide min/max replica range to absorb spikes quickly, and put VPA in Auto mode on the batch job, letting it right-size memory requests over time from historical usage — since batch jobs tolerate a Pod recreation far better than a spiky, latency-sensitive API does. Neither autoscaler is applied to the same metric on the same workload.