Learn Cilium - History, Background & Why You Need Cilium

#Introduction

Welcome back to the Learn Cilium series! In episode 0 you prepared a test cluster, the Cilium CLI, the hubble CLI, and Helm. Now we step back for a moment to understand where Cilium comes from and what problems it actually solves. Without this context, every command we are about to learn feels like a black box.

Episode 1 covers three big things: Cilium's evolution from Isovalent's internal project in 2017 to a CNCF graduated project, the eBPF technology foundation that makes it all possible, and an early comparison with other approaches such as Flannel, Calico, and kube-proxy. Why does this matter? Because the decision to use Cilium in production usually grows out of understanding the limitations of the old approaches.

#The Birth of Cilium: From Isovalent to CNCF

#Isovalent's Internal Project (2017)

Cilium was born around 2017 as an internal project at Isovalent, a company co-founded among others by Thomas Graf — a Linux kernel engineer who had previously contributed to many networking projects. Initially, Cilium was designed to answer one simple question: how to provide scalable networking and security for containers by leveraging eBPF, a technology that was just starting to become widely available in the Linux kernel.

This approach differed from the CNIs that existed before. Instead of building all the rules in user-space with iptables, Cilium loads small programs into the kernel that execute network logic directly in the data path. As a result, routing, load balancing, and policy decisions are made in the kernel without round-tripping to user-space.

#CNCF and Graduated Status

Cilium was donated to the CNCF in 2021 and eventually achieved graduated status. This status means the project has matured in terms of governance, adoption, and security — not just an experimental project. As of mid-2026, Cilium is at version 1.20.x, with the latest stable release 1.20.0 in July 2026, while versions 1.19.6 and 1.18.12 remain on the maintenance track.

To always know the latest version, use these two simple commands:

curl -s https://api.github.com/repos/cilium/cilium/releases/latest | grep tag_name
cilium version

curl -s https://api.github.com/repos/cilium/cilium/releases/latest fetches the latest release information directly from the GitHub API, while cilium version shows the CLI version and the version of the image that will be used in your cluster.

It is also important to understand the ecosystem around the project: Cilium is not a single-vendor project. Although it started at Isovalent, it is now developed by a broad community across many companies, including contributions from major cloud providers. This diversity of contributors is one of the reasons the project is trusted for production — no single party can unilaterally stop development.

#eBPF: The Technology Foundation

eBPF (extended Berkeley Packet Filter) is a Linux kernel mechanism that lets you run code inside the kernel safely and in isolation — without writing a kernel module. eBPF programs are verified, compiled into bytecode, and then attached to specific hooks, for example when a packet arrives, when a syscall is invoked, or when a new process starts. Verification ensures the program terminates within a bounded time and does not access memory arbitrarily.

The advantage of eBPF over iptables is fundamental: iptables works by checking rules one by one sequentially, while eBPF performs a hash table lookup directly in the kernel with constant complexity. Imagine the difference between reading a list of thousands of rules from top to bottom versus guessing the answer in a single step.

To check whether your kernel supports eBPF with full features, run:

uname -r
ls /sys/kernel/btf

ls /sys/kernel/btf verifies the presence of the BTF (BPF Type Format) file that Cilium needs to load eBPF programs with CO-RE (compile once, run everywhere). If that file does not exist, modern Cilium features will be limited.

#Problems Solved by Cilium

#Limitations of kube-proxy

kube-proxy works by arranging iptables rules on every node. The more Services there are, the longer the iptables chains get — a packet has to traverse thousands of rules before finding a match. This leads to two main problems: latency that grows with scale, and update complexity when Services change. Cilium replaces this mechanism with eBPF programs that do a direct lookup in the kernel, without long rule traversal.

Another problem that often goes unnoticed: security. Because iptables is filled with many rules from various sources, it is hard to ensure no conflicting or deviating rules exist. With eBPF, the data path is easier to audit because all rules are centralized in one place managed by Cilium — an advantage that is not visible in benchmarks but is strongly felt during a security incident.

#NetworkPolicy That Does Not Understand Identity

Kubernetes' built-in NetworkPolicy runs on top of iptables and only works at the IP and port level. The consequences are heavy: as soon as a pod restarts, its IP changes, and all IP-based rules become inaccurate. Cilium introduces identity — a numeric value derived from pod labels. Policies are written against identity rather than IP, so policies remain valid even when IPs change. Full details will be covered in episodes 5 and 6.

