Hubbry Logo
search
logo
Cilium (computing) avatar
Cilium (computing)
Cilium (computing)
current hub
2423183

Cilium (computing)

logo
Community Hub0 Subscribers
Read side by side
Cilium (computing)
View on Wikipedia
from Wikipedia
Cilium
Original authorsThomas Graf,
Daniel Borkmann,
André Martins,
Madhusudan Challa[1]
DevelopersOpen source community, Isovalent, Google, Datadog, Red Hat,
Cloud Native Computing Foundation[2]
Initial releaseDecember 16, 2015; 9 years ago (2015-12-16)[1]
Stable release
1.18 / 29 July 2025 (2025-07-29)[3]
Repositorygithub.com/cilium
Written inGo, eBPF, C, C++
Operating systemLinux, Windows[4]
Platformx86-64, ARM[5]
Available inEnglish
TypeCloud-native Networking, Security, Observability
LicenseApache License 2.0,
Dual GPL-2.0-only or BSD-2-clause for eBPF[6]
Websitecilium.io

Cilium is a cloud native technology for networking, observability, and security.[1] It is based on the kernel technology eBPF, originally for better networking performance, and now leverages many additional features for different use cases. The core networking component has evolved from only providing a flat Layer 3 network for containers to including advanced networking features, like BGP and Service mesh, within a Kubernetes cluster, across multiple clusters, and connecting with the world outside Kubernetes.[1] Hubble was created as the network observability component and Tetragon was later added for security observability and runtime enforcement.[1] Cilium runs on Linux and is one of the first eBPF applications being ported to Microsoft Windows through the eBPF on Windows project.[7]

History

[edit]

Evolution from Networking CNI (Container Network Interface)

Cilium began as a networking CNI[8] for container workloads. It was originally IPv6 only and supported multiple container orchestrators, like Kubernetes. The original vision for Cilium was to build an intent and identity-based high-performance container networking platform.[9] As the cloud native ecosystem expanded, Cilium added new projects and features to address new problems in the space.

The table below summarises some of the most significant milestones of this evolution:

  • December 2015 - Initial commit to the Cilium project[10]
  • May 2016 - Network policy was added, expanding the scope beyond just networking[11]
  • August 2016 - Cilium was initially announced during LinuxCon as a project providing fast IPv6 container networking with eBPF and XDP.[9] Today, Cilium has been adopted by major cloud provider's Kubernetes offerings and is one of the most widely used CNIs.
  • August 2017 - ebpf-go was created as a library to read, modify, and load eBPF programs and attach them to various hooks.[12]
  • April 2018 - Cilium 1.0 is the first stable release[13]
  • November 2019 - Hubble was launched to provide eBPF-based observability to network flows[14]
  • August 2020 - Chosen by Google as the basis for their Kubernetes Dataplane v2[15]
  • September 2021 - AWS picks Cilium for Networking & Security on EKS Anywhere[16]
  • October 2021 - Pwru was launched for tracing network packets in the Linux kernel with advanced filtering capabilities[17][18]
  • October 2021 - Accepted into CNCF as an incubation level project[19]
  • December 2021 - Cilium Service Mesh launched to help manage traffic between services[20]
  • May 2022 - Tetragon open sourced to cover security observability and runtime enforcement[21][22]
  • October 2022 - Chosen as CNI for Azure[23][24]
  • April 2023 - Cilium Mesh launched to connect workloads and machines across cloud, on-prem, and edge[25][26][27]
  • April 2023 - First CiliumCon hosted as a part of KubeCon[28]
  • October 2023 - Cilium becomes a CNCF Graduated project [29]

CNCF

[edit]

Cilium was accepted into the Cloud Native Computing Foundation on October 13, 2021 as an incubation-level project. It applied to become a graduated project on October 27, 2022.[19] It became a Graduated project one year later. Cilium is one of the fastest-moving projects in the CNCF ecosystem.[30]

Adoption

[edit]

Cilium has been adopted by many large-scale production users, including over 100 that have stated it publicly,[31] for example:

  • Datadog uses Cilium as their CNI and kube-proxy replacement[32][33]
  • Ascend uses Cilium as their one CNI across multiple cloud providers[34]
  • Bell Canada uses Cilium and eBPF for telco networking[35][36]
  • Cosmonic uses Cilium for their Nomad-based PaaS[37][38][39]
  • IKEA uses Cilium for their self-hosted bare-metal private cloud[40]
  • S&P Global uses Cilium as its CNI[41]
  • Sky uses Cilium as their CNI and for network security[42]
  • The New York Times uses Cilium on EKS for multi-region multi-tenant shared clusters[43]
  • Trip.com uses Cilium both on premise and in AWS[44]
  • OpenAI uses Cilium as their CNI[45]
  • TikTok uses Cilium as their CNI in their IPv6-only datacenters[46]

Cilium is the CNI for many cloud providers including Alibaba,[47] APPUiO,[48] Azure,[49] AWS,[16] DigitalOcean,[50] Exoscale,[51] Google Cloud,[15] Hetzner,[52] and Tencent Cloud.[53]

Projects overview

[edit]

Cilium

[edit]

Cilium began as a container networking project. With the growth of Kubernetes and container orchestration, Cilium became a CNI,[8] providing basic things like configuring container network interfaces and Pod to Pod connectivity. From the beginning, Cilium based its networking on eBPF rather than iptables or IPVS, betting that eBPF would become the future of cloud native networking.[54]

Cilium’s eBPF based dataplane provides a simple flat Layer 3 network with the ability to span multiple clusters in either a native routing or overlay mode with Cilium Cluster Mesh. It is Layer 7-protocol aware and can enforce network policies on Layer 3 to Layer 7 and with FQDN using an identity-based security model that is decoupled from network addressing.

Cilium implements distributed load balancing for traffic between Pods and to external services, and is able to fully replace kube-proxy,[55] using XDP, socket-based load-balancing and efficient hash tables in eBPF. It also supports advanced functionality like integrated ingress and egress gateways,[56] bandwidth management, a stand-alone load balancer, and service mesh.[57]

Cilium is the first CNI to support advanced kernel features such as BBR TCP congestion control[58] and BIG TCP[59] for Kubernetes Pods.[60]

Hubble

[edit]

Hubble is the observability, service map, and UI of Cilium which is shipped with the CNI.[61][62] It can be used to observe individual network packet flows, view network policy decisions to allow or block traffic, and build up service maps showing how Kubernetes services are communicating.[63] Hubble can export this data to Prometheus, OpenTelemetry, Grafana, and Fluentd for further analysis of Layer 3/4 and Layer 7 metrics.[64]

Tetragon

[edit]

Tetragon is the security observability and runtime enforcement project of Cilium.[65] Tetragon is a flexible Kubernetes-aware security observability and runtime enforcement tool that applies policy and filtering directly with eBPF. It allows users to monitor and observe the complete lifecycle of every process execution on their machine, translate policies for file monitoring, network observability, container security, and more into eBPF programs, and do synchronous monitoring, filtering, and enforcement completely in the kernel.

Go eBPF Library

[edit]

ebpf-go is a pure-Go library to interact with the eBPF subsystem in the Linux kernel.[66] It has minimal external dependencies, emphasises reliability and compatibility, and is widely deployed in production.

Pwru

[edit]

pwru ("Packet, where are you?") is an eBPF-based tool for tracing network packets in the Linux kernel with advanced filtering capabilities. It allows fine-grained introspection of kernel state to facilitate debugging network connectivity issues. Under the hood, pwru attaches eBPF debugging programs to all Linux kernel functions which are responsible for processing network packets.

This gives a user finer-grained view into a packet processing in the kernel than with tcpdump, Wireshark, or more traditional tools. Also, it can show packet metadata such as network namespace, processing timestamp, internal kernel packet representation fields, and more.

Use cases

[edit]

Networking

[edit]

