Cilium v1.20.1 combines networking, policy, and visibility
Cilium v1.20.1 is much more than a component that assigns pod addresses. Its eBPF datapath connects workloads, applies identity-aware policy, translates Kubernetes Services, and records flow decisions near the Linux kernel. Hubble turns those records into service maps, DNS and protocol views, drop reasons, metrics, and searchable events. For a platform team, that can reduce the handoffs between the CNI, firewall rules, service proxy, and packet-capture tools when a request disappears.
The README describes policy from Layer 3 through Layer 7, including labels, ports, DNS names, HTTP methods, URL paths, headers, and gRPC calls. Cilium can also replace kube-proxy, provide ingress and egress gateways, encrypt traffic with WireGuard or IPsec, and connect multiple clusters. That range is the main buying argument and the main warning. A team that uses only basic pod networking will own far more machinery than it needs.
Two routing modes force an early network decision
Cilium documents 2 broad routing models. Overlay mode carries pod traffic through VXLAN or Geneve and mainly asks the underlying network for host-to-host IP connectivity. Native routing uses ordinary host routes, so the surrounding network must know how to reach pod addresses. Neither choice is cosmetic. It affects packet paths, MTU planning, troubleshooting, and how much the physical or cloud network must understand.
Service handling adds another decision. Cilium can keep kube-proxy or replace it with eBPF load balancing, including socket-level translation, Direct Server Return, and Maglev hashing. Replacing kube-proxy removes one moving part, while making Cilium responsible for more of the service path. Test ClusterIP, NodePort, external traffic, host networking, and storage flows before migration. The v1.20.1 release fixed several datapath and Gateway API faults, which is a reminder to test the exact feature set you enable.
What happened when we ran it
Our run installed the checked-out code in 111 seconds, with 0 packages installed by that step. The build then succeeded in 438 seconds. We cloned commit 6fd7b3f into an unprivileged Debian container with 3 CPUs and 8 GB of RAM. The checkout held 8,199 files, about 1,015,249 lines of source, and occupied 76.9 MB, so even a clean source build is a substantial job.
Tests ended with exit code 1 after 625 seconds. Go reported 209 passing packages and 1 failing package out of 210. The supplied log tail shows metricslint and statedblint passing, followed by several tool packages with no test files, and then the final FAIL. It does not name the failed package or expose an error message. We therefore cannot attribute the failure to permissions, missing services, a flaky test, or Cilium itself from this evidence.
Linux 5.10 is the baseline, and production needs host privileges
Cilium's requirements recommend Linux kernel 5.10 or later, with named distribution equivalents such as RHEL 8.10's 4.18 kernel. Published images support AMD64 and AArch64. The agent loads eBPF programs, uses the host networking namespace, and normally runs through a privileged Kubernetes DaemonSet. An unprivileged container like our sandbox can inspect and compile the repository, but it cannot reproduce the real datapath or prove cluster connectivity.
The quick install assumes an existing Kubernetes cluster and a working kubectl context. The Cilium CLI can choose defaults for a supported distribution, while Helm exposes the settings platform teams will eventually need to own. Routing, IP allocation, firewall openings, encryption, Hubble, BGP, Gateway API, and Cluster Mesh all change the runtime shape. Add them in controlled stages. A failed packet is much easier to locate when only 1 layer changed.
Three maintained minor lines make upgrades an ongoing job
The README says the community maintains the latest 3 minor release lines and treats older minors as end of life. The upgrade guide calls for version-specific steps, preflight checks, and the appropriate compatibility value during minor upgrades. It also warns against Helm's --reuse-values option because old values can render a new chart incorrectly. For a component that carries every pod's traffic, that maintenance policy belongs in the adoption decision.
Release v1.20.1 shipped on August 18, 2026. Its fixes include a silent CIDR policy bypass and traffic drops after an agent restart, a NetworkPolicy update delayed by as much as 2 minutes, an operator shutdown deadlock, and several Gateway API errors. Quick backports are evidence of an active release process. The seriousness of those bugs also means operators need a prompt patch-review habit rather than treating the network layer as set-and-forget infrastructure.
25,012 stars come with active issue and pull request work
GitHub showed 25,012 stars and a push on August 26, 2026. The repository had 811 open issues and 306 open pull requests when fetched, and both issue and pull request activity continued that day. Those counts describe a large project with a large support surface, not 1,117 known bugs. Current commits, active discussions, and an August stable release together make a stronger health signal than the release tag alone.
Cilium deserves a serious trial when Hubble's flow evidence, identity-based policy, or kube-proxy replacement will remove known operational pain. Our 438-second build passed, while the 625-second test run left 1 of 210 packages failing without a visible cause. That result is good enough to continue evaluation and too incomplete to waive cluster testing. Smaller clusters with no advanced policy or visibility needs should start with Flannel or kube-router and add complexity only when a measured problem demands it.