Ditching the Sidecar: How to Build Zero-Overhead Service Meshes in Kubernetes Using eBPF | Ecstaticloud Blog

For the last half-decade, the modern Kubernetes service mesh paradigm has been virtually synonymous with the sidecar pattern. Projects like Istio and Linkerd empowered engineering teams with cross-cutting concerns—mTLS encryption, dynamic traffic routing, distributed tracing, and fine-grained access control—without requiring app-level code changes.

They accomplished this by injecting a lightweight proxy container (typically Envoy or Linkerd-proxy) into every single Pod.

While revolutionary at the time, scaling this model to enterprise-grade Kubernetes clusters running thousands of microservices reveals a harsh architectural truth: the sidecar pattern imposes a brutal tax on computational resources, latency budgets, and operational sanity.

In this post, we will unpack why the industry is abandoning sidecars, dive into the kernel internals of eBPF (Extended Berkeley Packet Filter) and Cilium, and construct a production-ready, sidecarless service mesh that operates at kernel speed.

1. The "Sidecar Tax": Quantifying the Overhead

To understand why we need to move past sidecars, we must analyze the path a single HTTP request takes when moving between two pods injected with traditional Envoy sidecars.

Latency Penalties: Double TCP Traversal

In a classic sidecar architecture, a packet doesn't just pass from Pod A to Pod B over the wire. It undergoes a tortuous journey through userspace and kernel boundaries:

[ Pod A App Container ]
        │ (1) Application writes to socket
        ▼
[ Linux Kernel TCP/IP Stack ]
        │ (2) Traverses veth pair
        ▼
[ Pod A Envoy Sidecar (Userspace) ] ── (L7 Processing & mTLS)
        │ (3) Writes encrypted payload back to kernel
        ▼
[ Linux Kernel TCP/IP Stack ]
        │ (4) Host network interface / Wire
        ▼
[ Linux Kernel TCP/IP Stack (Destination Node) ]
        │ (5) Traverses veth pair
        ▼
[ Pod B Envoy Sidecar (Userspace) ] ── (L7 Decryption)
        │ (6) Writes plaintext back to kernel
        ▼
[ Linux Kernel TCP/IP Stack ]
        │ (7) Delivered to socket
        ▼
[ Pod B App Container ]

This journey forces four separate traversals of the Linux TCP/IP stack and multiple context switches between kernel space and userspace for every single intra-cluster hop. At scale, this introduces milliseconds of P99 latency overhead—unacceptable for high-frequency trading, real-time analytics, or microservices topologies with high call-graph depth.

Resource Bloat

Sidecars consume memory and CPU regardless of whether the application container is processing traffic.

Consider a cluster with 1,000 application pods:

Memory footprint: If each Envoy sidecar consumes a conservative 50 MiB of RAM, you are sacrificing 50 GB of memory purely for networking plumbing.
CPU overhead: Allocating 0.1 vCPU per sidecar reserves 100 vCPUs across the cluster.
Cost implication: You are paying thousands of dollars a month to host infrastructure proxies rather than business logic.

Operational Friction

Pod Lifecycle Interference: Sidecars create race conditions during pod startup (e.g., app starts before Envoy is ready) and pod shutdown (e.g., Envoy terminates before app finishes flushing logs).
CVE Management: Upgrading Envoy means rolling out updates or restarting thousands of application pods across the entire cluster.

2. Enter eBPF: The Linux Kernel as a Programmable Engine

eBPF transforms the Linux kernel into a programmable environment. Instead of intercepting packets by forcing them through userspace proxies via iptables and virtual interfaces, eBPF allows developers to attach sandboxed, highly efficient bytecode directly to kernel hooks.

       +-----------------------------------------------+
       |             Userspace Applications            |
       +-----------------------------------------------+
                             │  ▲
       BPF System Calls      │  │ BPF Maps
       (bpf_prog_load, etc.) ▼  │ (Data Sharing)
  =========================== Kernel Boundary ===========================
       +-----------------------------------------------+
       |                   eBPF Engine                 |
       |  +--------------------+  +-----------------+  |
       |  |   JIT Compiler     |  |  BPF Verifier   |  |
       |  +--------------------+  +-----------------+  |
       +-----------------------------------------------+
          │                  │                  │
    Tracepoints /        tc (Traffic       Socket Layer
      kprobes            Control)        (sockmap / sk_msg)

