Exercise 2: What a CNI Plugin Does, and Why "My NetworkPolicy Isn't Working" May Not Be the YAML's Fault — Possible Solution
====================================================================

What a CNI plugin is responsible for:

Per the chapter, "Kubernetes itself doesn't implement pod networking
directly -- it delegates this to a CNI (Container Network Interface)
plugin." The CNI plugin is the actual software responsible for setting
up the real, underlying pod-to-pod network connectivity -- assigning
pod IP addresses, routing traffic between pods (potentially across
different nodes), and, for plugins that support it, actually ENFORCING
NetworkPolicy rules at the network level.

Why "my NetworkPolicy isn't working" might have nothing to do with the
policy's own YAML:

Per the chapter, "some CNI plugins ALSO implement Network Policies...
while simpler ones (like basic Flannel) don't." A NetworkPolicy
resource, like any Kubernetes object, is just DATA stored via the API
server -- creating it successfully only means the API server accepted
and stored the resource; it says nothing about whether anything is
actually ENFORCING it. If the cluster's CNI plugin doesn't implement
Network Policy support at all, a perfectly well-written, syntactically
correct NetworkPolicy will simply be ignored -- the traffic restriction
it describes never actually takes effect, even though the resource
itself exists in the cluster with no errors.

This is structurally the SAME category of confusion as `k8s1-9`'s own
"an Ingress resource does nothing without a controller" point -- a
correctly-written Kubernetes resource describing an intention doesn't
automatically mean something is actually ACTING on that intention.
Before assuming a NetworkPolicy's own rules are wrong, it's worth
confirming the cluster's CNI plugin actually supports Network Policy
enforcement at all -- a completely different category of problem than
a YAML mistake.

WHY THIS WORKS AS AN ANSWER
------------------------------
This explains the CNI's actual responsibility (implementing real
pod-to-pod connectivity, optionally including policy enforcement) and
then draws the explicit parallel to `k8s1-9`'s Ingress-without-a-
controller confusion, showing this is the SAME underlying category of
mistake -- a resource existing correctly in the cluster doesn't
guarantee anything is enforcing it.