eBPF dataplanes and Cilium — modern Kubernetes networking

eBPF and Cilium represent the modern Kubernetes networking stack. This lesson walks eBPF, Cilium’s architecture, the comparison with iptables/IPVS, and the operational discipline.

What is eBPF

flowchart LR
    A[User space] --> B[Application]
    C[Kernel space] --> D[eBPF programs]
    D -->|hooks| E[Network stack]
    D -->|hooks| F[Security]
    D -->|hooks| G[Observability]

eBPF (extended Berkeley Packet Filter) is a Linux kernel technology that allows programs to run sandboxed in the kernel without changing kernel source or loading kernel modules. eBPF programs can hook into:

• Network stack (XDP for ingress, TC for egress).
• Security (LSM hooks).
• Tracing (kprobes, uprobes).
• Observability.

For Kubernetes networking, eBPF replaces iptables and IPVS with programs that run directly in the kernel.

Cilium architecture

flowchart LR
    A["Cilium agent: DaemonSet"] --> B[eBPF programs]
    A --> C["Envoy: L7 proxy"]
    A --> D["Hubble: observability"]
    B -->|hooks| E[Network stack]
    C -->|intercepts| F["HTTP, gRPC, Kafka"]
    D -->|exports| G[Flow logs]
    H[Kubernetes API] -->|config| A

Cilium’s components:

• Cilium agent. DaemonSet running on every node. Manages eBPF programs, talks to the Kubernetes API.
• eBPF programs. Kernel-level programs for routing, NetworkPolicy, kube-proxy replacement.
• Envoy. L7 proxy for HTTP, gRPC, Kafka parsing (optional).
• Hubble. Observability component; exports flow logs.

Cilium can replace kube-proxy (the eBPF kube-proxy replacement) and provides native identity-based NetworkPolicy.

Identity-based security

flowchart LR
    A["Pod with label app: myapp"] --> B["Identity: myapp"]
    C["Pod with label app: db"] --> D["Identity: db"]
    B -->|NetworkPolicy| E{Allow app: myapp → db}
    D -->|Deny| F[Cannot reach]
    E --> G[Allowed]

Identity-based security:

• Each Pod gets an identity based on labels (e.g., app=myapp, tier=frontend).
• NetworkPolicy refers to identities, not IPs.
• Pods can move, restart, get new IPs; the identity follows the labels.

This is more robust than IP-based policies: an IP change does not break the policy.

Hubble observability

hubble observe

TIMESTAMP             SOURCE                    DESTINATION                   TYPE          VERDICT
Aug 16 10:30:00.123   prod-app/myapp-xxxxx       prod-data/db-yyyyy            L4            FORWARDED
Aug 16 10:30:00.456   prod-app/myapp-xxxxx       external/api.example.com      L7/HTTP       FORWARDED
Aug 16 10:30:01.789   prod-app/another-zzzzz     prod-data/db-yyyyy            L4            DENIED

Hubble shows:

• Source and destination (Pod identity, not just IP).
• Layer 4 protocol (TCP, UDP).
• Layer 7 protocol (HTTP, gRPC, Kafka) when Envoy is enabled.
• Verdict (forwarded, denied, error).

This is far more observable than iptables; the operator sees every flow with its identity, not just a packet count.

The comparison with iptables/IPVS

flowchart LR
    A[iptables] --> A1["+ Simple, well-understood"]
    A --> A2[- Linear rule traversal]
    A --> A3[- IP-based selectors]
    A --> A4[- Limited observability]
    B["eBPF/Cilium"] --> B1["+ Fast (no per-rule traversal)"]
    B --> B2[+ Identity-based selectors]
    B --> B3[+ Hubble observability]
    B --> B4[- Requires Linux 5.x+]
    B --> B5[- Steeper learning curve]

The comparison:

iptables/IPVS:

• Pros: Simple, well-understood; works on any Linux version.
• Cons: Linear rule traversal; IP-based selectors; limited observability.

eBPF/Cilium:

• Pros: Fast (no per-rule traversal); identity-based selectors; Hubble observability; L7 visibility with Envoy.
• Cons: Requires Linux 5.x+; steeper learning curve.

The operational trade-offs

flowchart LR
    A[Cilium] --> B[+ Performance at scale]
    A --> C[+ Identity-based security]
    A --> D[+ L7 visibility]
    A --> E[- Requires kernel 5.x+]
    A --> F[- Steeper learning curve]
    A --> G[- Limited support in managed Kubernetes]

The trade-offs:

• Pros. Performance at scale (eBPF is faster than iptables); identity-based security; L7 visibility.
• Cons. Requires Linux 5.x+; steeper learning curve; some managed Kubernetes providers have limited Cilium support.

Quiz

The operational discipline

Cilium in production rests on five non-negotiable elements:

• Verify kernel version. Linux 5.x+ required.
• Install Cilium via Helm or operator. Manual install is error-prone.
• Configure Hubble. Observability is the primary benefit.
• Use identity-based NetworkPolicy. Labels, not IPs.
• Test L7 visibility. Verify Envoy intercepts HTTP, gRPC, Kafka traffic.

Cilium is the modern CNI for advanced networking needs. The discipline is to test in staging before production; the behaviour differs from iptables in subtle ways.