By hooking into kernel sub-systems like Traffic Control (tc), Socket Operations (sock_ops), and socket messages (sk_msg), eBPF enables us to implement service mesh features directly within kernel space.

Short-Circuiting the Stack: `sockmap` Redirection

When two pods on the same host communicate, eBPF can completely bypass the standard TCP/IP network stack using a technique called sockmap redirection.

[ Application A Socket ]                                [ Application B Socket ]
         │                                                         ▲
         │ (1) write()                                             │ (3) read()
         ▼                                                         │
+----------------------------------------------------------------------+
|  eBPF Program (sk_msg Hook)                                          |
|  Directly maps App A's write buffer -> App B's socket receive queue  |
+----------------------------------------------------------------------+
                         Linux Kernel Space

When Pod A calls write() on its socket, the eBPF sk_msg program hooks the operation, looks up the destination socket in an eBPF sockmap table, and pastes the payload directly into Pod B's socket ingress queue.

Zero TCP/IP stack overhead. Zero veth pair traversals. Zero userspace context switches.

3. Architecture of a Sidecarless Mesh with Cilium

Cilium leverages eBPF to create a unified, sidecarless service mesh. It addresses networking, security, and observability at distinct levels of the OSI model:

+-----------------------------------------------------------------------+
|                         Cilium Service Mesh                           |
+-----------------------------------------------------------------------+
|  L7 Processing  | Per-Node Envoy Instance (Shared across host pods)   |
|  (HTTP/gRPC/WAF)| *Invoked ONLY when explicit L7 parsing is required*   |
+-----------------------------------------------------------------------+
|  L3 / L4 Mesh   | Pure eBPF Kernel Execution                          |
|  (Routing/mTLS) | *IPsec/WireGuard, identity-based ACLs, load balancing|
+-----------------------------------------------------------------------+

L3/L4 Traffic Routing & Load Balancing: Completely handled in the kernel via eBPF. Fully replaces kube-proxy.
mTLS & Auth: Handled at the host level via eBPF-driven WireGuard or IPsec transparent encryption combined with SPIFFE/SPIRE identities.
L7 Protocol Parsing (HTTP, gRPC, Tracing): When deep L7 inspection or header manipulation is strictly required, Cilium routes traffic to a single, shared Per-Node Envoy proxy instance rather than injecting an Envoy instance into every Pod.

This hybrid model scales the proxy footprint from $O(\text{Pods})$ down to $O(\text{Nodes})$.

4. Hands-On: Deploying a Sidecarless Service Mesh

Let's build a sidecarless service mesh on a Kubernetes cluster using Cilium with native eBPF host routing, eBPF-based service mesh features, WireGuard encryption, and Hubble observability.

Step 1: Install Cilium with eBPF Service Mesh Enabled

We will deploy Cilium using Helm, explicitly enabling standard kubeProxyReplacement, Hubble observability, L7 proxy support via the node-level architecture, and host-to-host transparent encryption.

Create a file named cilium-values.yaml:

# cilium-values.yaml
kubeProxyReplacement: "true"

# Enable Cilium Service Mesh features (Node-level Envoy for L7)
ingressController:
  enabled: true
  default: true

l7Proxy: true

# Enable Transparent Network Encryption via WireGuard
encryption:
  enabled: true
  type: wireguard

# Enable Hubble for eBPF-powered Observability
hubble:
  enabled: true
  ui:
    enabled: true
  relay:
    enabled: true
  metrics:
    enabled:
      - dns
      - drop
      - tcp
      - flow
      - icmp
      - http

# Optimize Routing via eBPF Direct Routing
tunnelPort: 8472
routingMode: "native"
autoDirectNodeRoutes: true
ipv4NativeRoutingCIDR: "10.244.0.0/16"

Apply the configuration via Helm:

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

helm upgrade --install cilium cilium/cilium \
  --version 1.15.1 \
  --namespace kube-system \
  -f cilium-values.yaml

Verify that Cilium has completely taken over network management and eBPF mode is operational:

cilium status --wait

Step 2: Defining Zero-Trust L7 Security Policies

With a sidecarless approach, security policies are declared using Kubernetes Custom Resource Definitions (CiliumNetworkPolicy) and enforced inside the kernel by eBPF programs, with offloading to the node proxy only when dynamic HTTP payload filtering is required.

Below is an enterprise policy that enforces identity-based L3/L4 filtering and precise L7 HTTP path restrictions:

apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata:
  name: secure-payment-service
  namespace: production
