Exercise 1: Why DaemonSets Don't Have a Specified Replica Count — Possible Solution
====================================================================

Why the count isn't directly specified:

Per the chapter, "a DaemonSet's desired count is inherently tied to
the NUMBER OF NODES, not an arbitrary number you specify." A
Deployment's replica count is an independent, arbitrary business
decision -- "I want 5 copies of my web server," a number that has
nothing to do with how many nodes the cluster happens to have. A
DaemonSet's whole purpose is fundamentally different: it needs to
guarantee coverage of EVERY node (or every node matching a selector),
which means its correct count is always, automatically, "however many
matching nodes currently exist in the cluster" -- a number that
changes on its own whenever nodes are added or removed, without
anyone needing to manually update a `replicas` field to match.

If a DaemonSet DID require manually specifying a count, that count
would need to be kept in sync by hand every single time a node was
added or removed from the cluster -- exactly the kind of manual
tracking Kubernetes' reconciliation loop (Chapter 2, Course 1) exists
to eliminate. By defining the DaemonSet's desired state as "one pod
per matching node" rather than a fixed number, the reconciliation loop
can automatically create a new pod the moment a new node joins,
without any human intervention or a config update -- exactly the
behavior the chapter describes.

Concrete example of a workload that needs to run on every node:

A LOG COLLECTION AGENT (e.g. Fluentd/Fluent Bit), per the chapter's
own example. Every node runs its own set of containers, each
generating its own local logs. For those logs to be collected and
forwarded centrally, an agent needs to be present ON EVERY SINGLE
NODE specifically to read that node's own local log files/streams --
a single or a few Fluentd pods running as an ordinary Deployment,
placed on only a handful of nodes by the scheduler, would completely
miss the logs generated on every OTHER node that doesn't happen to
have one running.

WHY THIS WORKS AS AN ANSWER
------------------------------
This explains why "one per node" as a CONCEPT is fundamentally
different from "N replicas" as a concept -- one tracks a
cluster-topology fact that changes on its own, the other is an
arbitrary business decision -- and then applies the chapter's own
log-agent example to show concretely why per-node coverage, not just
"some copies somewhere," is the actual requirement.