Cilium Series 1: Cilium Features, Capabilities, and Use Cases

Series Articles

• Cilium Series Articles

Introduction to Cilium

Cilium is an open-source cloud-native solution for providing, securing, and observing network connectivity between workloads, powered by the revolutionary kernel technology eBPF. Cilium is primarily used in Kubernetes, but its advantages are not limited to Kubernetes environments.

In Kubernetes environments, Cilium serves as a network plugin that provides connectivity between pods. It delivers security by enforcing network policies and transparent encryption, while Cilium’s Hubble component provides deep visibility into network traffic flows.

Thanks to eBPF, Cilium’s networking, security, and observability logic can be programmed directly into the kernel, making the capabilities of Cilium and Hubble completely transparent to application workloads. These are typically containerized workloads in Kubernetes clusters, though Cilium can also connect traditional workloads such as virtual machines and standard Linux processes.

A typical example of Cilium’s observability: applications in pods don’t need to enable tracing or export HTTP request metrics to Prometheus via an exporter. Through Cilium’s Hubble alone, you can directly obtain RED metrics (Requests, Errors, Durations) for the application’s HTTP requests.

Cilium Use Cases - Addressing the Challenges of Container Networking at Scale

In the highly dynamic and complex world of microservices, thinking about networking primarily in terms of IP addresses and ports can lead to frustration. Implementing with traditional networking tools (via five-tuples) can be extremely inefficient, offering only coarse-grained visibility and filtering, which limits the ability to troubleshoot and secure container networks. These are the challenges Cilium aims to solve.

From the very beginning, Cilium was designed for large-scale, highly dynamic containerized environments. It natively understands container and Kubernetes identities and can parse API protocols such as HTTP, gRPC, and Kafka, providing simpler and more powerful visibility and security than traditional firewalls.

Therefore, Cilium’s key capabilities focus on three areas:

• High performance
• Security
• Observability

Cilium - Built on eBPF

eBPF enables Cilium’s powerful security, visibility, and control logic to be dynamically inserted into the Linux kernel. eBPF makes the Linux kernel programmable, allowing applications like Cilium to hook into Linux kernel subsystems and bring user-space application context into kernel operations.

│ 📝Notes:
│
│ Because of this, using the full set of Cilium features requires a very recent Linux kernel version. The currently recommended Linux Kernel is ≥ 5.10.

Since eBPF runs within the Linux kernel, Cilium security policies can be applied and updated without changing application code or container configuration. eBPF programs hook into the Linux network data path and can take actions such as dropping packets based on network policy rules when packets enter a network socket.

eBPF enables visibility and control over systems and applications with unprecedented granularity and efficiency. It achieves this in a completely transparent manner without requiring any changes to the application. Cilium leverages the power of eBPF to layer an efficient identity concept on top, bringing Kubernetes context information (such as metadata labels) into eBPF-driven networking logic.

Now let’s talk about what Cilium can do.

Cilium Features

Networking

Cilium provides network connectivity that allows pods and other components (inside or outside Kubernetes clusters) to communicate. Cilium implements a simple flat Layer 3 network capable of connecting all application containers across multiple clusters (ClusterMesh).

By default, Cilium supports an overlay networking model, where a virtual network spans all hosts. Traffic in the overlay network is encapsulated for transmission between different hosts. This mode is chosen as the default because it has the lowest requirements for infrastructure and integration, requiring only IP connectivity between hosts.

Cilium also offers a native routing networking mode option, which uses the regular routing table on each host to route traffic to pod (or external) IP addresses. This mode is intended for advanced users and requires some understanding of the underlying network infrastructure. It works well with native IPv6 networks, cloud network routers, or pre-existing routing daemons.

Identity-Aware Network Policy Enforcement

Network policies define which workloads are allowed to communicate with each other, securing deployments by preventing unintended traffic. Cilium can enforce both native Kubernetes NetworkPolicies and the enhanced CiliumNetworkPolicy resource (CRD) types.

