Cilium replaces your iptables rules with JIT-compiled kernel code — and it’s 100× faster

iptables turns 25 in 2026. The packet filter baked into Linux since version 2.4 (January 2001) is still the default data plane for most Kubernetes CNI plugins. The problem isn’t security — it’s the architecture: every packet walks a rule chain sequentially until it hits a match. At 10,000 rules, the cost is O(n) linear. At 50,000 rules, your cluster starts dropping connections.

eBPF fixes this at the root. Instead of inspecting every packet against a list of rules, it injects a sandboxed program straight into the kernel — verified, JIT-compiled to native machine code, executed in constant time via hash tables. The result: 100× the throughput of iptables at equivalent rule volume, as measured by Isovalent in 2025 benchmarks. Cilium, the CNI built on eBPF, has become the most advanced project in the cloud-native networking stack — it replaces kube-proxy, replaces iptables, and adds L7 observability with Hubble and transparent WireGuard encryption.

iptables is 25 years old — and that’s the problem

The iptables model rests on five tables (filter, nat, mangle, raw, security) and predefined chains (INPUT, OUTPUT, FORWARD, PREROUTING, POSTROUTING). Every rule is evaluated in order, and every evaluation walks a linear data structure. When kube-proxy operates in iptables mode, each new Kubernetes Service, each new Endpoint, and each new NetworkPolicy appends more rules to these chains.

The degradation has been documented since 2017:

• Update latency. Adding a single Service in iptables mode can take multiple seconds on a medium-sized cluster, because iptables-restore rewrites the entire ruleset on every change.
• Throughput collapse. Beyond 5,000 rules, sequential traversal becomes visible in connection latency. At 20,000 rules, TCP timeouts begin appearing.
• Fundamental design flaw. Every data-plane packet traverses the ruleset, even when the matching rule is the last one in the chain.

Calico, the long-standing CNI, shared this problem for years — its default mode used iptables for policy enforcement. Calico has since added an eBPF data plane mode, but adoption remains partial and the feature surface trails Cilium’s. Flannel, the ecosystem’s simplest CNI, provides only overlay routing (VXLAN or host-gw) and no NetworkPolicy support whatsoever — it embodies the approach Cilium renders obsolete.

eBPF — the kernel becomes programmable

eBPF began as an extension of the original Berkeley Packet Filter. Where classic BPF (cBPF) was limited to network packet filtering, eBPF can run sandboxed programs at nearly every hook point in the Linux kernel: system calls, kernel functions, network events, tracepoints.

The lifecycle of an eBPF program follows four steps:

1. Compile. Restricted C code is compiled to eBPF bytecode via LLVM.
2. Load. The bytecode is loaded through the bpf() syscall and passes through the verifier — a formal validator that guarantees no infinite loops, no out-of-bounds memory reads, and no unterminated execution paths.
3. JIT. Verified bytecode is compiled on the fly to native x86-64 or ARM64 instructions by the kernel’s JIT compiler.
4. Attach. The program is attached to a chosen hook — XDP (eXpress Data Path) for driver-level packet processing, TC (Traffic Control) for ingress/egress, or a kprobe to intercept a system call.

For networking, the difference from iptables is stark. Where iptables evaluates rules sequentially, an eBPF program uses a hash table — lookup is O(1) constant time regardless of entry count. An eBPF map can hold hundreds of thousands of entries with no measurable degradation.

Cilium — the Swiss Army knife of cloud-native networking

Cilium (v1.19 as of April 2026, maintained by Isovalent — acquired by Cisco in December 2023) is far more than a CNI. It’s a complete networking platform that exploits eBPF at every layer of the stack.

kube-proxy replacement

The single use case that justifies Cilium on its own. kube-proxy in iptables mode maintains a NAT rule table for every Kubernetes Service — adding a Service means rewriting thousands of iptables rules on every node. Cilium fully replaces kube-proxy with an eBPF load balancer that operates at the socket level (connect()), not the packet level. The backend is chosen at connection-establishment time, with no per-packet address rewriting. Result:

# Replace kube-proxy with Cilium — one command
cilium install --kube-proxy-replacement=strict

In strict mode, Cilium handles all ClusterIP, NodePort, ExternalIPs, and LoadBalancer services without a single iptables rule. Isovalent internal benchmarks (2025) show a 90% reduction in new-Service provisioning time on a 100-node cluster.

L7 Network Policies — a firewall that understands HTTP

Native Kubernetes Network Policies filter at L3/L4: source IP, destination IP, port. Cilium extends this to L7 — you can write rules that understand application-layer protocols:

apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata:
  name: "api-http-rules"
