Exercise 1: Why Pods, Not Containers, and a Sidecar Example — Possible Solution
====================================================================

Why Kubernetes schedules Pods rather than individual containers:

Per the chapter, some workloads genuinely need multiple tightly-
coupled containers that must always be scheduled TOGETHER on the same
node, share the same network namespace, and share storage directly --
and must live and die as a unit rather than independently. If
Kubernetes scheduled containers individually, there would be no
guarantee that two containers meant to work together would even end
up on the same node, let alone share localhost networking or a
filesystem. The Pod exists specifically as the grouping boundary that
guarantees this -- it's also, per the chapter, "the smallest unit
Kubernetes can create, schedule, or scale," meaning Kubernetes always
reasons in terms of whole pods, never partial ones.

A concrete sidecar example:

A web application container writes its access logs to a local file on
a shared volume within its pod, but has no built-in capability to ship
those logs anywhere centralized. A LOGGING SIDECAR container, running
alongside the main application container in the SAME pod, mounts that
same shared volume, continuously reads the log file as it grows, and
forwards each new entry to a centralized log-aggregation system.

This makes sense as a sidecar specifically because: the two containers
need to share a VOLUME directly (per the chapter's own explanation of
what a pod provides), they need to be scheduled onto the SAME node
together (there's no benefit to the log-shipper running somewhere else
entirely), and they should be deployed and scaled TOGETHER as a unit
-- if there are 5 replicas of the application, there should be 5
matching log-shippers, one per pod, not a separately managed fleet.

WHY THIS WORKS AS AN ANSWER
------------------------------
This directly uses the chapter's own stated reasons for the Pod
abstraction (co-scheduling, shared network, shared storage) to justify
WHY containers aren't scheduled individually, and the logging-sidecar
example is explicitly named in the chapter itself as a genuine,
common real-world case -- expanded here with the specific
shared-volume mechanism that makes it a sidecar rather than a
separate, independently-deployed service.