Some of our clients, DevOps, and the SRE team wanted to explore Cilium to manage their network, so we explored the Cilium project. Cilium is widely popular among contributors- it has 2nd highest Git commits after Kubernetes. ( Refer to Cilium- the 2nd most active project in CNCF). A lot of companies such as Google, Bell, AWS, and Datadog use Cilium to improve cloud network experience. In this blog, we will explore more about Cilium, how it works, and why it makes sense to consider simplifying the network.
Introduction to Cilium
Cilium is an open-source, cloud-native solution for providing, securing, and observing network connectivity between workloads. Cilium uses the revolutionary Kernel technology eBPF (extended Berkeley Packet Filter).
(Optional Read: eBPF is a new technology that extends the Linux OS kernel without requiring a change in the source kernel code. This means that eBPF can allow programs to enhance the operating system’s capabilities and run much faster and more efficiently than in the user space. The speed and efficiency gain happen because of the OS’s robust and fast compiler and verification engine.)
How does Cilium work?
Because eBPF runs inside the Linux kernel, you can leverage Cilium to define and apply security policies without making any changes container configuration or application logic. Cilium leverages eBPF to implement features such as:
- Packet Filtering: eBPF programs can filter packets at various points in the network stack, enforcing security policies and ensuring that only authorized traffic is allowed.
- Traffic Redirection: Cilium can redirect traffic to different destinations based on load balancing decisions, service discovery, or other criteria.
- Performance Monitoring: eBPF allows Cilium to gather detailed performance metrics with minimal overhead, providing insights into network behavior and performance.
Offerings of Cilium project
Cilium offers many products which can be beneficial for various requirements in the cloud requirements. Important products are:
- Cilium CNI
- Cilium Service mesh
- Cilium Gateway API
While writing this document, Cilium CNI is the most matured product in their line and is adopted by many companies. Cilium service mesh (sidecar-less and based on Cilium CNI) is getting some traction because it fast. Since it is new and development of sophisticated networking features are in progress it will take some time for wide-spread adoption like Istio service mesh.
We will discuss about the Cilium CNI features in the next section.
Core Features of Cilium CNI
- High Performant Network Connectivity
Cilium excels in providing network connectivity for containerized applications. Traditional networking solutions Kube CNI or Calico CNI often struggle with the dynamic nature of microservices (say 1000s of replicas are getting scaled and deleted in secs), but Cilium addresses these challenges head-on. Since Cilium uses eBPF under the hood instead of iptables, the load balancing mechanisms at L3/L4 layer is fast and efficient.
- Highly Scalable
Unlike many cloud CNIs, Cilium CNI is built to scale in a large scale clusters with multiple nodes and thousand of services. It has an optimized eBPF-powered networking to handle your network operation at scale without compromising latency.
- Robust Security Policies
In Cloud and DevOps, security is a paramount concern. Cilium introduces a paradigm shift by moving beyond traditional IP-based security measures to identity-based policies. Cilium uses the concept of identities assigned to workloads, allowing policies to be defined in terms of these identities rather than IP addresses.
- Comprehensive Observability
Cilium CNI offers the ability to gain cluster-wide network performance for DevOps and SRE teams. Cilium offers another project called Hubble, an open source observabilty product built on top of Cilium and eBPF to gather deep visibility into the communication and behavior of services as well as the networking infrastructure. With Hubble, you get data such as dependency maps, operational monitoring and alerting, event monitoring with metadata, and application and security visibility based on flow logs
Architecture of Cilium
There are 4 main components of Cilium- Cilium Agent, Cilium CLI, Operator, and Plugin (Cilium Monitor is Hubble, we did not consider this for this blog).
- Cilium Agent: The Agent is responsible for accepting network, load balancing, and observability configurations from the Kubernetes API server. The Agent is responsible for listening to take actions based on events such as pod start or stop. It controls the eBPF programs which are responsible for managing network access in/out of containers (refer to the below image). Cilium Agent is installed per node in a cluster.
- Cilium CLI: It is a command line tool to interact with the Cilium Agent through REST APIs. One can read and access the eBPF program directly from the Cilium CLI tool.
- Operator: The Cilium Operator is responsible for CRD registrations, IP Address management, KVStore operations (like syncing K8s node info or services to external KVStore), garbage collection, parsing Ingress and Gateway API objects and translating to Cilium objects, and mutual authentication support.
- CNI Plugin: The Cilium CNI plugin is used when a pod is scheduled or terminated in a cluster node. It is responsible for initiating datapath configuration to provide networking, load-balancing and network policies for the pod.
Sources: Cilium.io (modified)
Conclusion
Cilium represents a significant advancement in how we manage networking, security, and observability in cloud-native environments. By leveraging the power of eBPF, Cilium offers a highly efficient and flexible solution that meets the needs of modern applications. DevOps and SREs team looking to enhance the security of your microservices, optimize network performance, or gain deeper insights into your network traffic, Cilium is a tool worth exploring.
In the next blog, we will discuss whether to consider Cilium while using Istio service mesh. We shall explore the performance of the duo by conducting a load test.