Cilium: eBPF Networking for Kubernetes

By Kokil Thapa | Last reviewed: September 2026

Cilium: eBPF Networking for Kubernetes is the CNI I reach for when a cluster needs more than basic pod connectivity. Traditional CNIs lean on iptables chains that grow with every Service and every rule. Cilium pushes policy and load balancing into eBPF programs attached at the kernel level. That shift cuts per-packet overhead and gives you identity-based security that scales better on busy nodes. If you already run Kubernetes for Laravel workloads on Kubernetes or multi-tenant SaaS, this guide walks through architecture, install, policy, and the production mistakes I see repeatedly.

What is Cilium and how does eBPF networking work in Kubernetes?

Cilium is a cloud-native CNI built around extended Berkeley Packet Filter (eBPF). Instead of programming thousands of iptables rules on every node, Cilium loads verified eBPF bytecode into the Linux kernel. Those programs handle routing, NAT, policy enforcement, and observability hooks at attach points like TC (Traffic Control) and XDP.

Each Kubernetes node runs a cilium-agent DaemonSet. The agent watches the Kubernetes API and Cilium CRDs. It compiles policy into eBPF maps that the kernel reads on every relevant packet. Pod identity comes from labels, not only IP addresses. That model aligns well with how Kubernetes network policies are written in the real world.

The control plane has two extra pieces beyond a typical CNI. The Cilium Operator manages cluster-wide resources like CiliumNode configs and IPAM modes. Hubble—optional but valuable—collects flow logs and service dependency maps from eBPF tracepoints. For deeper runtime security on the same stack, pair this with Tetragon runtime security with eBPF or compare against Falco runtime security depending on your threat model.

Why eBPF beats iptables at scale

iptables was never designed for dynamic microservice topologies. Every Service endpoint adds rules. Every network policy multiplies chains. On nodes running hundreds of pods, rule evaluation cost shows up as CPU spikes and latency jitter. eBPF programs run as compiled bytecode with map lookups—typically O(1) for policy decisions.

Kernel support matters. Cilium targets Linux 5.10 or newer for full feature coverage. Ubuntu 22.04 and 24.04 nodes on production clusters usually satisfy this. Verify with uname -r before you schedule a migration window. The official Cilium documentation lists minimum kernel features per release.

Cilium also supports several IPAM modes: cluster-pool, Kubernetes host-scope, ENI mode on AWS, and Azure IPAM. Pick the mode that matches your cloud or bare-metal layout. Wrong IPAM choice is a top cause of IP exhaustion on bare-metal Kubernetes with MetalLB clusters I have debugged.

How do you install Cilium on a Kubernetes cluster?

Install Cilium after the control plane is up but before you deploy application workloads. If another CNI is already active, plan a maintenance window. Switching CNIs in place is possible but messy. Greenfield clusters are straightforward.

1. Confirm kernel version 5.10+ and disable or remove the existing CNI if present.
2. Install the Cilium CLI on your admin workstation.
3. Deploy Cilium via Helm or cilium install with values tuned to your environment.
4. Enable kube-proxy replacement if you want full eBPF service load balancing.
5. Validate with cilium status and a test pod ping across nodes.
6. Optionally enable Hubble for flow visibility.

Cilium CLI install (typical greenfield path)

