Exercise 3: An HPA That Never Scales Despite Heavy Load — Likely Root Cause — Possible Solution
====================================================================

The genuinely likely root cause worth checking first: whether the
METRICS SERVER is actually installed and running in the cluster at
all.

Why, per this chapter's own material:

The chapter states directly, in its own warn-box: "the Metrics Server
is what actually powers... HPA (Chapter 6) actually queries for CPU/
memory data. Without it installed, resource-based HPA simply doesn't
work at all." An HPA configured with entirely correct, reasonable CPU
thresholds is still fundamentally dependent on SOMETHING actually
supplying it with real, current CPU utilization numbers to compare
against those thresholds -- and that "something" is specifically the
Metrics Server. If it isn't installed, HPA has no metric data to
evaluate at all, and simply never has any basis to decide a scale-up
is warranted, REGARDLESS of how correctly its thresholds are
configured or how heavy the real load actually is.

This is directly the same category of problem the chapter explicitly
compares it to: `k8s1-9`'s "an Ingress resource does nothing without a
controller" pattern -- a correctly-configured Kubernetes resource
(the HPA object itself, or an Ingress object) can exist perfectly
correctly in the cluster while accomplishing NOTHING, because the
separate piece of infrastructure actually required to ACT on that
resource's configuration was never installed or running in the first
place.

Why this is worth checking FIRST, specifically: the symptom described
-- "configured correctly... but never scales at all" -- is exactly the
signature of a MISSING DEPENDENCY rather than a misconfiguration
within the HPA's own settings. If the thresholds themselves were wrong
(too high, for instance), the HPA would still be actively evaluating
metrics and simply concluding scaling isn't warranted -- but "never
scales AT ALL, even under genuinely heavy load" more strongly suggests
the HPA has no metric data to evaluate in the first place, which is
exactly what a missing Metrics Server would cause. Checking `kubectl
top pods` (which the chapter also notes depends on Metrics Server) is
a fast, direct way to confirm this -- if that command itself fails or
returns nothing, Metrics Server is the answer.

WHY THIS WORKS AS AN ANSWER
------------------------------
This directly cites the chapter's own explicit warn-box scenario,
explains why the reported symptom (never scales, not "scales
incorrectly") specifically points at a missing dependency rather than
a threshold misconfiguration, and names a concrete, fast diagnostic
step (`kubectl top pods`) the chapter itself connects to Metrics
Server's presence.