Cilium : the future of cloud native network solutions ?

Search for a command to run...

Cilium is supported by Exoscale SKS from June 2022 :)
Cilium CNI is now the way to go for the mass, as it brings nice features in observability and security.
Summary Based on the Cloud Adoption Framework (CAF) and Well-Architected Framework (WAF), this project automates the audit of an entire Azure tenant in minutes, using AI and a sovereign environment to

Summary The N1 agent transforms how DevOps teams interact with Kubernetes infrastructures by combining conversational prompts and advanced automation, all powered by artificial intelligence. Concretel

We had the opportunity to attend Kubernetes Community Days (KCD) Suisse Romande, held at CERN in Geneva, on December 4th and 5th. These two days were full of discussions, workshops (we had the opportunity to participate to the Exoscale capture the fl...

With the recent annoncements regarding the Gateway APIs and the end of the Ingress Nginx maintenance, some aspects (historically managed by the Ingress Nginx) need to be re-adapted, we’ll shre one of those today: the TLS certificates management throu...

The CNCF has recently announced a major transition: Ingress Nginx, the “de facto” considered ingress controller, will officially reach end-of-life in March 2026. Official source here : https://kubernetes.io/blog/2025/11/11/ingress-nginx-retirement/#:...

During our visit to KubeCon in Paris, we attended a presentation by Nico Vibert & Dan Finneran of Isovalent about Cilium. I personnaly was hyper motivated to learn more about this network management solution that seems to be gaining traction!
Indeed, Kubernetes isn't designed with an easy and "implicit" network management approach. This is where Cilium comes in and starts the presentation by introducing some questions:
Who manages the K8s network?
Often, network infrastructures are unaware that "pod networks" exist, what to do?
What tools are available for troubleshooting the K8s network?
How to check for bottlenecks and performance?
How to manage traffic encryption?
How to handle load balancing?
Other requirements : we need to secure our applications, we need to know what egress IP we're using for our pods in order to manage IP filtering, etc...
Natively in Kubernetes, all network rules are managed by a component called kube-proxy. This component controls iptables across all nodes of the cluster.
However, even thokugh iptables is widely used in the GNU/Linux environment, it's not always ideal.
Indeed, when iptables needs to update a rule, it must recreate and update all rules in a single transaction. This is a real problem when a cluster has a significant number of nodes and Pods running on it.
Moreover, this tool can only filter based on IP addresses or ports, not on potential paths or HTTP methods. This is somewhat inconvenient in a Kubernetes context where many applications are APIs.
Finally, iptables generally consumes a significant amount of CPU when running with Kubernetes.
Most of iptables' shortcomings are addressed with Cilium. It can filter at the Layer 7 (application) of the OSI model and addresses scalability issues that iptables struggled with.
eBPF is the primary answer. Indeed, eBPF allows direct communication with the kernel. In fact, a slide states "what Javascript is to the browser, eBPF is to the Linux Kernel."
eBPF is used to control the traffic, load balancers, network policies, service mesh, ingress, etc.
eBPF is low level kernel coded and that's the reason it's able to communicate with the kernel and manage traffic very quickly.

Note : ePBF is massively used by Facebook / Google / Netflix to handle the traffic. Think about that the next time you're loading content from them ;)
Here's a performance comparaison between eBPF / ipvs and iptables

The end of the presentation mainly revolves around use cases, showing manifest files after installation of Cilium.
You can find the video of the presentation here .
The installation can be done through different ways. The first one is using an Helm chart, the second one is using cilium-cli (doc available here ).
Example with helm :
helm repo add ciliumhttps://helm.cilium.io/
helm upgrade --install cilium cilium/cilium
--version 1.xx.x-rcx
--namespace kube-system
--set sctp.enabled=true
--set hubble.enabled=true
--set hubble.metrics.enabled="{dns,drop,tcp,flow,icmp,http}"
--set hubble.relay.enabled=true
--set hubble.ui.enabled=true
--set hubble.ui.service.type=NodePort
--set hubble.relay.service.type=NodePort
When it's done we can check the "cilium status" command to be sure that the cilium CNI was correctly installed.

AKS supports Cilium but has some limitations (no L7 rules, no hubble) . More details here :
https://learn.microsoft.com/en-us/azure/aks/azure-cni-powered-by-cilium#limitations
EKS: many advanced features of Cilium are not yet enabled as part of EKS Anywhere, including Hubble observability, DNS-aware and HTTP-Aware Network Policy, Multi-cluster Routing, Transparent Encryption, and Advanced Load-balancing. More details here :