Cilium 1.20: 80% Smaller Binary, Same-Node Encryption, Upgrade Now

Cilium 1.20.1 landed on August 18. If your cluster is still on 1.19, there are three things in this release worth your time: the cilium-cni binary shrank 80 percent, WireGuard encryption now covers same-node pod traffic (the gap zero-trust teams have been complaining about since 1.15), and a new cluster-mesh policy entity finally makes cross-cluster security policies writable by humans. Two months in, Kubernetes operators are calling 1.20 an “operational maturity” release — not flashy, but the kind that changes what you can promise in your SLA.

The Binary That Shrank 80 Percent

The most immediate change is the cilium-cni binary. It was 77 MB. It is now 16 MB. The same pull request also shrunk cilium-agent and cilium-dbg.

That sounds like a footnote. At scale, it is not. At 500 nodes, the old binary required roughly 38 GB of storage for the CNI alone. At 16 MB it is 8 GB. More importantly, every time a node bootstraps — auto-scaling event, spot instance replacement, AZ failover — it pulls that binary before the node becomes schedulable. Smaller binary means faster bootstrap means shorter recovery window. This is the kind of change that shaves minutes off your next incident.

There is a security argument too. A smaller binary has fewer embedded dependencies and a narrower attack surface. Cilium achieved this by stripping unnecessary build artifacts and trimming embedded libraries that had accumulated across releases. According to the official release notes, this single change touched cilium-cni, cilium-agent, and cilium-dbg in the same PR — a coordinated cleanup, not a one-off fix.

Same-Node WireGuard Encryption: The Gap Is Closed

Cilium has supported WireGuard-based pod encryption for several releases. What it did not do was encrypt traffic between pods on the same node. Traffic crossing node boundaries was encrypted. Traffic between two pods on the same host was not — because eBPF handled it directly in the kernel, bypassing the WireGuard tunnel.

That is a real gap in multi-tenant clusters. If you share nodes across teams or workloads that should not see each other’s traffic, same-node placement could expose data. Cilium 1.20 closes this. All enrolled pod-to-pod connections are now encrypted regardless of node placement.

Enabling it requires two Helm values:

encryption:
  enabled: true
  type: wireguard
  nodeEncryption: false  # set true for node-to-node traffic (still beta)

You need Linux 5.6 or later with CONFIG_WIREGUARD built in. On any modern distribution that is a given. The full node-to-node option (encrypting control-plane to worker traffic) is still in beta — as the Cilium WireGuard documentation notes, WireGuard key rotation can temporarily block worker nodes from reaching the API server, so test it thoroughly before enabling it in production.

Cluster-Mesh Policy: One Entity for the Whole Mesh

If you run Cilium Cluster Mesh — federating two or more Kubernetes clusters — you know the pain of cross-cluster network policies. Previously, expressing “allow traffic from any endpoint in the mesh” required enumerating clusters by the io.cilium.k8s.policy.cluster label. Add a cluster, update the policy. Remove one, update it again.

Cilium 1.20 adds a cluster-mesh policy entity that selects every endpoint across the entire mesh. Write the policy once. It covers whatever is in the mesh, current and future. For teams running multi-region active-active or cross-cluster disaster recovery setups, this is exactly the kind of operational simplification that makes policy audits survivable. The Cilium cluster mesh policy documentation has the CiliumNetworkPolicy examples.

Netkit Auto-Selection and One Hard Caveat

Cilium 1.20 introduces bpf.datapathMode=auto. Set it and Cilium probes the kernel for netkit support, using it if available and falling back to veth otherwise. Netkit is a more efficient virtual device type optimized for eBPF — on supported kernels, it reduces processing overhead with no further configuration.

One hard incompatibility: bpf.tproxy=true cannot run alongside netkit. If both are configured, Cilium refuses to start. If you use transparent proxying, hold off on auto mode until that conflict is resolved upstream.

Before You Upgrade: The Short Checklist

• Get to the latest 1.19 patch first — only consecutive minor version upgrades are supported
• If you use Gateway API, upgrade your CRDs to v1.6.1 before upgrading Cilium
• Audit CiliumNetworkPolicy resources with empty spec fields — 1.20 rejects them at admission
• Run cilium connectivity test after the upgrade before marking it done

The Cilium upgrade guide covers the full checklist, including notes on legacy mutual authentication, Envoy Go extensions, and Kafka-aware policies that are also deprecated in this release.

Upgrade Now or Wait?

Upgrade. Cilium 1.20.1 is stable, has 2,660+ commits from 1,100+ contributors, and the binary size reduction is worth it on its own at any cluster size above a few dozen nodes. The same-node encryption closes a genuine compliance gap that some security teams have been escalating since 1.15. The only reason to hold back is if you rely on tproxy mode and have not yet verified the netkit interaction — in that case, stay on 1.19.x until the incompatibility is resolved. Everyone else: read the checklist above, run the preflight, and ship it.