#One Platform: Networking, Security, and Observability

Before Cilium, teams usually combined several tools: one CNI for networking, a separate solution for NetworkPolicy, and yet another observability tool to monitor traffic. Cilium unifies all three in a single eBPF data plane. Hubble (episode 7) reads flow logs from the same data plane, so you can see why a packet was accepted or dropped without installing extra tooling.

#Performance and Scale

The performance difference between iptables and eBPF is not just theory. Community benchmarks show that for clusters with hundreds of Services, iptables-based kube-proxy starts to show measurable latency increases, while Cilium's eBPF data plane maintains nearly constant latency. The main reason is simple: iptables reads rules sequentially, whereas eBPF performs the lookup in a single step.

There is also an effect on the control plane that is rarely noticed. Every time a Service changes, kube-proxy has to update all affected chains — an operation that can take seconds in large clusters. In Cilium, a Service change only adds or modifies one entry in the kernel hash table, so the operation is nearly instantaneous.

Note that benchmark numbers always depend on workload and hardware. Do not draw conclusions from someone else's benchmarks; run cilium connectivity test and measure it yourself in your cluster to get numbers that are relevant to your own environment.

#Practice: Checking Environment Readiness

Before you enter episode 3 for installation, make sure your learning environment is ready. Cilium needs a reasonably modern kernel and BTF support to use eBPF features fully. Checking this early saves a lot of time later.

uname -r
grep -c CONFIG_BPF /boot/config-$(uname -r) 2>/dev/null || echo "config tidak tersedia"
ls /sys/kernel/btf
kubectl get nodes -o wide

uname -r shows your kernel version; make sure it is at least kernel 5.10 or newer to use modern Cilium features comfortably. ls /sys/kernel/btf checks for the presence of the BTF file we discussed in the eBPF section. kubectl get nodes -o wide displays the kernel version of every node at once — a quick way to ensure all nodes are consistent, since Cilium runs as a DaemonSet on every node.

If there is a node with a much older kernel, note that node's number. The features we use in the early episodes may still work, but features like the bandwidth manager (episode 11) or WireGuard encryption (episode 14) require newer kernels. Kernel consistency across nodes is an often-overlooked operational prerequisite.

cilium version

cilium version shows the CLI version and the version of the image that will be used. Note that the image version shown is the version that will be installed in the cluster — if it differs from what you want, specify the version explicitly at install time as we will do in episode 3.

#Cilium vs Other Approaches

As an initial overview, here is where Cilium sits among other commonly used CNIs:

• Flannel: simple, VXLAN overlay, no advanced NetworkPolicy.
• Calico: IP-based routing with BGP, iptables-based policy, strong for traditional networking.
• Weave: easy to use, overlay-focused, less popular at large scale.
• Cilium: eBPF in the data plane, identity-based policy, built-in observability, and kube-proxy replacement.

It is important to note that this comparison does not mean Cilium always wins in every situation. Calico and Flannel still have their place in simple clusters or in environments that do not support eBPF. An in-depth comparison, including Cilium vs Istio for service mesh, will be covered in episode 22.

The comparison above is taken from the perspective of feature capabilities and operational style. Migration cost also needs to be considered: switching a CNI means all pods must be restarted, so the CNI choice should be made carefully and not changed without strong reason.

The most important thing to understand: choosing a CNI is a long-term architectural decision. Once workloads are running, migrating a CNI requires downtime and serious planning. Therefore, understanding the differences between CNIs early on — as we are doing in this series — is a very valuable investment.

#Closing

Key takeaways:

• Cilium was born at Isovalent in 2017 and is now a graduated CNCF project at version 1.20.x.
• eBPF makes it possible to run code inside the kernel safely without modules.
• iptables-based kube-proxy does not scale in large clusters because of long rule traversal.
• Classic IP-based NetworkPolicy is fragile because pod IPs change; Cilium uses identity.
• Cilium unifies networking, security, and observability in one data plane.
• Cilium's position vs Flannel, Calico, Weave, and Istio is discussed in depth in episode 22.

In the next episode 2, we will dissect Cilium's core concepts and main architecture — the Cilium Agent on every node that compiles and loads eBPF programs, the Cilium Operator that manages cluster-wide state, the eBPF data plane for L3/L4/L7, as well as components such as CiliumNetworkPolicy, ClusterwideNetworkPolicy, Hubble, and IPAM. This is the architectural foundation we will use in all subsequent episodes.