Cilium began as a networking project and has many features that allow it to provide a consistent connectivity experience from Kubernetes workloads to virtual machines and physical servers running in the cloud, on-premises, or at the edge. Some of these include:

  • Container Network Interface (CNI)[67] - Provides networking for Kubernetes clusters
  • Layer 4 Load Balancer[68] - Based on Maglev[69][70] and XDP[71] for handling north/south traffic
  • Cluster Mesh[72] - Combines multiple Kubernetes clusters into one network
  • Bandwidth and Latency Optimization[73] - Fair Queueing, TCP Optimization, and Rate Limiting
  • kube-proxy replacement[74] - Replaces iptables with eBPF hash tables
  • BGP[75] - Integrates into existing networks and provides load balancing in bare metal clusters
  • Egress Gateway[76] - Provides a static IP for integration into external workloads
  • Service Mesh[77][78] - Includes ingress, TLS termination, canary rollouts, rate limiting, and circuit breaking
  • Gateway API[79] - Fully conformant implementation for managing ingress into Kubernetes clusters
  • SRv6[80] - Defines packet processing in the network as a program
  • BBR support for Pods[81] - Allows for better throughput and latency for Internet traffic
  • NAT 46/64 Gateway[82] - Allows IPv4 services to talk with IPv6 ones and vice versa
  • BIG TCP for IPv4/IPv6[83] - Enables better performance by reducing the number of packets traversing the stack
  • Cilium Mesh[84][85] - Connects workloads running outside Kubernetes to ones running inside it

Observability

[edit]

Being in the kernel, eBPF has complete visibility of everything that is happening on a machine. Cilium leverages this with the following features:

  • Service Map[86] - Provides a UI for network flows and policy
  • Network Flow Logs[87] - Provides Layer 3/4 and DNS visibility connected to identity
  • Network Protocol Visibility[88] - Including HTTP, gRPC, Kafka, UDP, and SCTP
  • Metrics & Tracing Export[89] - Sends data to Prometheus, OpenTelemetry, or other storage system

Security

[edit]

eBPF can stop events in the kernel for security. Cilium projects leverage this through the following features:

  • Transparent Encryption[90] - Utilizes either IPSec or WireGuard
  • Network Policy[91] - Includes Layer 3 to Layer 7 and DNS-aware policies
  • Runtime Enforcement[92] - Stops processes outside of policies with default policies
  • File Integrity Monitoring[93] - Tracks modification to the system

Release timeline

[edit]
Release timeline
Version Release date End of Life date Notes
Unsupported: 0.9 31 May 2017 10 September 2017 https://cilium.io/blog/2017/5/31/cilium-v09-released-hello-kubernetes/
Unsupported: 0.10 24 July 2017 30 November 2017 https://cilium.io/blog/2017/9/29/cilium-v010-v011-released-double-the-fun-two-updates-in-one/
Unsupported: 0.11 10 September 2017 24 April 2018 https://cilium.io/blog/2017/9/29/cilium-v010-v011-released-double-the-fun-two-updates-in-one/
Unsupported: 0.12 30 November 2017 26 June 2018 https://cilium.io/blog/2017/11/7/cilium-with-kafka/
Unsupported: 1.0 24 April 2018 23 October 2018 https://cilium.io/blog/2018/04/24/cilium-10/
Unsupported: 1.1.0 26 June 2018 12 February 2019 https://cilium.io/blog/2018/06/26/cilium-11/
Unsupported: 1.2.0 21 August 2018 29 April 2019 https://cilium.io/blog/2018/08/21/cilium-12/
Unsupported: 1.3.0 23 October 2018 20 August 2019 https://cilium.io/blog/2018/10/23/cilium-13-envoy-go/
Unsupported: 1.4.0 12 February 2019 19 February 2020 https://cilium.io/blog/2019/02/12/cilium-14/
Unsupported: 1.5.0 29 April 2019 22 June 2020 https://cilium.io/blog/2019/04/24/cilium-15/
Unsupported: 1.6.0 20 August 2019 10 November 2020 https://cilium.io/blog/2019/08/20/cilium-16/
Unsupported: 1.7.0 19 February 2020 20 May 2021 https://cilium.io/blog/2020/02/18/cilium-17/
Unsupported: 1.8.0 22 June 2020 9 December 2021 https://cilium.io/blog/2020/06/22/cilium-18/
Unsupported: 1.9.0 10 November 2020 19 July 2022 https://cilium.io/blog/2020/11/10/cilium-19/
Unsupported: 1.10 20 May 2021 18 April 2023 https://cilium.io/blog/2021/05/20/cilium-110/
Unsupported: 1.11 9 December 2021 25 July 2023 https://isovalent.com/blog/post/2021-12-release-111/
Unsupported: 1.12 19 July 2022 1 February 2024 https://isovalent.com/blog/post/cilium-release-112/
Unsupported: 1.13 15 February 2023 19 July 2024 https://isovalent.com/blog/post/cilium-release-113/
Unsupported: 1.14 25 July 2023 4 February 2025 https://isovalent.com/blog/post/cilium-release-114/
Unsupported: 1.15 1 February 2024 29 July 2025 https://isovalent.com/blog/post/cilium-1-15/
Supported: 1.16 25 July 2024 TBA https://isovalent.com/blog/post/cilium-1-16/
Supported: 1.17 4 February 2025 TBA https://github.com/cilium/cilium/releases/tag/v1.17.0
Latest version: 1.18 29 July 2025 TBA https://github.com/cilium/cilium/releases/tag/v1.18.0

Support windows

[edit]

The chart below visualises the period for which each Cilium community release is maintained:

Community

[edit]

Cilium's official website lists online forums, messaging platforms, and in-person meetups for the Cilium user and developer community.

Conferences

[edit]

Conferences dedicated to Cilium development in the past have included:

  • CiliumCon EU 2023,[28] held in conjunction with KubeCon + CloudNativeCon EU 2023[94]
  • CiliumCon NA 2023,[95] held in conjunction with KubeCon + CloudNativeCon NA 2023[96]
  • CiliumCon EU 2024,[97] held in conjunction with KubeCon + CloudNativeCon EU 2024[98]
  • CiliumCon NA 2024 [99] held in conjunction with KubeCon + CloudNativeCon NA 2024[100]

Annual report

[edit]

The Cilium community releases an annual report to cover how the community developed over the course of the year:

  • Cilium Annual Report 2022: Year of the CNI[101]
  • Cilium Annual Report 2023: Year of Graduation[102]

See also

[edit]

References