# Install Cilium CLI (Linux amd64 example)
CILIUM_CLI_VERSION=$(curl -s https://raw.githubusercontent.com/cilium/cilium-cli/main/stable.txt)
curl -L --fail -o cilium.tar.gz \
  "https://github.com/cilium/cilium-cli/releases/download/${CILIUM_CLI_VERSION}/cilium-linux-amd64.tar.gz"
sudo tar -C /usr/local/bin -xzf cilium.tar.gz cilium
rm cilium.tar.gz

# Install Cilium into the cluster
cilium install --version 1.16 \
  --set kubeProxyReplacement=true \
  --set k8sServiceHost=${API_SERVER_IP} \
  --set k8sServicePort=6443

# Verify
cilium status --wait
cilium connectivity test

Helm install for GitOps teams

Teams using Argo CD GitOps for Kubernetes usually prefer Helm. Add the Cilium repo, pin a chart version, and store values in Git.

helm repo add cilium https://helm.cilium.io/
helm repo update

helm upgrade --install cilium cilium/cilium \
  --namespace kube-system \
  --version 1.16.0 \
  --set operator.replicas=2 \
  --set kubeProxyReplacement=true \
  --set hubble.enabled=true \
  --set hubble.relay.enabled=true \
  --set hubble.ui.enabled=true

After install, confirm pod CIDR allocation and that CoreDNS resolves across nodes. A failed connectivity test often traces back to MTU mismatch on overlay tunnels or a firewall blocking VXLAN/Geneve between nodes. That pattern shows up on self-managed clusters deployed with Kubespray as often as on managed offerings.

How does Cilium compare to Calico and other Kubernetes CNI plugins?

Not every cluster needs Cilium. Small K3s edge clusters with a handful of services may run fine on Flannel. The switch pays off when you need L7 policy, deep observability, or kube-proxy replacement at scale.

Calico remains a solid choice when teams already know its CRDs and BGP peering model. Cilium wins when you want one stack for CNI, service load balancing, and flow-level debugging without bolting on five add-ons. For enterprise application platforms with strict east-west segmentation, Cilium's label-based identity model reduces the IP-churn pain you get after horizontal pod autoscaling events.

How do you configure network policies and observability with Cilium?

Standard Kubernetes NetworkPolicy objects work on Cilium. Cilium extends them with CiliumNetworkPolicy CRDs that add DNS-aware rules, HTTP path matching, and entity selectors like world or host.

Example: L4 policy between namespaces

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: allow-frontend-to-api
  namespace: production
spec:
  endpointSelector:
    matchLabels:
      app: api
  ingress:
  - fromEndpoints:
    - matchLabels:
        app: frontend
        io.kubernetes.pod.namespace: production
    toPorts:
    - ports:
      - port: "8080"
        protocol: TCP

Example: L7 HTTP policy

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: api-l7-allow
  namespace: production
spec:
  endpointSelector:
    matchLabels:
      app: api
  ingress:
  - fromEndpoints:
    - matchLabels:
        app: frontend
    toPorts:
    - ports:
      - port: "8080"
        protocol: TCP
      rules:
        http:
        - method: GET
          path: /api/v1/.*

Validate policies with cilium policy get and Hubble. Hubble UI shows allowed and denied flows in near real time. That beats tcpdump on a busy node when you are chasing a CrashLoopBackOff caused by network timeouts.

# Port-forward Hubble UI locally
kubectl port-forward -n kube-system svc/hubble-ui 12000:80

# Watch flows from CLI
hubble observe --namespace production --pod api \
  --verdict DROPPED

Export Hubble metrics to Prometheus for dashboards alongside Kubernetes performance tuning work. Flow drops correlated with latency spikes often reveal a missing egress rule to an external payment API—a pattern I have seen on production eCommerce stacks similar to Quick And Easy Nepalese Grocery.

When debugging JSON payloads returned from internal APIs during policy testing, a local JSON formatter keeps inspection readable without sending sensitive data to third-party sites.

What production gotchas should you plan for with Cilium on Kubernetes?

Cilium is stable on well-provisioned Linux nodes. Most outages I have traced come from environment mismatch, not from Cilium itself. Plan for these before you cut over production traffic.

• Kernel and BPF filesystem: Ensure bpffs is mounted at /sys/fs/bpf. Some minimal node images skip this.
• kube-proxy coexistence: Running kube-proxy alongside full kube-proxy replacement causes duplicate NAT rules. Pick one model and document it.
• MTU and tunnel overhead: Geneve/VXLAN adds bytes. Set pod network MTU below the physical NIC MTU minus overhead or you get silent TCP hangs.
• Node-local DNS cache: Policy must allow DNS to kube-dns or NodeLocal DNSCache endpoints. Deny-by-default namespaces break resolution first.
• Upgrade ordering: Upgrade Cilium agents before Kubernetes minor version jumps. Check the release compatibility matrix each cycle.
• Resource requests: Cilium agents use more memory than Flannel. Budget 500Mi–1Gi per agent on dense nodes.

Understand the broader node layout from Kubernetes worker node architecture and control-plane dependencies in Kubernetes architecture explained. That context speeds up triage when agents fail health checks after a kernel upgrade handled by your Linux system administration team.

Encryption and multi-cluster considerations

Cilium supports WireGuard-based transparent encryption between nodes. Enable it when traffic crosses untrusted L3 networks. For multi-cluster service discovery, Cilium Cluster Mesh links multiple Kubernetes clusters with global services. That is advanced ops. Start single-cluster, master policy and Hubble, then expand.

The eBPF ecosystem continues to mature. The eBPF project site tracks kernel features and tooling. Kubernetes networking fundamentals remain documented in the Kubernetes networking guide. Cross-reference both when you design upgrades.

When should you choose Cilium eBPF networking for Kubernetes?

Choose Cilium when observability and policy matter as much as connectivity. High-churn microservice clusters, regulated workloads, and platforms running service mesh features without a full Istio footprint are strong fits. Skip it when you operate a two-node lab and just need pods to ping each other—Flannel or the built-in K3s CNI is enough.

On booking and CRM platforms like Adventure Third Pole Trek, predictable east-west latency matters during checkout and supplier API calls. Cilium's eBPF load balancing removes kube-proxy iptables overhead that grows with Service count. Pair that with sensible resource limits and requests so network improvements are not wasted on CPU-starved pods.

Budget for learning curve time. Your platform team needs comfort with CiliumNetworkPolicy, Hubble, and agent upgrades. Ongoing support and maintenance should include a quarterly Cilium version review alongside Kubernetes patch cycles.

If you run containerised apps without Kubernetes yet, read Docker networking and volumes explained first. The concepts transfer directly. For broader platform context, see my work on production web systems since 2010 and related Kubernetes guides.

Key Takeaways

• Cilium replaces iptables-heavy CNIs with kernel eBPF for faster policy enforcement and optional kube-proxy-free service load balancing.
• Install via Cilium CLI or Helm after confirming Linux 5.10+, then run cilium connectivity test before production cutover.
• Use CiliumNetworkPolicy for L7 HTTP rules and DNS-aware egress controls beyond standard NetworkPolicy.
• Enable Hubble early—flow-level DROP visibility saves hours compared to blind tcpdump sessions.
• Watch MTU, kube-proxy overlap, and DNS allow rules; they cause most first-week production incidents.
• Choose Cilium for scale, zero-trust segmentation, and observability—not for minimal two-node lab clusters.

People Also Ask

Does Cilium replace kube-proxy in Kubernetes?

Yes, when you enable kube-proxy replacement during install. Cilium programs eBPF maps to handle ClusterIP, NodePort, and LoadBalancer forwarding without iptables rules from kube-proxy. You should disable or remove kube-proxy to avoid conflicting NAT behaviour.

What kernel version does Cilium require?

Cilium targets Linux 5.10 or newer for the full eBPF feature set including efficient kube-proxy replacement and advanced policy modes. Older kernels may work with reduced features. Always check the release notes for your chosen Cilium version before upgrading production nodes.

How is Cilium different from a service mesh like Istio?

Cilium operates at the CNI and node network layer using eBPF. It can enforce L7 HTTP policy without a full sidecar mesh, but it does not replace all Istio traffic management features like weighted canaries or rich mutual-TLS identity federation. Many teams use Cilium as the data plane and add a mesh only where advanced traffic shaping is required.

Can you run Cilium on managed Kubernetes like EKS or GKE?

Yes. EKS supports Cilium as an alternative CNI with the correct node configuration and IAM/network prerequisites. GKE Dataplane V2 is built on Cilium eBPF technology. Managed offerings reduce install friction but you still own policy design, upgrades, and observability integration.

Ship faster pod networking with the right CNI choice

Cilium: eBPF Networking for Kubernetes earns its place when policy, performance, and visibility cannot be afterthoughts. Start with a staging cluster, enable Hubble, write deny-by-default policies incrementally, and validate every change with connectivity tests. The payoff is lower node CPU overhead, clearer security boundaries, and flow logs that actually explain why a pod cannot reach its database.

Need help designing a production Kubernetes platform or migrating from a legacy CNI? Contact us to discuss architecture, install, and ongoing cluster operations.