Right, let’s talk about the plumbing. You’ve got your shiny Network Policies written, a set of perfect, declarative rules telling your pods exactly who they can and can’t talk to. You apply them…and nothing happens. The traffic flows merrily along, completely ignoring your carefully crafted security intentions.

Welcome to the most common “oh crap” moment with Network Policies. The truth they don’t lead with in the marketing docs is this: Network Policies are not a feature of Kubernetes itself. They are a specification. It’s a wish list you hand off to the actual entity running your cluster’s network: the Container Network Interface (CNI) plugin.

Think of it like this: the Kubernetes API is the legislature, passing laws (NetworkPolicy objects). But without a police force (the CNI plugin) to enforce them, those laws are just suggestions written on fancy paper. If your CNI plugin is just a simple bridge-layer (like kubenet or Flannel in its default mode), it will shrug at your NetworkPolicy and go back to letting everyone talk to everyone. You need a CNI plugin that is, in industry parlance, “NetworkPolicy-aware.”

The Enforcers: Calico, Cilium, and Weave

The big three enforcers you’ll encounter are Calico, Cilium, and WeaveNet. They all implement the NetworkPolicy spec, but how they do it and what extra goodies they offer varies wildly. This isn’t a committee-designed standard; each team took their own brilliant, opinionated path.

Calico: The Battle-Tested Enforcer

Calico is the old reliable. It doesn’t mess around with fancy magic; it takes your NetworkPolicy rules and compiles them down into brutally efficient iptables rules on each node. It’s like a network administrator who’s been around the block and speaks in raw packet filters.

Why you might pick it: It’s performant, predictable, and its operational model is very straightforward for anyone coming from a traditional networking background. It also has a rich policy language of its own (Calico Network Policy) that can do things the standard Kubernetes spec can’t, like deny rules and order-of-precedence.

The rough edge: Because it’s often using iptables under the hood, debugging can be a nightmare. You’re trying to trace why pod A can’t talk to service B, and you end up knee-deep in a chain of 100 iptables rules on the host node. It’s powerful, but it can feel a bit like the plumbing in an old house.

Here’s a quick example of applying a policy. It works the same as with any CNI, but Calico is the one enforcing it.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-dns-only
  namespace: production
spec:
  podSelector: {} # Applies to all pods in the namespace
  policyTypes:
  - Egress
  egress:
  - to: # First rule: allow egress to the kube-dns pods
    - namespaceSelector:
        matchLabels:
          kubernetes.io/metadata.name: kube-system
      podSelector:
        matchLabels:
          k8s-app: kube-dns
    ports:
    - protocol: UDP
      port: 53
  - to: # Second rule: deny ALL other egress traffic
    - podSelector: {} # This empty selector matches nothing, effectively blocking all other egress.

Cilium: The Next-Gen Supercop

If Calico is the beat cop, Cilium is the spec-ops team with satellite surveillance. Instead of iptables, it uses eBPF—a technology that allows you to run sandboxed programs deep inside the Linux kernel. This is a paradigm shift.

Why it’s a game-changer: eBPF is insanely efficient and provides observability you can only dream of with iptables. Cilium can enforce network policies based on application-layer protocols (e.g., “allow GET /api but not POST /api”) and has built-in, killer observability tools that show you exactly why a packet was allowed or dropped. It’s not just enforcing policy; it’s explaining it.

The questionable choice (or rather, complexity): The power of eBPF comes with a steeper learning curve. The concepts are different, and the troubleshooting tools are entirely its own. You’re not just learning Kubernetes networking; you’re learning a slice of cutting-edge Linux kernel programming.

# With Cilium, you can do wild things like trace policy decisions in real-time.
# This is the kind of power that makes network engineers weep with joy.
cilium monitor --type policy

Weave: The Easy-Button (That Can Still Enforce)

WeaveNet is often the default in simple installs like kubeadm with Weave. It’s designed to “just work,” creating a mesh overlay network between nodes. Crucially, it also has a NetworkPolicy controller.

Why you might use it: It’s famously easy to set up and has sensible defaults. For a cluster where you need basic policy enforcement without a lot of fuss, it’s a solid choice.

The pitfall: While it works, it’s generally not considered as high-performance or feature-rich as Calico or Cilium for large-scale or complex deployments. It’s the reliable compact car, not the tuned sports car or the armored truck.

The Golden Rule: Test Your CNI Plugin

Never assume. The first thing you should do in any new cluster is run a quick test to see if Network Policies are actually enforced. Here’s the canonical smoke test. It creates a default-deny all policy and checks if a pod can still talk to the internet.

# Create a namespace for testing
kubectl create namespace network-policy-test

# Launch a simple pod with curl
kubectl run test-pod --image=radial/busyboxplus:curl -i --tty --rm --namespace=network-policy-test --command -- sh

# FROM INSIDE THE POD, try to curl google.com. It should work.
curl -I https://google.com

# Now, apply a default-deny all policy for the namespace
cat <<EOF | kubectl apply -n network-policy-test -f -
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress
EOF

# Try your curl command again from inside the pod. It should now time out.
# If it still works, your CNI plugin is NOT enforcing policies. Panic accordingly.
curl -I --connect-timeout 5 https://google.com

The takeaway? Always know your police force. Your Network Policies are only as good as the CNI plugin that’s there to back them up. Choose and operate accordingly.