[edit]
[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

Cilium (computing)

View on Grokipedia
from Grokipedia
Cilium is an open-source, cloud-native networking, security, and observability platform designed to provide, secure, and observe connectivity between workloads, particularly in Kubernetes environments, leveraging the eBPF kernel technology for high-performance and programmable data paths.[1][2][3] Originally created in December 2015 by developers who later founded Isovalent, Cilium was open-sourced and has since become the de facto standard for cloud-native networking, powering over 60% of CNI deployments according to the 2025 CNCF State of Kubernetes Networking report, with deep integration into Kubernetes as a Container Network Interface (CNI). Key features of Cilium include identity-aware security policies enforced at the kernel level, comprehensive network observability through metrics and tracing, and efficient load balancing, distinguishing it from traditional CNIs by replacing slow kernel modules with eBPF programs for reduced latency and improved scalability.[1][4][5] It supports multi-cluster and hybrid cloud deployments, and is used by major cloud providers such as Google for Google Kubernetes Engine (GKE) and AWS for EKS Anywhere, enabling advanced use cases like service mesh capabilities without sidecar proxies.[1][6]

Overview

Introduction

Cilium is an open-source, cloud-native solution that provides networking, observability, and security for connectivity between workloads in environments such as Kubernetes clusters.[1] It leverages extended Berkeley Packet Filter (eBPF) technology to enable high-performance, programmable data paths directly in the Linux kernel, addressing the scalability and security challenges of modern containerized applications.[1] Unlike traditional networking approaches that rely on kernel modules or user-space proxies, Cilium uses eBPF to run sandboxed programs at kernel hooks without modifying kernel code or loading modules, allowing for efficient policy enforcement and visibility at the network layer.[1] Originally created by the founders of Isovalent in late 2015 to overcome limitations in conventional Linux networking for microservices and distributed systems, Cilium emerged as a response to the growing demands of cloud-native infrastructures where traditional tools struggled with performance and fine-grained control.[5] The project began in December 2015, with Isovalent founded in 2017 by its key creators to advance eBPF-based innovations.[7] It quickly gained traction for its ability to provide layer 3/4 networking with advanced features like identity-aware security policies and deep observability.[2] Cilium serves primarily as a Container Network Interface (CNI) plugin for Kubernetes, enabling seamless integration and management of pod networking.[1] It joined the Cloud Native Computing Foundation (CNCF) as an incubating project in October 2021 and achieved graduated status in October 2023, marking its maturity and widespread adoption in production environments.[2] This progression underscores Cilium's role as a foundational technology for secure and observable cloud-native networking.[8] Cilium has seen widespread adoption by major cloud providers and enterprises. Google Kubernetes Engine (GKE) uses Cilium as the basis for its Dataplane V2, Azure Kubernetes Service (AKS) is powered by Cilium via Azure CNI, and Amazon Elastic Kubernetes Service (EKS) provides official support for Cilium deployments. It is also embraced by numerous enterprises, establishing it as the de facto standard for Kubernetes networking in many contexts per recent reports such as the State of Kubernetes Networking 2025.

Key Features

Cilium provides a range of key features centered on networking, security, and observability, all powered by eBPF for high-performance operations in cloud-native environments like Kubernetes.[1][9] Networking Features: Cilium offers advanced load balancing capabilities, including socket-level load balancing (socketLB) that operates directly in the kernel to distribute traffic efficiently without user-space overhead.[10] It also supports service mesh functionalities through sidecar-less implementations. Key among these is the Proxy Load Balancing feature for Layer 7 (L7) traffic on Kubernetes Services, enabled via annotations such as service.cilium.io/lb-l7: "enabled", which redirects traffic to a shared per-node Envoy proxy for L7-aware load balancing, including support for protocols like gRPC. This provides a lightweight, partial replacement option for gRPC load balancing needs but does not include the full advanced traffic management capabilities of Istio, such as retries, circuit breaking, timeouts, or fault injection. These features enable secure service-to-service communication, facilitate multi-cluster connectivity for seamless networking across distributed Kubernetes environments, and provide PROXY protocol support for its Ingress Controller and Gateway API listeners to preserve original client IP addresses when traffic passes through proxies or load balancers.[1][11][12][13][14] Security Features: For security, Cilium enforces network policies using Kubernetes Custom Resource Definitions (CRDs), allowing fine-grained control based on pod identities rather than IP addresses.[15] It provides identity-based policy enforcement to ensure secure workload isolation and integrates encryption options, such as WireGuard, for transparent data protection in transit.[15][12] Observability Features: Cilium's observability is enhanced by Hubble, a user interface for visualizing network flows and debugging connectivity issues in real-time.[9] It also exports detailed metrics to tools like Prometheus, enabling comprehensive monitoring of network performance and security events.[1] Performance Metrics: Due to its eBPF foundation, Cilium achieves significant performance gains over traditional networking solutions in large-scale deployments.

History

Development Origins

Cilium was founded in 2015 by Thomas Graf and a team of engineers, including Daniel Borkmann, with the initial goal of addressing scalability challenges in container networking for cloud-native environments.[16][17] The project emerged from Graf's extensive background in kernel development, spanning over a decade at Red Hat and time at Cisco working on Open vSwitch and software-defined networking.[17] This effort predated the formal founding of Isovalent in 2017 by Graf and Dan Wendlandt, a company established specifically to support and commercialize Cilium.[16] The primary motivations for Cilium's creation stemmed from the limitations of legacy networking tools like iptables, which struggled with performance and manageability in high-scale containerized setups, particularly as Kubernetes adoption grew.[17] Developers recognized that iptables rulesets introduced significant overhead for pod-to-pod communication, prompting a shift toward more efficient alternatives.[17] This coincided with the maturation of eBPF in the Linux kernel following version 4.4, which provided a revolutionary framework for running sandboxed programs in kernel space to enable programmable, high-performance data paths without the drawbacks of traditional tools.[18] Early milestones included the project's public launch with its first lines of code committed openly in December 2015, eschewing a traditional closed development phase to gather immediate community feedback.[17] An initial prototype was demonstrated at DockerCon in 2017, showcasing Cilium's eBPF-based approach.[17][19][20] Key affiliations have shaped Cilium's trajectory, including its development under Isovalent, which was acquired by Cisco, with the acquisition announced in December 2023 and completed in April 2024, to bolster multicloud networking and security capabilities.[21]

Major Releases and Milestones

Cilium follows a semantic versioning scheme, ensuring backward compatibility for production environments through long-term support (LTS) releases and regular updates that introduce new features while maintaining stability.[22] The project reached its first stable milestone with the release of version 1.0 on April 24, 2018, which provided basic Container Network Interface (CNI) support for Kubernetes, including eBPF-based networking and initial policy enforcement capabilities.[22] In August 2019, Cilium 1.6 was released, introducing Kubernetes CRD-backed security identities for smaller clusters and enabling kvstore-free operations, enhancing scalability and simplifying deployments.[23] Shortly after, on November 19, 2019, Hubble was launched as an integrated observability tool, providing eBPF-based visibility into network flows for Kubernetes workloads.[24] A significant version update came with Cilium 1.14 on July 25, 2023, which integrated Tetragon for runtime security and observability, allowing eBPF-based tracing and enforcement at the process level.[25] Key milestones include Cilium's acceptance into the Cloud Native Computing Foundation (CNCF) as an incubating project on October 13, 2021, followed by its graduation to stable status on October 11, 2023, reflecting widespread community adoption and maturity.[2][8] Cilium has seen integrations with major cloud providers, such as official support in Amazon EKS for enhanced networking and service mesh capabilities since 2024, and native compatibility with Google Kubernetes Engine (GKE) for IP address management and forwarding.[26][27] Notable adoption events include its use by companies like Datadog for scaling Kubernetes clusters with network policies, processing over 10 trillion data points per day across more than 18,000 customers.[28] The project has also addressed security vulnerabilities through timely patches, such as those for CVE-2022-29178 and CVE-2022-29179, which fixed issues in service load balancing and identity allocation to prevent denial-of-service attacks.[29][30]

Architecture

Core Components

Cilium's core components form the foundational elements of its architecture, enabling efficient networking, security, and observability in cloud-native environments. These components work together to leverage eBPF for high-performance data paths while managing cluster-wide operations and state.[31] The Cilium Agent is a daemon that runs on each node in the cluster, responsible for loading and managing eBPF programs, enforcing network policies, and handling local networking tasks such as IP address management (IPAM) for pods. It interacts directly with the Linux kernel to attach eBPF programs to network interfaces and monitors endpoint changes to update security identities and policies dynamically. Additionally, the agent provides observability features by collecting metrics and traces from the eBPF data plane.[31][10] The Cilium Operator serves as a cluster-wide controller, performing tasks that require global coordination, such as IPAM across the entire cluster, garbage collection of unused resources, and synchronization of identities and policies. It operates outside of individual nodes, using Kubernetes APIs to watch for changes and ensure consistency, thereby offloading non-local responsibilities from the agents to improve scalability. The operator also manages the lifecycle of cluster-scoped resources like load balancers and service configurations.[31][10] Cilium integrates with Envoy, a high-performance proxy, to enable Layer 7 (L7) proxying and traffic management in service mesh mode, allowing for advanced features like HTTP and gRPC policy enforcement without sidecar proxies. This integration embeds Envoy instances within Cilium agents on each node, redirecting traffic transparently to apply L7 policies, load balancing, and observability while maintaining eBPF's efficiency for L3/L4 handling.[32][33] BPF maps are in-kernel data structures used by Cilium to store and manage state, configuration, and telemetry efficiently, with types such as hash maps for quick lookups of endpoint identities based on IP addresses or labels. These maps, including endpoint maps that associate IP addresses with security identities and policy maps that track allowed connections, enable O(1) access times regardless of cluster scale and support features like identity-based security enforcement. Cilium creates these maps with capacity limits to ensure predictable performance and scalability in the data path.[34][35]

eBPF Integration

Cilium leverages eBPF to implement high-performance networking at the kernel level, attaching programs to specific hooks for efficient packet processing. For ingress traffic, Cilium uses the XDP (eXpress Data Path) hook, which operates at the earliest stage in the network driver upon packet reception, enabling rapid filtering and dropping of invalid packets before further processing.[36] For container egress traffic, Cilium attaches eBPF programs to the Traffic Control (TC) ingress hook on the host side of virtual Ethernet (veth) pairs to enforce policies and redirect packets after initial stack processing but before Layer 3 forwarding; generally, for egress traffic, it uses the TC egress hook on networking interfaces.[36] Additionally, Cilium employs sockops hooks at the socket level, attached to the root cgroup to monitor TCP state transitions, particularly for established connections, allowing attachment of send/receive programs that inspect and redirect messages without kernel-user space crossings.[36] The programmability of eBPF in Cilium allows for the generation of custom programs derived from high-level user policies, which are compiled into eBPF bytecode using LLVM's BPF backend for just-in-time loading into the kernel.[37] These programs maintain a stable application binary interface (ABI) with "never-break-user-space" guarantees, enabling atomic updates without disrupting ongoing traffic, and can be tailored for tasks like policy enforcement or load balancing.[38] The Cilium agent, responsible for managing these programs, compiles and loads them dynamically based on cluster state changes.[36] Key advantages of this integration include zero-copy data paths, where packets are processed directly on DMA buffers in the kernel without unnecessary copying to user space, and reduced context switches by executing logic entirely within kernel space.[37] Cilium requires a Linux kernel version of at least 5.10 (or 4.18 on RHEL 8.10 equivalents) for core eBPF features, with advanced capabilities like multicast support needing 5.10 or higher on AMD64 architectures.[39] Cilium utilizes specific eBPF helper functions to enhance its operations, such as bpf_map_lookup_elem for efficient lookups in kernel maps to retrieve policy identities or service forwarding rules based on packet details.[36] Similarly, bpf_redirect is employed for packet steering, allowing seamless redirection of traffic to local endpoints, other interfaces, or accelerated paths in socket hooks.[38]

Deployment and Configuration

Installation Methods

Cilium installation requires specific system prerequisites to ensure compatibility with its eBPF-based functionality. Nodes must run a Linux kernel version 5.10 or later (or equivalent, such as 4.18 on RHEL 8.10), with eBPF support enabled via kernel configuration options, and kernel headers installed if compiling eBPF programs on the host.[39] Additionally, Cilium agents typically require privileged pod execution and read-write access to the /sys/fs/bpf filesystem for loading eBPF maps and programs.[39] For Kubernetes environments, one primary installation method is using Helm, which allows for customizable deployment of Cilium as a Container Network Interface (CNI). To install via Helm, first add the Cilium Helm repository with helm repo add cilium https://helm.cilium.io/, update repositories using helm repo update, and then run helm install cilium cilium/cilium --version 1.18.5 --namespace kube-system (replacing the version as needed), optionally including flags like --set kubeProxyReplacement=true to enable kube-proxy replacement for enhanced performance.[40] This method supports advanced options during installation, such as specifying IPAM modes or enabling specific eBPF features.[40] In standalone mode for non-Kubernetes setups, such as containerized environments supporting CNI plugins, Cilium can be deployed by using the Cilium CNI plugin and running the cilium-agent binary directly with appropriate configuration flags, without relying on Kubernetes orchestration. Users can download the cilium-agent from official releases and execute it as a standalone network service leveraging eBPF for connectivity, though support for such setups is limited and not actively maintained.[41] This approach is suitable for bare-metal container hosts that implement CNI specifications, with caveats for deprecated integrations like Docker.[41] Cilium supports installation across various Kubernetes distributions and local development tools, with tailored guides for environments like kind, minikube, and cloud providers such as Amazon EKS. For local clusters, the quick installation using cilium install automatically detects configurations for kind or minikube, ensuring seamless setup on laptops for development.[42] On Amazon EKS, installation in ENI mode involves disabling the default AWS VPC CNI add-on, then deploying Cilium via Helm or CLI with EKS-specific parameters like --set eni.enabled=true to utilize Elastic Network Interfaces for native AWS integration.[43] These multi-environment guides emphasize verifying cluster compatibility and applying provider-specific prerequisites before proceeding.[42]

Configuration Options

Cilium offers a range of configuration options to customize its behavior post-installation, allowing users to tailor networking, security, and observability features to specific cluster requirements. These options are primarily managed through the cilium-config ConfigMap, Helm values during upgrades, or command-line flags for the Cilium agent, enabling fine-grained control over performance and functionality.[44][13] Key flags for load balancing include those related to socket load balancing (Socket LB) and BPF-based external access. Socket LB, which enables host-level load balancing for Kubernetes services using eBPF cgroup hooks, is activated by setting kubeProxyReplacement=true in the Helm installation or upgrade command, replacing traditional kube-proxy for efficient traffic translation at the socket layer during system calls like connect() or sendmsg().[45] For external service access, the --bpf-lb-external-clusterip flag (default: false) allows external connectivity to ClusterIP services by enabling BPF load balancing for them, which can be set via the agent's command-line arguments or ConfigMap equivalents.[46] Cilium's Ingress Controller supports the PROXY protocol, which preserves client IP information when traffic passes through proxies or load balancers. This can be enabled using the Helm value ingressController.enableProxyProtocol (default: false) or the cilium-operator flag --enable-ingress-proxy-protocol. When enabled, proxy protocol is activated for all Ingress listeners, and only PROXY protocol traffic is accepted (non-PROXY traffic is rejected). Similar support exists for Gateway API listeners via the cilium-operator flag --enable-gateway-api-proxy-protocol.[13][14] Policy enforcement modes in Cilium determine how network traffic is handled for endpoints, configurable via the policyEnforcementMode Helm value or the enable-policy flag. The default mode allows unrestricted access for endpoints until they are selected by a policy, at which point it enforces default-deny for ingress or egress based on the policy sections, permitting only explicitly allowed traffic; this can be adjusted per policy using the enableDefaultDeny field set to false to avoid restrictions.[47] In contrast, the "always" mode (often considered stricter) enforces policies on all endpoints regardless of selection, requiring explicit allowances for all traffic, while the "never" mode disables enforcement entirely.[47] For example, a CiliumClusterwideNetworkPolicy CRD might specify: 
apiVersion: cilium.io/v2
kind: CiliumClusterwideNetworkPolicy
metadata:
  name: intercept-all-dns
spec:
  endpointSelector:
    matchExpressions:
      - key: "io.kubernetes.pod.namespace"
        operator: "NotIn"
        values: ["kube-system"]
      - key: "k8s-app"
        operator: "NotIn"
        values: ["kube-dns"]
  enableDefaultDeny:
    [egress](/page/Egress_filtering): false
    ingress: false
  egress:
    - toEndpoints:
        matchLabels:
          io.kubernetes.pod.namespace: "kube-system"
          k8s-app: "kube-dns"
      toPorts:
        - ports:
            - port: ["53"](/page/List_of_DNS_record_types)
              protocol: [TCP](/page/Transmission_Control_Protocol)
            - port: "53"
              protocol: [UDP](/page/User_Datagram_Protocol)
      rules:
        dns:
          matchPattern: "*"
This policy intercepts DNS traffic without enforcing default-deny, allowing other traffic to proceed unaffected.[47] Observability configurations, particularly for Hubble, are enabled to provide network flow visibility. Hubble is activated using the Cilium CLI command cilium hubble enable, which patches the ConfigMap, restarts pods, and deploys the Relay component, requiring TCP port 4244 open on nodes; alternatively, via Helm with --set hubble.enabled=true and --set hubble.relay.enabled=true.[48] For exporting data to Grafana, Hubble metrics can be integrated by configuring Prometheus as a data source to scrape Hubble's exposed metrics endpoints, though specific export flags are managed through standard Kubernetes monitoring setups rather than direct Cilium flags.[48] Resource limits for Cilium agents, including CPU and memory requests, are specified via Helm values under agent.resources to ensure optimal allocation in resource-constrained environments. By default, this is an empty object {}, requiring explicit settings such as requests: {cpu: "100m", memory: "512Mi"} and limits: {cpu: "1000m", memory: "2Gi"} in the values file during Helm upgrades to prevent overconsumption while maintaining performance.[13] Features like IPv6 can be disabled for single-stack IPv4 clusters by setting enable-ipv6: "false" in the cilium-config ConfigMap, which requires restarting Cilium pods for the change to propagate, typically taking up to 2 minutes across nodes.[44]

Use Cases and Applications

Networking in Kubernetes

Cilium serves as a Container Network Interface (CNI) plugin for Kubernetes, enabling efficient pod-to-pod communication through its integration with eBPF for high-performance networking.[44] As part of this integration, Cilium handles IP Address Management (IPAM) using BPF maps to allocate and track IP addresses for pods, allowing for scalable and dynamic address assignment without relying on external controllers.[49] This approach leverages kernel-level eBPF programs to manage IP allocations directly in BPF maps, providing O(1) lookup times and reducing latency compared to traditional IPAM methods.[10] For inter-node communication, Cilium supports overlay and encapsulation modes such as VXLAN and Geneve to create a virtual network across cluster nodes.[50] In these modes, pod traffic is encapsulated in UDP packets using VXLAN (default) or Geneve protocols, forming a tunnel mesh between nodes to route traffic over underlying layer 3 networks without requiring direct routing configurations.[51] This encapsulation ensures compatibility with diverse underlay networks, including those in multi-tenant cloud environments, while maintaining pod isolation.[9] Cilium enhances service load balancing in Kubernetes by replacing the default kube-proxy with an eBPF-based implementation that supports Direct Server Return (DSR).[45] In this setup, eBPF programs perform load balancing at the kernel level, rewriting connections at the socket level for east-west traffic and avoiding per-packet NAT overhead, which results in higher throughput and lower CPU usage, especially in large-scale clusters.[52] DSR mode allows backend pods to respond directly to clients without routing responses back through the load balancer node, optimizing performance for services with high traffic volumes.[10] Cilium fully supports and enforces standard Kubernetes NetworkPolicy resources (networking.k8s.io/v1) without deleting, modifying, or automatically removing them. It watches these policies via the Kubernetes API, as Kubernetes distributes them across nodes, and enforces them using eBPF programs at the kernel level.[53] Cilium extends the standard NetworkPolicy API with its own custom resource definitions, CiliumNetworkPolicy (namespaced) and CiliumClusterwideNetworkPolicy (cluster-scoped), which provide advanced features such as Layer 7 policy enforcement, identity-based selections, and granular control including HTTP-aware policies not available in the base API.[53] While standard Kubernetes NetworkPolicy focuses on Layer 3 and 4 rules using labels and namespaces, the Cilium extensions offer more capabilities, and the policy types are fully compatible for mixed usage in clusters, though caution is advised when combining multiple types to avoid confusion in policy behavior.[54][53] During migrations from another CNI provider to Cilium, the official documentation recommends temporarily deleting existing NetworkPolicies if necessary to avoid potential conflicts (with policy enforcement disabled during the migration process), but Cilium itself performs no automatic deletions or modifications.[55] These policies are enforced via eBPF at the kernel level for efficient, programmable data paths.[56] This networking foundation supports integration with security policies for comprehensive traffic control, as detailed in the relevant documentation.[53] To configure cluster-wide load balancing for Kubernetes Services of type LoadBalancer, administrators can enable Cilium's built-in eBPF load balancer (Cilium LoadBalancer IPAM) during installation, which advertises service IPs via BGP or Layer 2 protocols across the cluster.[57] For example, by setting the loadBalancer.mode to "dsr" and configuring BGP peers in the Cilium Helm chart, external traffic to LoadBalancer services is distributed efficiently without needing external tools like MetalLB, ensuring high availability and scalability.[58] This setup involves applying a CiliumLoadBalancerIPPool custom resource to define IP ranges and then creating Services that automatically leverage the eBPF-based balancing for global reachability.[59]

KubeVirt Integration

Cilium integrates with KubeVirt to provide secure, scalable, and observable networking for virtual machines (VMs) running alongside containers in Kubernetes clusters. KubeVirt VMs connect via the cluster's CNI, with Cilium treating them similarly to pods for IP allocation, service discovery, and policy enforcement.

Compatibility and Configuration

Deploy Cilium before enabling KubeVirt. For compatibility with KubeVirt's virtual device networking, configure the Helm value socketLB.hostNamespaceOnly=true during installation to enable socket load balancer bypass in pod namespaces.

Advantages

  • Unified Security and Zero Trust: Cilium Network Policies (L3/L4 and L7-aware) apply consistently to pods and VMs, enabling micro-segmentation and identity-based rules. Transparent encryption (WireGuard/IPsec) secures traffic.
  • Observability: Hubble provides deep insights into VM traffic flows, including real-time visualization and filtering across VMs, pods, and external endpoints.
  • Performance: eBPF datapath delivers high throughput and low latency compared to iptables-based CNIs. Supports live VM migration with network continuity.
  • Advanced Features: Gateway API for external VM access, BGP/ARP service exposure, and Cluster Mesh for multi-cluster pod-VM communication.

Performance Enhancements

Ongoing work accelerates KubeVirt networking with eBPF innovations like netkit devices and AF_XDP backend for QEMU. Preliminary benchmarks (e.g., netperf TCP_RR, 1500 MTU) show:
  • +13% better throughput in some configurations.
  • +37% throughput improvement with netkit + AF_XDP.
  • 30-35% lower latency.
These use netkit queue binding and RSS context based on VM MAC for closer-to-native performance.

Known Limitations and Issues

  • eBPF host-routing can interfere with KubeVirt's masquerade NAT on pod networks, requiring workarounds.
  • Netkit mode may assign invalid MAC addresses to KubeVirt interfaces; use netkit-l2 or custom bindings pending fixes.
  • Requires modern Linux kernel (≥4.19 recommended) for full eBPF features.
Hands-on resources include Isovalent's Cilium + KubeVirt lab (https://isovalent.com/labs/cilium-kubevirt/), demonstrating micro-segmentation, Hubble observability, and live migration. This integration positions Cilium as a strong choice for converged container/VM environments, unifying networking under one eBPF-based stack.

Security and Observability

Cilium provides robust security features through identity-aware policies, which enable fine-grained enforcement at Layers 3 through 7 by leveraging security identities rather than relying on ephemeral IP addresses.[60] These policies allow administrators to define rules based on pod identities, service accounts, or labels, ensuring consistent enforcement even as workloads scale or migrate within Kubernetes clusters.[61] By integrating eBPF for efficient policy application at the kernel level, Cilium supports zero-trust models without performance overhead.[62] Cilium enforces standard Kubernetes NetworkPolicy resources (networking.k8s.io/v1) using eBPF without deleting, modifying, or automatically removing them; Kubernetes distributes the policies, and Cilium applies them automatically by watching the Kubernetes API. Cilium additionally provides extended custom resources CiliumNetworkPolicy and CiliumClusterwideNetworkPolicy for more advanced Layer 3-7 policy capabilities.[53] Cilium's Layer 7 (L7) policies provide advanced protocol-specific enforcement, supporting HTTP, gRPC, Kafka, and DNS filtering. Additional capabilities include explicit deny rules for stricter access control and FQDN-based egress policies to restrict outbound traffic to approved domains. These features, combined with Tetragon for runtime security enforcement at the process level, enable comprehensive protection across network and runtime layers. A key component for runtime security is Tetragon, an eBPF-based tool that offers transparent observability and enforcement for processes in cloud-native environments.[63] Tetragon monitors system calls, file accesses, and process executions in real-time, enabling threat detection and policy enforcement directly within the Linux kernel without requiring agents or modifications to applications.[64] It supports Kubernetes-aware filtering, allowing users to trace the lifecycle of workloads and block suspicious activities, such as unauthorized executions, to mitigate risks like container escapes or lateral movement.[65] For observability, Cilium incorporates Hubble, a platform that delivers Layer 7 visibility into network traffic through detailed flow logs, service dependency graphs, and customizable alerting.[66] Hubble captures eBPF-generated events to map service interactions, identify bottlenecks, and detect anomalies, providing a unified view of communication patterns across the cluster.[67] This enables proactive monitoring, such as generating graphs that visualize dependencies and triggering alerts for policy violations or unusual traffic spikes.[68] Cilium maintains a strong security posture, as evidenced by a 2022 security audit conducted by Ada Logics on behalf of the CNCF, which found no critical or high-severity vulnerabilities and concluded that Cilium is a well-secured project. Recent CVEs identified in 2025-2026 have been patched promptly in subsequent releases to ensure ongoing security. Cilium also supports transparent encryption for node-to-node traffic using WireGuard, eliminating the need for sidecar proxies or application changes.[69] This feature encrypts pod-to-pod communications across nodes securely and efficiently, leveraging WireGuard's lightweight protocol to protect data in transit within Kubernetes clusters.[70] It ensures confidentiality without impacting performance, making it suitable for multi-tenant environments where isolating traffic is critical.[71]

Troubleshooting and Maintenance

Common Startup Issues

One common startup issue with Cilium in Kubernetes clusters is pod failures manifesting as CrashLoopBackOff status in the kube-system namespace, which can be identified by running the command kubectl get pods -n kube-system -l k8s-app=cilium.[72] This error often indicates that the Cilium agent pods are repeatedly crashing during initialization, potentially due to configuration errors or resource constraints on the nodes.[73] To diagnose such failures, administrators should review the previous container logs using kubectl -n kube-system logs <pod-name> --previous, where errors related to BPF map creation or loading frequently appear, such as failures in populating eBPF maps required for network policy enforcement.[72][74] Kernel version incompatibilities represent another frequent barrier to successful Cilium startup, as the project requires a Linux kernel version of 5.10 or later to enable full eBPF feature support.[39] In environments with older kernels, such as those below 5.10, essential eBPF programs may fail to load, leading to initialization halts.[75] Ensuring kernel compatibility is thus a prerequisite step, often verified through system checks before deployment.[39] Specific challenges can arise when disabling socketLB, a feature for kube-proxy replacement, as the Cilium agent requires privileged execution permissions and proper filesystem mounts to function correctly. Cilium generally requires CAP_SYS_ADMIN privileges, typically granted by running as a privileged container, to attach eBPF programs.[39] Additionally, the eBPF filesystem must be mounted at /sys/fs/bpf in read-write mode to persist eBPF resources across restarts.[39][76] For socketLB specifically, the cgroup v2 filesystem must be mounted, which Cilium handles automatically unless disabled. Without these configurations, the agent may fail to initialize properly. Administrators addressing these must verify security contexts and mount options in the Cilium DaemonSet configuration to resolve the issue.[39][45]

Diagnostic Tools and Checks

Cilium provides several command-line utilities and integration points for diagnosing and monitoring its operations in production environments, enabling administrators to inspect agent health, endpoint states, and eBPF-based data paths.[72] The Cilium CLI serves as a primary diagnostic tool, allowing users to check the overall status of the Cilium agent on a node with the cilium status command, which reports on connectivity, health, and configuration details.[77] Additionally, the cilium-dbg endpoint list command lists all endpoints managed by Cilium, displaying pod states, identities, and policy enforcement status for troubleshooting network connectivity issues.[78] For deeper inspection of load balancing mechanisms, administrators can execute commands directly within Cilium pods using kubectl exec -n kube-system cilium-<node> -- cilium-dbg bpf lb list, which queries eBPF maps to reveal the state of load balancers and service backends.[72] Cilium integrates with Prometheus for metrics collection and alerting, exposing detailed observability data on agent performance, error rates, and resource usage to facilitate proactive monitoring.[79] Complementing this, the Hubble tool enables real-time flow observation through commands like hubble observe, which streams network traffic details including identities, policies, and DNS resolutions for immediate debugging of live communications.[80] Advanced diagnostics involve using bpftool to verify loaded eBPF programs, listing maps, and inspecting program attachments to ensure kernel-level functionality is intact.[81] Checks for proper kernel mounts, such as the eBPF filesystem at /sys/fs/bpf, confirm that Cilium can access necessary resources, as Cilium will automatically mount it if not present.[39]

Community and Ecosystem

Contributions and Governance

Cilium operates as a graduated project under the Cloud Native Computing Foundation (CNCF), which provides technical oversight through its Technical Oversight Committee (TOC) to ensure alignment with cloud-native standards and community-driven development.[2] The project's governance model emphasizes collaborative decision-making, with core maintainers primarily affiliated with Isovalent (now part of Cisco), including notable figures like Joe Stringer, who was recognized as a top CNCF maintainer in 2024 for his contributions to Cilium.[82] This structure supports transparent processes for project evolution, including release planning and feature prioritization, while maintaining independence from any single vendor.[83] Contributions to Cilium follow established guidelines outlined in the project's GitHub repository, requiring adherence to the CNCF Code of Conduct to foster an inclusive environment.[84] Potential contributors are encouraged to triage issues via GitHub, participate in discussions, and submit pull requests after certifying their contributions via the Developer's Certificate of Origin (DCO) by including a Signed-off-by line in commit messages to grant the project necessary rights for code integration.[85] The process includes code reviews by maintainers and automated testing to maintain high standards, with detailed instructions available in the official contributing documentation.[86] As of 2024, the Cilium community boasts over 1,000 contributing companies (1,011 as reported) and a robust base of over 4,000 individual contributors, reflecting significant growth since its CNCF incubation in 2021.[87] This includes thousands of contributors engaged in pull requests and issue resolutions.[4] Community engagement is further amplified through events like CiliumCon, a dedicated co-located conference at KubeCon that brings together users, developers, and contributors to discuss advancements in eBPF-based networking and security.[88] The diversity of contributions highlights expertise in eBPF technology and involvement from major cloud providers, enabling broad innovation in areas like Kubernetes networking and observability.[89] Participants from organizations such as Google, AWS, and Microsoft collaborate alongside independent eBPF specialists, ensuring the project's applicability across varied cloud-native ecosystems.[87] This collaborative model has driven consistent velocity, positioning Cilium as one of the most active CNCF projects behind only Kubernetes and OpenTelemetry.[90]

Integrations with Other Tools

Cilium provides deep integration with Istio, enabling enhanced service mesh capabilities in Kubernetes clusters by leveraging Cilium's eBPF-based networking for improved performance in Layer 7 proxying and policy enforcement.[91] This integration allows users to deploy Istio alongside Cilium, combining Istio's traffic management features with Cilium's efficient data path processing.[92] When using Cilium's kube-proxy replacement mode (kubeProxyReplacement=true), the default socket-level load balancing applies within pod namespaces, which can bypass Istio sidecar redirection and prevent proper traffic interception by the sidecar. To maintain compatibility and allow Istio sidecars to intercept traffic, set the Helm value socketLB.hostNamespaceOnly=true (equivalent to bpf-lb-sock-hostns-only=true in the ConfigMap). This restricts socket LB to the host namespace only. This configuration is recommended in the official Cilium Istio integration documentation for environments running Istio with full kube-proxy replacement. Cilium also offers Proxy Load Balancing for Kubernetes Services as a lightweight alternative to full Istio sidecar deployments for basic Layer 7 requirements. By annotating a Service with service.cilium.io/lb-l7: enabled, traffic is redirected to a per-node shared Envoy proxy for L7-aware load balancing, including support for protocols like gRPC. This feature (currently in beta) provides efficient L7 capabilities without the overhead of per-pod proxies. For details, refer to the Cilium Proxy Load Balancing documentation. For GitOps deployments, Cilium supports tools like Flux, facilitating automated installation and management of Cilium operators through declarative configurations stored in version control repositories.[93] In the monitoring stack, Cilium offers native support for Prometheus to collect and store metrics from Cilium agents and operators, which can then be visualized using Grafana dashboards for cluster-wide network and security insights.[94] Additionally, Cilium's Hubble observability layer enables export of trace and flow data to Jaeger for distributed tracing analysis.[95] Cilium demonstrates compatibility with Falco for runtime security detection, where Falco can leverage Cilium's network policies and APIs to enforce restrictions based on detected threats in Kubernetes environments.[96] For cloud integrations, Cilium includes official operators tailored for managed Kubernetes services on AWS, Azure, and Google Cloud Platform (GCP), enabling seamless IP address management and routing optimizations specific to each provider.[97] For instance, the AWS ENI mode in Cilium automates Elastic Network Interface handling for efficient pod networking.[98] Similar support exists for Azure and GCP through native cloud provider integrations.[99]

Comparisons and Alternatives

Vs. Traditional CNI Plugins

Cilium differs from traditional Container Network Interface (CNI) plugins like Flannel primarily through its use of eBPF technology, which avoids the overhead associated with overlay networks that Flannel relies on for pod-to-pod communication. Flannel employs a VXLAN-based overlay that encapsulates packets, introducing additional latency and reducing throughput in large-scale deployments, whereas Cilium's kernel-level eBPF programs enable direct routing without such encapsulation, leading to higher performance and better scalability for clusters with over 10,000 pods.[100][101][102] In comparison to Calico, Cilium provides superior Layer 7 (L7) policy enforcement by leveraging eBPF for programmable data paths, bypassing the limitations of iptables chains that Calico traditionally uses, which can result in increased latency as the number of rules grows. Calico's iptables-based approach often leads to performance degradation under high policy loads due to linear rule traversal, while Cilium's eBPF implementation allows for efficient, identity-aware L7 filtering with reduced CPU overhead and lower latency, making it more suitable for complex microservices environments.[103][104][105] Traditional CNI plugins, such as Flannel and Calico in their non-eBPF modes, suffer from user-space processing bottlenecks where packet handling occurs outside the kernel, leading to higher latency and resource consumption compared to eBPF's in-kernel execution. Additionally, these legacy plugins often lack native observability features, requiring separate tools for metrics and tracing, whereas Cilium integrates Hubble for real-time visibility without such dependencies.[106][107][108] Migrating from kube-proxy to Cilium's eBPF-based load balancing involves several steps to ensure a smooth transition: first, assess the existing cluster configuration and compatibility; second, install Cilium in a dual-CNI mode alongside the current setup to test functionality; third, enable the eBPF kube-proxy replacement mode via Helm values like kubeProxyReplacement=strict; and finally, remove the old kube-proxy daemonset once stability is confirmed, leveraging Cilium's compatibility with Kubernetes services for seamless load balancing.[109][52]

Vs. Other eBPF-Based Solutions

Cilium differentiates itself from other eBPF-based solutions through its comprehensive integration of networking, security, and observability features, particularly when compared to Calico's eBPF mode. While Calico's eBPF data plane primarily emphasizes efficient routing and network policy enforcement via BGP or IP-in-IP overlays, Cilium provides a full-stack approach that extends beyond routing to include advanced Layer 7 security policies and integrated observability via Hubble, enabling detailed flow-level visibility without additional tooling.[110][104][111] In contrast to Katran, an eBPF-based load balancer developed by Facebook for high-performance traffic distribution, Cilium offers a Kubernetes-native architecture tailored for containerized environments, whereas Katran focuses on hardware-accelerated load balancing optimized for bare-metal deployments and general-purpose networking without deep Kubernetes integration.[112][113] Cilium's unique strengths lie in its programmable policies, which leverage eBPF to enable fine-grained, identity-aware enforcement at Layers 3-7, surpassing the capabilities of more experimental eBPF projects, and its maturity as a CNCF Graduated project since 2023, ensuring robust governance and widespread adoption in production environments.[60][2] Benchmarks as of 2026 show Cilium and Calico eBPF achieving very close performance, with differences under 5-10% in most metrics including throughput and latency, due to maturing eBPF dataplanes in both projects.

Comparison with Calico

Cilium offers native open-source Layer 7 policy enforcement, better scalability at large scales without iptables bloat from rule accumulation, and an identity-first approach that bases policies on workload identities rather than IP addresses, providing advantages over Calico in complex, high-scale environments. Calico and Cilium are leading Kubernetes CNIs, with Cilium being eBPF-native and Calico offering multi-dataplane flexibility.
FeatureCiliumCalico
Core TechnologyeBPF-onlyiptables/nftables, eBPF, VPP, Windows HNS
Network PoliciesL3–L7 native (HTTP, gRPC, etc.)L3/L4 strong, L7 via integration
ObservabilityHubble (L3-L7 flows, service map)Flow logs, metrics; advanced in Enterprise
PerformanceVery high, low latencyHigh; eBPF mode parity with Cilium
Kube-Proxy ReplacementMature, defaultAvailable in eBPF mode
EncryptionWireGuard, IPsecWireGuard, IPsec
Windows SupportLimitedStrong
Best ForModern cloud-native, observability, L7 securityHybrid, large-scale, BGP fabrics, Windows
As of 2026, Calico's eBPF dataplane (v3.28+) provides performance close to Cilium, with differences under 5-10% in most benchmarks. Choose Cilium for native L7 and Hubble; Calico for flexibility and maturity in enterprise/hybrid setups.

Future Directions

Ongoing Developments

Cilium 1.15, released on February 1, 2024, introduced gRPC routing via the Gateway API, enabling efficient handling of gRPC traffic.[93] This version also improved multi-tenancy features, including a doubled Cluster Mesh scale to 511 clusters for better multi-cluster deployments and BGP support for multi-pool IPAM to enable flexible IP allocation across namespaces and annotations.[93] Additionally, the Hubble Flow Exporter was enhanced to provide dynamic filtering by namespaces, aiding observability in multi-tenant environments.[93] Recent bug fixes and patches in Cilium address eBPF-related issues, including improvements in attaching BPF programs to kernel modules and handling data sections, ensuring compatibility with evolving kernel versions such as 6.x.[114] Community discussions in 2024 explored Windows support, with the project open to contributions for additional platform integrations, but as of 2026, Cilium does not support Windows nodes.[115][116] Similarly, work on edge computing integrations progresses, including compatibility with tools like KubeEdge for efficient networking in distributed edge deployments.[117]

Potential Enhancements

Cilium's roadmap emphasizes enhancements to its zero-trust security model, including more efficient encryption mechanisms and advanced threat detection capabilities. Transparent encryption using in-kernel IPsec or WireGuard provides a foundation to improve performance in secure environments.[61] Additionally, integration with tools like Tetragon enables runtime anomaly detection for events such as process execution and system calls.[61] As the Linux kernel evolves, Cilium is positioned to adapt to upcoming eBPF features, such as improved dynamic program loading, which would allow runtime modifications to eBPF programs based on user inputs without full recompilation.[118] These enhancements could enable more flexible and responsive networking behaviors in cloud-native setups.[119] Ecosystem expansions for Cilium include deeper integration with WebAssembly (Wasm) to support user-space extensions, complementing eBPF's kernel-level operations. By leveraging Wasm runtimes like Wasmtime, developers can execute complex, application-specific logic in user space with near-native performance and secure isolation, addressing eBPF's limitations in handling Turing-incomplete tasks such as advanced L7 routing.[120] This hybrid approach could extend Cilium's service mesh capabilities, reducing resource overhead compared to traditional sidecar proxies while enabling customizable extensions in languages like Rust or C++.[120] Key challenges in Cilium's future development involve addressing limitations in non-Linux environments, where eBPF's reliance on the Linux kernel restricts native support, potentially requiring alternative implementations or compatibility layers for broader platform adoption.[1] Furthermore, incorporating quantum-safe cryptography poses hurdles, as larger public keys in algorithms like ML-KEM (Kyber) can exceed packet size limits in TLS handshakes, impacting networking tools like Cilium in Kubernetes clusters and necessitating adjustments to handle oversized ClientHello messages.[121] These gaps highlight areas for innovation to ensure Cilium's resilience against emerging quantum threats while expanding beyond Linux-centric deployments.[121]

References

  1. Cilium - Cloud Native, eBPF-based Networking, Observability, and ...
  2. Cilium | CNCF
  3. Cilium — Isovalent Enterprise Platform documentation
  4. Cilium Project Journey Report | CNCF
  5. Cilium Graduates at the CNCF - Isovalent
  6. Cilium Service Mesh - Everything You Need to Know - Isovalent
  7. Isovalent - Products, Competitors, Financials, Employees ...
  8. Cloud Native Computing Foundation Announces Cilium Graduation
  9. Introduction to Cilium & Hubble
  10. cilium/cilium: eBPF-based Networking, Security, and Observability
  11. Cilium Proxy Load Balancing documentation
  12. Unlocking cloud native security with Cilium and eBPF | CNCF
  13. Cilium Helm Reference
  14. cilium-operator Command Reference
  15. Security - Cilium
  16. Isovalent Raises $40M Series B as Cilium and eBPF Transform ...
  17. Ep. #30, Cilium and eBPF with Thomas Graf of Isovalent | Heavybit
  18. What is eBPF? An Introduction and Deep Dive into the eBPF ...
  19. Cilium - Container Security and Networking Using BPF and XDP
  20. https://medium.com/codex/from-container-chaos-to-cloud-native-clarity-the-cilium-story-how-ebpf-revolutionized-8fc5e75a77ad
  21. https://investor.cisco.com/news/news-details/2024/Cisco-Completes-Acquisition-of-Isovalent-to-Define-the-Future-of-Multicloud-Networking-and-Security/default.aspx
  22. https://cilium.io/blog/2018/04/24/cilium-10/
  23. KVstore-free operation, 100% kube-proxy replacement ... - Cilium 1.6
  24. Network, Service & Security Observability for Kubernetes - Cilium
  25. Cilium 1.14 - Effortless Mutual Authentication, and much more
  26. Getting Started with Cilium Service Mesh on Amazon EKS - AWS
  27. Google Kubernetes Engine — Cilium 1.19.0-dev documentation
  28. Datadog | CNCF
  29. CVE-2022-29178 Detail - NVD
  30. CVE-2022-29179 Detail - NVD
  31. Component Overview — Cilium 1.18.5 documentation
  32. L7 Load Balancing and URL re-writing - Cilium
  33. Isovalent Labs Resource Library Cilium Envoy L7 Proxy
  34. eBPF Maps — Cilium 1.18.5 documentation
  35. Cilium Technical Deep Dive — Understanding the eBPF Data Path
  36. eBPF Datapath Introduction - Cilium
  37. BPF Architecture — Cilium 1.18.5 documentation
  38. Program Types — Cilium 1.18.5 documentation
  39. System Requirements — Cilium 1.18.5 documentation
  40. Installation using Helm — Cilium 1.18.5 documentation
  41. Is it possible to run Cilium without Kubernetes? #13072 - GitHub
  42. Cilium Quick Installation — Cilium 1.18.5 documentation
  43. Installing Cilium on EKS in ENI Mode
  44. Configuration — Cilium 1.18.5 documentation
  45. Kubernetes Without kube-proxy — Cilium 1.18.5 documentation
  46. cilium-agent — Cilium 1.18.5 documentation
  47. Policy Enforcement Modes — Cilium 1.18.5 documentation
  48. Setting up Hubble Observability — Cilium 1.18.5 documentation
  49. Learn How to Build an eBPF CNI Plugin from Scratch | Solo.io
  50. Routing — Cilium 1.18.5 documentation
  51. Choosing the Right Routing in Cilium - Solo.io
  52. Kube-proxy Replacement - Cilium
  53. Network Policy — Cilium 1.19.0 documentation
  54. Use Cilium for NetworkPolicy | Kubernetes
  55. Migrating a cluster to Cilium — Cilium 1.19.0 documentation
  56. Overview of Network Policy — Cilium 1.18.5 documentation
  57. Layer 4 Load Balancer - Cilium
  58. Using Cilium as a Kubernetes Load Balancer - Rafay Docs
  59. Migrating from MetalLB to Cilium - Isovalent
  60. Advanced Network Policy - Cilium
  61. Zero Trust Security with Cilium - Isovalent
  62. eBPF - The Future of Networking & Security - Cilium
  63. Runtime Security - Cilium
  64. Tetragon - eBPF-based Security Observability and Runtime ...
  65. cilium/tetragon: eBPF-based Security Observability and ... - GitHub
  66. Network Observability with Hubble — Cilium 1.18.5 documentation
  67. Hubble - Network, Service & Security Observability for Kubernetes ...
  68. Hubble for Network Observability and Security (Part 1) - Cilium
  69. Transparent Encryption — Cilium 1.18.5 documentation
  70. Transparent Encryption - Cilium
  71. Transparent encryption of node to node traffic on Amazon EKS using ...
  72. Troubleshooting — Cilium 1.18.5 documentation
  73. Cilium pod fails to start due to CrashLoopBackOff error in config init ...
  74. Cilium Not Updating BPF Maps - Doctor Droid
  75. Troubleshooting — Cilium 1.19.0-dev documentation
  76. Error mounting sys-fs-bpf.mount on Ubuntu 20.04 Focal · Issue #10955
  77. Command Cheatsheet — Cilium 1.18.5 documentation
  78. cilium-dbg endpoint list — Cilium 1.18.5 documentation
  79. Monitoring & Metrics — Cilium 1.18.5 documentation
  80. Introduction to Cilium & Hubble
  81. Debugging and Testing — Cilium 1.18.5 documentation
  82. Isovalent announces Cilium maintainer recognized as top CNCF ...
  83. Move Governance to the community repo · Issue #78 - GitHub
  84. cilium-cli/CONTRIBUTING.md at main - GitHub
  85. How To Contribute — Cilium 1.19.0-dev documentation
  86. cilium/CONTRIBUTING.md at main - GitHub
  87. A look at the Cilium CNCF project journey report
  88. https://events.linuxfoundation.org/archive/2023/kubecon-cloudnativecon-north-america/co-located-events/ciliumcon/
  89. Cilium's 2023 annual report | CNCF
  90. CNCF firms up Cilium cell structure - Computer Weekly
  91. official Cilium Istio integration documentation
  92. What Cilium and BPF will bring to Istio
  93. Cilium 1.15 - Gateway API 1.0 Support, Cluster Mesh Scale Increase ...
  94. Running Prometheus & Grafana — Cilium 1.18.5 documentation
  95. Cilium 1.12 - Ingress, Multi-Cluster, Service Mesh, External ...
  96. Introducing Falco Feeds by Sysdig
  97. Cloud Providers - Cilium
  98. AWS ENI — Cilium 1.18.5 documentation
  99. High Performance Cloud Native Networking (CNI) - Cilium
  100. Cilium vs Calico vs Flannel - Civo.com
  101. The Ultimate Guide To Using Calico, Flannel, Weave and Cilium
  102. Kubernetes CNI: The Ultimate Guide (2025) - Plural
  103. What is Kube-Proxy and why move from iptables to eBPF? - Isovalent
  104. Calico vs. Cilium: Which Kubernetes CNI Is Right for You? - Zesty.co
  105. Calico vs. Cilium: Choosing the Right Kubernetes CNI
  106. Network Plugins and eBPF Deep Dive - DevOps.dev
  107. Cilium: The eBPF-Based Revolution in Kubernetes Networking ...
  108. Top 20 Cilium Use Cases - Isovalent
  109. Tutorial: How to Migrate to Cilium - Isovalent
  110. Calico vs. Cilium: 9 Key Differences and How to Choose - Tigera
  111. CNI Benchmark: Understanding Cilium Network Performance
  112. eBPF Applications Landscape
  113. Set Up Katran eBPF Load Balancer - PHB Crystal Ball
  114. Releases · cilium/ebpf - GitHub
  115. CFP: when will support wIndows node #34929 - cilium/cilium - GitHub
  116. https://docs.cilium.io/en/stable/operations/system_requirements/
  117. Enable Cilium with KubeEdge
  118. Documentations for dynamically loading eBPF programs ... - GitHub
  119. Roadmap — Cilium 1.18.5 documentation
  120. eBPF and Wasm: Exploring the Future of the Service Mesh Data Plane
  121. Post-Quantum Cryptography in Kubernetes
User Avatar
No comments yet.