Cilium & Hubble: How eBPF Is Replacing kube-proxy in Modern Kubernetes

Cilium & Hubble: The eBPF-Powered Nervous System of Your Kubernetes Cluster

How modern Kubernetes networking is moving into the kernel — and why it matters for performance, security, and observability.

Introduction

If your Kubernetes cluster is still relying on iptables and kube-proxy, you’re paying a hidden tax — in latency, scalability, and visibility.

Cilium replaces that entire model with eBPF, moving networking, security, and observability directly into the Linux kernel. Paired with Hubble, it gives you real-time insight into every packet flowing through your cluster — without sidecars, instrumentation, or application changes.

This isn’t just an incremental improvement. It’s a fundamental shift in how Kubernetes networking works.

Why Teams Are Switching to Cilium

Performance at Scale

• Eliminates iptables rule traversal
• Kernel-level packet processing reduces latency
• Constant-time lookups even with thousands of services

Built-in Security

• Native L3/L4 policy enforcement
• Identity-aware security (labels instead of IPs)
• No reliance on perimeter-based security

Deep Observability

• Real-time, per-flow visibility via Hubble
• No sidecars or instrumentation required
• Instant insight into drops, retries, and service dependencies

Simplicity & Efficiency

• No kube-proxy required
• Reduced moving parts (no iptables tuning)
• Lower CPU and memory overhead

Future-Proof Architecture

• eBPF is becoming a Linux standard
• Automatically adapts to kernel capabilities
• Aligns with modern cloud-native trends

The Big Picture: How Cilium Works

At a high level, Cilium acts as a programmable data plane powered by eBPF:

• Traffic is intercepted at the Linux kernel level
• Policies and load balancing are applied inline
• Observability data is emitted directly from the kernel

This eliminates the need for iptables-based rule processing and drastically reduces overhead.

Kubernetes Networking (Quick Refresher)

• Container ↔ Container → Same pod (localhost)
• Pod ↔ Pod → Routed via CNI using veth pairs
• Pod ↔ Service → kube-proxy rewrites traffic using iptables
• Ingress/Egress → Load balancers + NAT

This model works — but it doesn’t scale efficiently.

The problem isn’t correctness. It’s that iptables scales linearly, while modern clusters scale exponentially.

Cilium Architecture Explained

1. Cilium Agent (Per Node Brain)

• Runs as a DaemonSet
• Watches Kubernetes API
• Compiles policies into eBPF programs
• Enforces networking rules at packet level

2. Cilium Operator (Cluster Coordinator)

• Handles IPAM and cluster-wide state
• Not in the data path

3. Cilium CNI (Pod On-Ramp)

• Configures networking when pods start/stop
• Attaches eBPF programs to pod interfaces

Hubble: Observability Without Instrumentation

Hubble builds on top of Cilium and provides:

• Real-time flow visibility
• Service-to-service communication mapping
• Drop/forward decisions at packet level

Components

• Hubble Relay → Aggregates data across nodes
• Hubble UI → Visual service graph

Extended Observability Stack

• VictoriaMetrics → Stores time-series metrics from Cilium and Hubble
• Grafana → Visualizes metrics via dashboards and alerts

You get deep observability without sidecars, agents, or code changes.

Why eBPF Changes Everything

Traditional Networking

• Relies on iptables rules
• Requires walking large rule chains
• Adds latency as rules grow

eBPF Approach

• Runs JIT-compiled programs in the kernel
• Executes logic at packet hook points
• Avoids user-space transitions

Mental Model

iptables → "Which rule matches this packet?"
eBPF    → "I already know what to do."

Replacing kube-proxy with Cilium

Cilium can fully replace kube-proxy by handling service routing in eBPF.

Key Differences

• Rule-based vs kernel-native routing
• Linear scaling vs constant-time lookups
• Context switching vs direct execution
• Limited vs per-flow observability

Enable kube-proxy replacement

kubeProxyReplacement: true

⚠️ Requires modern kernels (5.x+) and proper validation in production setups.

Hands-On: Enforcing a Network Policy

Goal

Allow only the checkout service to access payments.

Step 1: Apply Policy

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: allow-checkout-to-payments
  namespace: payments
spec:
  endpointSelector:
    matchLabels:
      app: payments
  ingress:
    - fromEndpoints:
        - matchLabels:
            app: checkout

Step 2: Deploy

kubectl apply -f allow-checkout-to-payments.yaml

Step 3: Observe with Hubble

hubble observe --namespace payments --follow

Example Output

checkout → payments  FORWARDED
frontend → payments  DROPPED

Enforcement happens at the kernel level — and is instantly observable.

Cilium vs Istio: Do You Need Both?

Cilium replaces infrastructure. Istio augments application behavior.

Cilium

• L3/L4 networking and security
• Kernel-native performance
• No sidecars
• Built-in observability

Istio

• L7 traffic management (retries, routing)
• mTLS between services
• Sidecar-based architecture
• Higher overhead

Rule of Thumb

• Use Cilium by default
• Add Istio only if you need advanced L7 features

Final Takeaway

Cilium isn’t just another CNI plugin — it’s a shift in how Kubernetes networking operates:

• User space → Kernel space
  Networking and policy enforcement move into eBPF programs in the kernel

• Static rules → Programmable logic
  The data plane becomes dynamic and adaptable

• Coarse metrics → Per-flow visibility
  Every connection, drop, and retry is observable in real time

• CRDs → etcd at scale
  CRDs work for most clusters; etcd helps at massive scale

---

If Kubernetes was the control plane revolution, eBPF is quietly becoming the data plane revolution.