spec:
  endpointSelector:
    matchLabels:
      app: payment-service
  ingress:
  # Allow traffic only from Checkout service
  - fromEndpoints:
    - matchLabels:
        app: checkout-service
    toPorts:
    - ports:
      - port: "8080"
        protocol: TCP
      # Deep L7 Enforcement executed via eBPF + Node-level Envoy
      rules:
        http:
        - method: "POST"
          path: "/api/v1/charge"
        - method: "GET"
          path: "/healthz"
  egress:
  # Block all external communications except cluster DNS
  - toEndpoints:
    - matchLabels:
        k8s:io.kubernetes.pod.namespace: kube-system
        k8s-app: kube-dns
    toPorts:
    - ports:
      - port: "53"
        protocol: UDP
      rules:
        dns:
        - matchPattern: "*"

Step 3: Kernel-Level Observability via Hubble

Because eBPF operates within the kernel, we obtain total visibility into all TCP/UDP connections and L7 HTTP request parameters without installing APM agents or sidecar tracing headers.

Use the hubble CLI to inspect live traffic flows across the cluster in real-time:

# Monitor live L7 traffic flows for the payment-service
hubble observe --namespace production \
  --pod payment-service \
  --protocol http \
  --follow

Example Output:

TIMESTAMP             SOURCE                          DESTINATION                     TYPE          VERDICT   SUMMARY
May 12 10:14:02.102   production/checkout-6f...:4210  production/payment-89...:8080   to-endpoint   FORWARDED HTTP/1.1 POST /api/v1/charge
May 12 10:14:02.145   production/analytics-1a...:5512 production/payment-89...:8080   to-endpoint   DROPPED   Policy denied (L3/L4)

Notice that dropped requests are dropped directly at the kernel layer using BPF drop hooks before they consume CPU context switches or allocate socket memory buffers inside the target container.

5. Performance Benchmarks: Sidecar vs. eBPF (Cilium)

To quantify the real-world performance advantage of dropping sidecars, we executed synthetic stress tests (using wrk2) across two identical 100-node EKS clusters running a microservices topology.

Benchmark Setup

Cluster Size: 100 Nodes (c6i.2xlarge)
Workload: 2,000 Microservice Pods
Traffic Pattern: 50,000 req/sec cluster-wide throughput

Results

6. Architectural Trade-Offs: When Do You Still Need Sidecars?

While eBPF-based service meshes represent the future of Kubernetes networking, software engineering is always a game of trade-offs.

                  Which Service Mesh Architecture Fits Your Needs?
                                         │
                         Is strict per-pod blast radius or 
                         legacy multi-tenant isolation required?
                                         │
                        ┌────────────────┴────────────────┐
                        │                                 │
                       YES                                NO
                        │                                 │
                        ▼                                 ▼
         [ Traditional Sidecar Mesh ]            [ eBPF / Cilium Mesh ]
         - Hard multi-tenancy                    - Maximum performance
         - Custom Envoy filters (Lua/Wasm)       - Minimal memory/CPU tax
         - Per-pod fault isolation               - Unified observability

Advantages of Per-Node / Kernel eBPF Architectures:

Radical Efficiency: Massively reduces memory/CPU allocation.
Kernel Speed: Bypasses TCP stack traversals via sockmap.
Zero Lifecycle Pain: Pods launch instantly without sidecar initialization delays.

Where Traditional Sidecars Might Still Persist:

Hard Multi-Tenancy Security Boundaries: If a node-level proxy crashes, all pods relying on L7 processing on that specific node lose L7 routing capability temporarily. In sidecars, an Envoy crash affects only its immediate pod container.
Complex Custom Wasm/Lua Envoy Filters: Highly customized, proprietary Envoy Extension Filter chains tied to application pods may prove easier to ship as an injected sidecar container if enterprise platform teams maintain localized configurations.

Conclusion: The Post-Sidecar Era

The sidecar pattern was an indispensable transitional technology, enabling cloud-native engineering teams to decouple application code from network enforcement. However, kernel-level innovations driven by eBPF have rendered the per-pod sidecar obsolete for modern, high-scale Kubernetes deployments.

By moving networking, telemetry, and security policies down into the Linux kernel using Cilium and eBPF, organizations can eliminate latency bottlenecks, reclaim gigabytes of wasted memory, and implement true Zero-Trust security without modifying a single application deployment manifest.

The future of Kubernetes networking is not in userspace—it's in the kernel.