CNCF Graduates Cilium Networking Software Project
The Cloud Native Computing Foundation (CNCF) today revealed that the open source Cilium networking software project has officially graduated alongside projects such as Kubernetes, Prometheus and others.
Designed to run in the microkernel of an operating system that supports extended Berkeley Packet Filtering (eBPF), Cilium was originally developed by Isovalent. There are now more than 800 contributors to the project, and organizations that have adopted it include Bell Canada, Bloomberg, DB Schenker, S&P Global, Sky and The New York Times.
Bill Mulligan, a maintainer for Cilium employed by Isovalent, said as the first container networking interface (CNI) technology to officially graduate, Cilium is now poised for increased adoption as organizations look to employ a single network across multiple IT environments.
In addition to providing connectivity at Layer 3 to Layer 4 of the networking stack, Cilium also provides capabilities to enforce policies, integrate multiple Kubernetes clusters across a single mesh, eliminate the need for kube-proxy, encrypt traffic, manage bandwidth and unify the management of ingress and egress via gateway.
A sub-project, dubbed Hubble, also provides network observability, metrics, a service map and a user interface, while the Tetragon sub-project focuses on security observability and runtime enforcement.
In the future, the project will grow beyond Kubernetes environments to include support for external workloads running on, for example, bare metal and virtual machines. Collectively, those capabilities ultimately should make it simpler for IT teams to programmatically converge network and security operations within the context of a DevOps workflow, noted Mulligan.
Adoption of Cilium is, of course, tied to the rate at which organizations are adopting instances of Linux that support eBPF. In effect, eBPF changes the way operating systems are designed. It bridges the boundary between kernel and user space by enabling developers to combine and apply logic across multiple subsystems that were historically completely independent. That approach enables, for example, networking or security software to scale at much higher levels of throughput.
It’s not clear to what degree eBPF might one day drive convergence across distinct categories once multiple tools and applications run at the microkernel level, but IT organizations would be well-advised to ask their vendors when they plan to support eBPF as they plan their upgrade cycles. It’s not likely IT teams are going to want to upgrade every tool and application that can benefit from eBPF all at once, but the performance that can be achieved by software running at the eBPF level will quickly make legacy tools running at the user space level seem antiquated.
It remains to be seen how IT organizations themselves might be realigned as software running at the eBPF level become more commonplace, but there will no doubt be much higher levels of collaboration as the walls that today separate distinct classes of tools become more porous, noted Mulligan.
In the meantime, major upgrades to everything from networking and security to storage and observability platforms are now in the offing. The only issue that remains to be seen is the pace at which the transition to eBPF is going to inevitably occur.
