The future of Kubernetes networking: Cilium and other CNIs with Canonical Kubernetes

Choosing the right Container Network Interface (CNI) for Kubernetes is critical to achieving optimal performance, security, and scalability. With the launch of  Canonical Kubernetes LTS (long-term support) last month, Canonical decided to integrate Cilium as the default CNI in order to reflect our commitment to delivering a modern, security-maintained, high-performance Kubernetes experience.

A quick look at popular CNIs

Several CNIs are available for Kubernetes, each with its own strengths and limitations. Let’s explore them in more detail.

Cilium

Traditional CNIs rely on iptables-based packet filtering and routing. Cilium is a modern CNI designed to address the evolving needs of cloud-native networking by leveraging eBPF (Extended Berkeley Packet Filter) for high-performance networking, security, and observability. Cilium operates at the kernel level with eBPF, allowing for more efficient and programmable network traffic handling. This modern approach eliminates the scalability limitations of legacy networking solutions and provides deep visibility into traffic flows without significant performance overhead. It allows for dynamic network policy enforcement, DNS-aware security policies, and seamless integration with service meshes. Cilium also enhances Kubernetes network observability, making it easier to debug issues and optimize performance. However, as a relatively new technology, eBPF-based networking may require more knowledge acquisition from network administrators, compared to traditional CNIs. For a detailed overview, we’d recommend exploring the  Cilium documentation.

Sponsored

class=”wp-block-heading”>Calico

Calico is a widely used CNI that provides robust network policy enforcement and supports both BGP and VXLAN for flexible network routing. It offers deep security capabilities, including workload identity, DNS-based policies, and eBPF-based networking acceleration. Calico is designed for high-scale production environments and integrates well with public cloud providers and on-premise deployments. However, Calico’s reliance on IP-based security policies may require additional configuration for use cases needing identity-based security models. More information can be found on Project Calico.

Flannel

Flannel is a simple and lightweight CNI primarily focused on providing pod connectivity. It supports multiple backends such as VXLAN, host-gw, and WireGuard (for encrypted tunnels). Flannel is easy to set up and a popular choice for lightweight Kubernetes clusters. However, it does not include built-in support for network policies, which limits its security and traffic control capabilities. This makes Flannel less suitable for production environments that require advanced networking features. More details can be found in the Flannel GitHub repository.

Multus

Multus is a CNI that enables the attachment of multiple interfaces to Kubernetes pods. It acts as a multiplexer and enables Kubernetes to use multiple CNIs simultaneously (including CNIs other than Multus), which is particularly useful in advanced networking scenarios such as network function virtualization (NFV), high-performance applications, and multi-network deployments. While powerful, Multus adds additional complexity in setup and management, which requires careful planning to ensure optimal performance and interoperability between CNIs. More information is available in the Multus GitHub repository. 

Multus plays a crucial role in enabling Enhanced Platform Awareness (EPA) features, which are essential for supporting the orchestration of cloud-native network functions. This is particularly important for telecommunications providers deploying next-generation 5G networks, where advanced networking capabilities like multiple network interfaces per pod, SR-IOV, and DPDK acceleration are required to meet stringent performance and latency requirements. Canonical Kubernetes fully supports EPA through Multus, providing telcos with a scalable and efficient solution for their cloud-native infrastructure. More information on EPA support can be found in the EPA explanation and EPA how-to guide.

OVN-Kubernetes

OVN-Kubernetes is an enterprise-grade CNI that provides software-defined networking (SDN) capabilities using Open Virtual Network (OVN). It offers native support for Kubernetes network policies, load balancing, and IPv6. OVN-Kubernetes relies on Open vSwitch (OVS), which provides industry-leading support for hardware acceleration, including Data Plane Development Kit (DPDK) and full hardware offload. This is particularly beneficial in high-performance environments, for instance, when using OVS-DOCA on high-performance hardware like NVIDIA’s BlueField DPUs to optimize network processing, reduce CPU overhead, and improve overall efficiency. More details can be found at OVN-Kubernetes.

Why Canonical chose Cilium

Canonical’s decision to adopt Cilium as the default CNI in its latest Kubernetes offering is driven by several key factors:

1. Performance and scalability: Cilium’s use of eBPF enables direct packet processing in the Linux kernel, reducing overhead and improving performance compared to traditional CNIs.
2. Security enhancements: With identity-based security policies and deep visibility into network traffic, Cilium enhances Kubernetes security beyond simple IP-based filtering.
3. Observability and troubleshooting: Cilium provides detailed insights into network flows, making it easier for operators to debug issues and optimize performance.
4. Seamless service mesh integration: Cilium integrates natively with service meshes, reducing the need for additional proxies and simplifying architecture.
5. Future-proofing: The adoption of eBPF ensures that Cilium is well-positioned to evolve with the changing needs of cloud-native networking.

For users looking to understand how Canonical Kubernetes handles networking by default, our official documentation provides a comprehensive guide to default networking. This guide explains the configuration and features of Cilium as the default CNI. Our aim is to make it simple for users to take full advantage of its performance and security benefits.

While Cilium is the default, Canonical recognizes that different workloads and environments may require alternative CNIs. As a result, Canonical Kubernetes supports other CNIs as first-class citizens. Whether users prefer Calico, Flannel, Multus, or OVN-Kubernetes, they can integrate their preferred networking solution with ease. More details on alternative CNI configurations can be found in Canonical’s alternative CNIs documentation.

With Cilium as the default CNI, Canonical Kubernetes users benefit from a cutting-edge networking stack that is not only simple to secure and high-performance, but also well-aligned with the future of cloud-native technologies. At the same time, Canonical Kubernetes remains highly flexible, allowing users to seamlessly adopt other CNIs as needed. Detailed tutorials are available to guide users through the setup of alternative CNIs such as Multus and Calico, ensuring smooth deployment and integration. Looking ahead, Canonical is actively working to simplify the deployment and management of even the most complex CNIs, including OVN-Kubernetes, to make them more accessible and easier to use in future releases.

Learn more about Canonical Kubernetes by visiting our dedicated Canonical Kubernetes page.