Compare an eBPF-based CNI like Cilium to a traditional iptables-based CNI for a large Kubernetes cluster with thousands of NetworkPolicies. What actually changes at scale?
Quick Answer
iptables-based CNIs evaluate NetworkPolicies as sequential chain rules, so packet-processing cost grows roughly linearly with rule count and every node must hold rules for every policy that could apply to it. Cilium replaces that with eBPF programs attached at the socket/XDP layer that do near-constant-time hash lookups, so policy evaluation stays fast as the policy count grows, at the cost of needing a newer kernel and more careful upgrade/rollback discipline.
Detailed Answer
Traditional CNIs (kube-router, Calico in iptables mode) implement NetworkPolicy by generating iptables/ipset rules and chains. The kernel walks these chains per-packet. With a handful of policies this is fine; with thousands of policies and large clusters, three things degrade: (1) iptables-restore time during scale-out — rule programming becomes a control-plane bottleneck during mass pod churn, (2) per-packet latency grows because chain traversal is not O(1), and (3) debugging is hard because the effective rule set is the product of many overlapping chains.
eBPF-based CNIs like Cilium attach programs directly to the kernel's networking hooks (TC, XDP, socket layer) and represent policy as hash maps and identity-based lookups (Cilium assigns each pod a 'security identity' derived from labels, not just an IP). Policy evaluation becomes a map lookup keyed by identity rather than chain traversal, so it scales much better with policy count and connection rate. eBPF also enables features iptables can't do efficiently: kube-proxy replacement (no more iptables/IPVS for service routing), transparent encryption, and L7-aware policies without a sidecar.
The tradeoffs: eBPF CNIs require a relatively modern kernel (5.x+ recommended for full feature set), upgrades touch live kernel-loaded programs so you need to validate kernel/Cilium version compatibility carefully, and observability tooling (Hubble for Cilium) is a new piece of operational surface to learn. For very large multi-tenant clusters with heavy NetworkPolicy usage and high pod churn, the eBPF model is generally the better fit; for smaller or more conservative environments, the simplicity and maturity of iptables-based CNIs may outweigh the scalability ceiling.
Code Example
# Check current CNI and kube-proxy mode kubectl get pods -n kube-system -o wide | grep -E 'cilium|calico|kube-proxy' # Cilium: inspect eBPF policy maps for a given endpoint cilium endpoint list cilium bpf policy get <endpoint-id> # Hubble: observe live policy decisions (allow/deny) per flow hubble observe --namespace checkout --verdict DENIED # Compare: count of iptables rules under a legacy CNI (the thing eBPF avoids) iptables -t filter -L KUBE-NETWORK-POLICY -n | wc -l
Interview Tip
Anchor the answer on the actual mechanism difference: chain traversal (O(n) in rule count) vs. identity-based hash map lookup (near O(1)). Mention kube-proxy replacement and Hubble observability as concrete operational wins, and be honest about the kernel-version and upgrade-risk tradeoffs — interviewers at this level want to know you'd evaluate the migration cost, not just declare eBPF strictly better.