Exercise 2: What HPA and VPA Each Scale, and Why Combining Them on CPU Can Conflict — Possible Solution
====================================================================

What each one scales:

HPA scales the NUMBER OF PODS (the replica count) -- per the chapter,
it "automatically adjusts a Deployment's... replica count." It doesn't
touch any individual pod's own resource configuration at all; it just
creates or removes whole additional copies.

VPA scales the SIZE of each individual pod -- per the chapter, it
"adjusts the resource requests/limits... of EXISTING pods," making
each pod itself bigger or smaller in terms of CPU/memory allocation,
without changing how MANY pods exist.

In short: HPA answers "how many," VPA answers "how big each one is" --
two genuinely different scaling dimensions.

Why running both on the same CPU-based metric simultaneously can
cause confusing behavior:

Per the chapter's own explicit warning, "VPA changing requests changes
what '70% utilization' even MEANS for HPA's own calculation." HPA's
utilization percentage is calculated as (actual CPU usage) / (CPU
request) -- and CPU REQUEST is exactly the value VPA is actively
changing.

Concretely: imagine a pod is using a fairly constant amount of real
CPU. If VPA decides to INCREASE that pod's CPU request (based on its
own longer-term usage observations), the SAME actual CPU usage now
represents a SMALLER percentage of the (now larger) request -- which
could cause HPA to conclude utilization has dropped and scale the
replica count DOWN, even though nothing about the real workload's
actual demand changed at all. Conversely, if VPA decreases the
request, the same real usage suddenly looks like a HIGHER percentage,
potentially triggering HPA to scale UP unnecessarily.

The two controllers end up reacting to CHANGES THE OTHER ONE CAUSED,
rather than to genuine shifts in real demand -- HPA's decisions become
partly driven by VPA's own adjustments rather than purely by actual
load, producing scaling behavior that's difficult to predict or
reason about, exactly the "confusing, conflicting behavior" the
chapter warns against.

WHY THIS WORKS AS AN ANSWER
------------------------------
This distinguishes the two dimensions each controller scales (count
vs. size) and then works through the specific mechanism -- HPA's
percentage calculation using CPU request as its denominator, which VPA
is simultaneously changing -- that produces the chapter's own named
conflict, rather than just asserting the two "can conflict" without
explaining the causal chain.