Exercise 3: Which QoS Class Gets Evicted First Under Resource Pressure — Possible Solution
====================================================================

The BestEffort pod is likely to be evicted first.

Reasoning, per the chapter's own QoS table and its explicit ordering:

GUARANTEED (requests = limits for every resource): this is the
"highest priority, least likely to be evicted" class. Because its
requests exactly match its limits, Kubernetes has the strongest
possible guarantee about exactly how much of each resource this pod
will consume -- there's no ambiguity or risk of it silently
overconsuming beyond what was already accounted for when it was
scheduled, making it the safest pod to leave running under pressure.

BURSTABLE (requests set, limits higher or unset): described as "the
common middle case" -- it has SOME resource guarantee (its request),
but also has room to consume more than its request up to its limit
(or without a hard ceiling at all, if limits are unset). This
introduces more uncertainty than Guaranteed, but still has a real,
declared request establishing some baseline priority.

BESTEFFORT (no requests/limits set at all): described directly as
"lowest priority, first evicted under pressure." This pod made NO
resource guarantees or claims about its needs whatsoever when it was
scheduled -- Kubernetes has no information suggesting this pod
requires any particular amount of resources to function, which is
exactly why it's treated as having a lower priority claim on the
node's resources than pods that DID declare and reserve resources for
themselves.

Why this ordering makes practical sense: pods that explicitly declared
(and had the scheduler account for) their resource needs represent a
stronger, more deliberate commitment that Kubernetes has already
factored into its scheduling decisions. A BestEffort pod, having made
no such commitment, is the pod Kubernetes can remove with the least
disruption to the guarantees it has already made to OTHER,
resource-declaring pods on the same node -- which is exactly why it's
evicted first when the node needs to free up capacity.

WHY THIS WORKS AS AN ANSWER
------------------------------
This directly applies the chapter's own explicitly stated eviction
priority ordering (Guaranteed safest, BestEffort first) and explains
the underlying LOGIC behind that ordering -- pods that made stronger,
more specific resource commitments are protected first, while pods
that made no commitment at all have the weakest claim to continued
residency on a resource-constrained node.