Traditional firewalls protect workloads by filtering on IP addresses and destination ports. In Kubernetes environments, every time a pod starts in the cluster, the firewalls (or iptables rules) on all node hosts need to be manipulated to rebuild the firewall rules corresponding to the desired network policy enforcement. This does not scale well.

To avoid this, Cilium assigns an identity to groups of application containers based on relevant metadata such as Kubernetes labels. This identity is then associated with all network packets emitted by the application containers, enabling eBPF programs to efficiently validate the identity at the receiving node without using any Linux firewall rules. For example, when scaling a deployment and creating new pods in the cluster, the new pods share the same identity as existing pods. The eBPF program rules corresponding to network policy enforcement don’t need to be updated again because they already know the pod’s identity!

Traditional firewalls operate at Layer 3 and Layer 4, but Cilium can also secure modern Layer 7 application protocols such as REST/HTTP, gRPC, and Kafka (in addition to Layer 3 and Layer 4 enforcement). It can enforce network policies based on application protocol request conditions, for example:

• Allow all HTTP requests with method GET and path /public/.*. Deny all other requests.
• Require all REST calls to include the HTTP header X-Token:[0-9]+.

Transparent Encryption

Encrypting data between services is now a requirement of many regulatory frameworks such as PCI or HIPAA. Cilium supports transparent encryption with simple configuration using IPSec or WireGuard, securing traffic between nodes without requiring any workload reconfiguration once enabled.

Multi-Cluster Networking

Cilium’s Cluster Mesh feature allows workloads to easily communicate with services hosted in different Kubernetes clusters. You can run services in clusters across different regions and connect them using Cilium Cluster Mesh to achieve high availability for your services.

Load Balancing

Cilium implements distributed load balancing for traffic between application containers and external services. In fact, Cilium can fully replace kube-proxy and can also be used as a standalone load balancer. eBPF uses efficient hash tables to implement load balancing that can scale almost infinitely.

Enhanced Network Observability

While we have a soft spot for tools like tcpdump and ping — they’ll always hold a special place in our hearts — they are not up to the task of troubleshooting network issues in dynamic Kubernetes cluster environments. Cilium is committed to providing observability tools that let you quickly identify and fix cluster networking problems.

To this end, Cilium introduced a dedicated network observability component called Hubble. Hubble leverages Cilium’s identity concept to easily filter traffic in an actionable way and provides the following capabilities:

• Network traffic visibility at Layer 3/4 (IP addresses and ports) and Layer 7 (API protocols)
• Event monitoring with metadata: when a packet is dropped, the tool reports not just the source and destination IPs, but also the full label information of the sender and receiver along with a wealth of other information
• Configurable Prometheus metrics export
• A graphical user interface for visualizing cluster network traffic

Here’s what it looks like in practice:

Prometheus Metrics

As mentioned earlier, Cilium and Hubble export metrics on network performance and latency via Prometheus, so you can integrate Cilium metrics into your existing Grafana dashboards.

│ 📝Notes:
│
│ In recent news, the collaboration between Cilium and Grafana has yielded initial results — the Grafana Hubble data source.
│ For details, read this article: Monitor Kubernetes network and security events with Hubble and Grafana

Service Mesh

As described above, Cilium supports inter-service load balancing, application-layer visibility, and various security-related features — all of which are capabilities of a Kubernetes service mesh. Cilium also supports Kubernetes Ingress and Gateway API, providing a full suite of service mesh functionality without the overhead of injecting a sidecar into every pod.

Summary

Cilium is an open-source cloud-native solution for providing, securing, and observing network connectivity between workloads, powered by the revolutionary kernel technology eBPF. Cilium is primarily used in Kubernetes.

Cilium’s key highlights are:

• High performance
• Security
• Observability

Beyond serving as a Kubernetes CNI, Cilium offers many other capabilities, including but not limited to:

• Multi-cluster networking
• Load balancing (fully replacing kube-proxy)
• Service Mesh

Let’s keep moving forward! 💪

📚️References

• Introduction to Cilium & Hubble — Cilium 1.13.4 documentation