History
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
Cilium was accepted into the Cloud Native Computing Foundation on October 13th, 2021 as an incubation-level project. It applied to become a graduated project on October 27th 2022. [19] It became a Graduated project one year later. Cilium is one of the fastest-moving projects in the CNCF ecosystem. [30]
Adoption
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
Cilium
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
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
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
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
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.
This page is based on this
Wikipedia article Text is available under the
CC BY-SA 4.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.
