Exercise 1: Requests vs. Limits — Who Uses Which — Possible Solution
====================================================================

REQUESTS are used by the SCHEDULER. Per the chapter, "a request is the
amount of CPU/memory a container is guaranteed to get, and specifically
what Chapter 2's scheduler uses when deciding which node has enough
available capacity to place a pod on." This happens at SCHEDULING
TIME, BEFORE the pod is even running -- the scheduler looks at each
candidate node's remaining available capacity and compares it against
the pod's requested resources, only placing the pod on a node that has
enough requested capacity free. Requests never change once the pod is
running; they're purely a scheduling-time input.

LIMITS are enforced by the CONTAINER RUNTIME, at ACTUAL RUNTIME, after
the pod is already running. Per the chapter, "a limit is the maximum a
container is allowed to use, enforced by the container runtime." This
happens continuously WHILE the container is executing -- the runtime
actively watches the container's real resource usage and takes action
(throttling for CPU, killing for memory, per the chapter's own
distinction) the moment usage would exceed the configured limit.

Summary: requests answer the question "where should this pod be
placed, given what it says it needs?" (a scheduling-time decision).
Limits answer the question "how much is this container allowed to
actually consume once it's running?" (a runtime enforcement action).
A pod could, in principle, be scheduled based on a modest request and
then still be constrained by a separately-configured, possibly higher,
limit once it's actually running -- the two numbers serve genuinely
different purposes at genuinely different points in the pod's
lifecycle.

WHY THIS WORKS AS AN ANSWER
------------------------------
This distinguishes requests and limits by WHEN in the pod's lifecycle
each one applies (scheduling time vs. continuous runtime enforcement)
and WHO specifically uses each one (the scheduler component from
Chapter 2 vs. the container runtime component also from Chapter 2) --
directly matching the chapter's own explicit attribution of each to a
specific system component.