Cilium on Kubernetes isn’t just a CNI; it’s a fundamental shift in how your network operates, treating network packets as objects to be manipulated with incredible speed and flexibility.
Let’s see Cilium in action. Imagine a simple web application deployed across a few pods.
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-webapp
spec:
replicas: 3
selector:
matchLabels:
app: my-webapp
template:
metadata:
labels:
app: my-webapp
spec:
containers:
- name: web
image: nginxdemos/hello:plain-text
ports:
- containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
name: my-webapp-svc
spec:
selector:
app: my-webapp
ports:
- protocol: TCP
port: 80
targetPort: 80
type: ClusterIP
With Cilium installed, we can leverage its advanced features. For instance, instead of relying solely on Kubernetes Network Policies (which are translated by Cilium), we can use CiliumNetworkPolicies for more granular control, including L7 protocol awareness.
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
name: deny-all-ingress-to-webapp
spec:
endpointSelector:
matchLabels:
app: my-webapp
ingress:
- fromEndpoints:
- matchLabels:
role: frontend # Assuming a frontend deployment with this label
toPorts:
- ports:
- port: "80"
protocol: TCP
rules:
http:
- method: "GET"
path: "/api/v1/users"
This policy restricts incoming traffic to pods labeled app: my-webapp to only accept GET requests on the /api/v1/users path from pods labeled role: frontend. Cilium intercepts these requests at the kernel level using eBPF, inspecting the HTTP method and path without needing to proxy the traffic.
The core problem Cilium solves is the inefficiency and limited visibility of traditional kernel-based networking and CNI plugins. By leveraging eBPP (extended Berkeley Packet Filter), Cilium can run custom programs directly within the Linux kernel. This allows it to bypass traditional network stacks for performance gains and implement complex networking and security policies with unprecedented efficiency.
When you install Cilium, it deploys a set of components:
- Cilium Agent (cilium-agent): Runs as a DaemonSet on each node. It’s responsible for managing the network interfaces for pods on that node, enforcing network policies, and communicating with the Kubernetes API. It uses eBPF to hook into network events.
- Cilium CLI (cilium-cli): A command-line tool for interacting with the Cilium agent, debugging, and managing policies.
- Cilium Operator: A deployment that manages the lifecycle of Cilium, especially for features like IP Address Management (IPAM) and identity allocation.
The Cilium agent is the workhorse. It watches Kubernetes API objects (Pods, Services, NetworkPolicies, CiliumNetworkPolicies) and translates them into eBPF programs that are loaded into the kernel. When a packet arrives at a node, the eBPF program attached to the network interface can inspect, modify, or drop the packet based on these policies. For pod-to-pod communication, Cilium can encrypt traffic using WireGuard or IPsec, or use direct routing (e.g., BGP) for maximum performance.
The most surprising outcome of using Cilium is how effectively it can replace not just your CNI but also your Ingress controller and network security tools. Because Cilium operates at the kernel level with eBPF, it can perform L7 load balancing and enforce sophisticated L7 security policies (like HTTP method and path filtering) without introducing a separate proxy like Envoy or Nginx. This dramatically reduces latency and complexity by keeping traffic processing within the kernel itself.
The next concept you’ll want to explore is Cilium’s Service Load Balancing, which offers a high-performance, eBPF-native alternative to kube-proxy.