spec:
  endpointSelector:
    matchLabels:
      app: api
  ingress:
  - fromEndpoints:
    - matchLabels:
        app: frontend
    toPorts:
    - ports:
      - port: "8080"
        protocol: TCP
      rules:
        http:
        - method: "GET"
          path: "/public/.*"
        - method: "POST"
          path: "/api/v2/.*"
          headers:
          - "Authorization: Bearer .*"

This policy allows the frontend to make GET requests to /public/ and POST requests to /api/v2/ with a Bearer token. Everything else is blocked — not at IP level, not at port level, but by inspecting HTTP content directly in the kernel via eBPF. No Envoy sidecar, no dedicated L7 proxy.

DNS-based policies add another layer: instead of allowing an IP, you allow a FQDN. Cilium intercepts DNS resolution, extracts the returned IP address, and injects it dynamically into the policy — no restart, no recompilation.

Transparent WireGuard encryption

Cilium enables WireGuard encryption between all cluster nodes with a single command:

cilium install --encryption=wireguard

Every inter-pod packet traverses a WireGuard tunnel automatically negotiated between nodes. Keys are managed by Cilium and stored in Kubernetes Secrets. No IPsec configuration, no certificates, no external daemon. For a multi-cloud or bare-metal cluster, this delivers the encryption level regulators demand — without the operational burden.

Cluster Mesh — a single network across datacenters

Cluster Mesh federates multiple Kubernetes clusters into a single logical network. Services in a GCP cluster can directly call pods in an AWS cluster, with the same security identity, the same L7 Network Policies, and the same WireGuard encryption. The whole thing runs on eBPF routing — no external VPN, no inter-cluster load balancer.

Hubble — observability that costs nothing

Hubble is the observability platform built into Cilium. It leverages the same eBPF hooks as the networking data path to expose, with no measurable overhead, the complete service-to-service flow graph:

• Real-time service map. Which pods talk to which pods, over which protocol, at what frequency.
• L7 metrics. HTTP 5xx/4xx codes per service, P95/P99 latency between endpoints, gRPC call volume.
• DNS visibility. Which domains are resolved, by which pods, with which return code.
• Drop reasons. Why a packet was rejected — L3 policy, L7 policy, DNS failure — with the exact label of the blocking rule.

# Observe all HTTP flows between two namespaces
hubble observe --from-namespace frontend --to-namespace backend --protocol http

Where a classic Service Mesh (Istio + Envoy) injects a sidecar proxy per pod — each proxy consuming RAM, CPU, and adding a hop of latency — Hubble instruments the kernel data path directly. The contrast is stark: 300 MB of RAM and 15% of CPU saved per node on a typical production cluster, per Isovalent’s 2024 benchmark.

Cilium vs Calico vs Flannel — the production verdict

Calico remains an excellent choice for deployments that don’t need L7 policies or built-in observability. Its eBPF mode narrows the gap with Cilium, but the maturity and functional coverage aren’t on the same level. Flannel is the choice of maximum simplicity — a lab, a dev cluster, a demo. But the day you need a NetworkPolicy, you migrate.

The verdict — when to switch to Cilium

iptables was never designed for cloud-native workloads. It’s a 2001 firewall stretched to route Kubernetes clusters with thousands of pods. The fact that it still holds up is a tribute to Linux kernel engineering — but it’s also a signal that it’s time to move on.

Switch to Cilium if your cluster exceeds 50 nodes or 5,000 pods, if you need L7 Network Policies, if compliance requires inter-pod encryption, or if you want to see what’s happening on your network without a separate observability budget. The kube-proxy replacement alone justifies the migration.

Stay on Calico if your cluster is smaller, your policies are strictly L3/L4, and you want a battle-tested solution with less configuration surface area.

Stay on Flannel if you’re in prototyping mode and simplicity trumps every other consideration.

eBPF is becoming Linux’s default networking layer — kernel 7.0 (released in March 2026) elevates it to a first-class component with extended hooks for scheduling and storage. Cilium is currently the most complete expression of this revolution. iptables won’t disappear — but using it to route your Kubernetes cluster in 2026 is like running a Formula 1 car on a lawnmower carburetor.

References

• Cilium 1.19 Documentation — Introduction — architecture, features, use cases
• ebpf.io — What is eBPF? — official introduction from the eBPF Foundation
• Cilium — kube-proxy Replacement — benchmark and iptables vs. eBPF comparison
• Cilium — Network Policy — L3-L7 and DNS-based policies
• Cilium — Hubble Observability — service map and metrics
• Cilium — WireGuard Encryption — transparent inter-node encryption
• Cilium — Cluster Mesh — multi-cluster federation
• Cilium GitHub — v1.19 Changelog — version history
• Linux Kernel 7.0 — eBPF enhancements — extended hooks in kernel 7.0