Calico vs Cilium: Kubernetes CNI for a Home Cluster

Set up a fresh Kubernetes cluster and one of the first decisions you’re handed is also one of the least explained: which CNI? Your nodes sit there in NotReady, the docs wave vaguely at a list, and you pick whatever the tutorial used. Months later you’re trying to write a NetworkPolicy or debug a packet that vanishes, and you finally wish you’d understood the choice.

The Container Network Interface is the plugin that gives every pod an IP and makes pods on different nodes able to talk to each other. Without one, your cluster is a collection of isolated boxes. For self-hosters, two names dominate the conversation: Calico and Cilium. They reach the same destination by very different roads.

1 What a CNI is on the hook for

Two jobs, fundamentally. First, connectivity: every pod gets an IP, and traffic finds its way across nodes, usually via an overlay network (encapsulating pod traffic inside node-to-node packets) or via plain routing where your network already knows the pod routes. Second, policy: NetworkPolicies that say “these pods may talk to those pods, and nothing else.” A bare cluster allows all pod-to-pod traffic by default, which is fine until it very much isn’t.

How a CNI does these two jobs is where Calico and Cilium part ways, and it comes down to one acronym.

2 Calico: routing you can reason about

Calico is the dependable, widely-deployed choice. Its standard mode does pod networking with straightforward Linux routing and iptables (or the newer eBPF dataplane if you opt in), and it can run as a pure layer-3 router that advertises pod routes over BGP — no overlay, no encapsulation overhead, packets that look like normal packets.

For a homelab the appeal is that it’s legible. When something breaks, you can ip route, iptables -L, and tcpdump your way to an answer using tools you already know. It’s been around a long time, the docs are excellent, and it does the job without drama. NetworkPolicy support is solid and it adds its own richer policy CRDs on top of the standard Kubernetes ones.

A minimal default-deny policy — the thing every cluster should have and almost none do — looks like this:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-ingress
  namespace: prod
spec:
  podSelector: {}
  policyTypes:
    - Ingress

Apply that and every pod in prod rejects all incoming traffic until you write explicit allow rules. It’s the single highest-value security control most home clusters are missing, and Calico enforces it cleanly.

3 Cilium: eBPF and the programmable kernel

Cilium is the ambitious one. It’s built on eBPF, a technology that lets you run sandboxed programmes inside the Linux kernel without modules or patches. Instead of pushing traffic through long iptables chains, Cilium loads eBPF programmes that make forwarding and policy decisions in the kernel datapath directly. At scale that’s meaningfully faster, because iptables performance degrades as rules pile up and eBPF does not.

But Cilium is more than a faster dataplane. It does identity-based policy — rules keyed on pod identity rather than fragile IPs — and reaches up into layer 7, so you can write policies like “this pod may make GET requests to that API but not POST.” It ships Hubble, a genuinely lovely observability layer that shows live service-to-service traffic flows, which is the kind of thing you didn’t know you wanted until you’ve watched your cluster’s traffic light up in real time. It can even replace kube-proxy entirely.

The catch is complexity. eBPF requires a reasonably modern kernel, and when something does go wrong you’re debugging eBPF maps rather than iptables rules you can read. The power is real; so is the learning curve.

4 So which one for a home cluster?

Here’s my honest take after running both on hardware in my own house.

• If you want the path of least resistance, pick Calico. It’s stable, well-documented, debuggable with standard Linux tools, and it does everything a home cluster realistically needs. Most homelabs never push enough traffic for the eBPF performance gap to matter.
• If you’re here partly to learn, Cilium is a fantastic thing to learn on, and Hubble alone makes your cluster’s networking visible in a way nothing else does. The observability is the real prize at home scale, more than the raw performance.
• For policy, both enforce standard NetworkPolicy well. Cilium’s layer-7 and identity-based rules go further, but most people start and stop at “default-deny plus a few allows,” which either handles fine.
• For footprint, Calico is the lighter, simpler thing to keep running. Cilium asks a bit more of your kernel and your patience.

5 The verdict

There’s no wrong answer here, which is the most reassuring thing I can tell you. If you want a CNI you install once and forget, that fades into the background and never surprises you, Calico is the safe and entirely respectable pick — it’s what I reach for when I just want the cluster to work. If you treat your homelab as a place to learn the modern, eBPF-shaped future of Linux networking, and you’ll actually use Hubble and the layer-7 policies, Cilium rewards the investment and is genuinely a joy once it clicks. Pick based on whether you want your CNI to disappear or to teach you something. Both are good. Just please, whichever you choose, write that default-deny policy.