eBPF Observability

What eBPF Changes

 eBPF: sandboxed programs running IN THE KERNEL, attached to
 network/socket/trace points — no packet redirection needed:

 traditional sidecar path:
   app → iptables redirect → proxy (user-space) → net → peer

 eBPF path:
   app → kernel socket ops → net → peer
              │
        eBPF programs observe/enrich at kernel level

 cilium-class platforms use this for mesh-ish behavior;
 standalone eBPF agents (pixie, tetragon-class) use it for
 DEEP OBSERVABILITY without touching traffic paths.

What Kernel-Level Visibility Reveals

 observability BELOW the service layer:

 □ EVERY connection on the node — including ones meshes miss:
     app→database, app→cache, cron→anything, localhost oddities
 □ process-level attribution: WHICH binary/pod made each flow,
   with L7 parsing (http/sql/redis protocols decoded in-kernel)
 □ RED latency analysis: syscalls, scheduler delays, softirq —
   where did the 200ms actually GO inside the node?
 □ zero-instrumentation onboarding: deploy agent, get maps
   of services nobody remembered existed ✓ (discovery by truth)
 
 [eBPF agent]──sees──► http flows + sql calls + tcp anomalies
              per-process, per-pod, continuously

The Complementarity Table

Capability	eBPF	Sidecar/mesh
east-west HTTP metrics	✓ (parsed in kernel)	✓ native
mTLS enforcement	limited/emerging	core strength
L7 routing policy (canary weights)	partial	core strength
non-HTTP visibility (sql/redis/dns)	strong	weak/none
app-internal spans/GC/business	✗	✗
per-hop resource cost	low (kernel)	proxy CPU/RAM/tail

 read the table honestly:
 eBPF excels at SEEING EVERYTHING cheaply;
 sidecars excel at CONTROLLING traffic richly.
 they answer different verbs: observe vs enforce.

Where Fleets Combine Them

 observed production patterns:

 1. eBPF for BASELINE discovery + database/cache visibility;
    mesh for policy/mTLS between SERVICES only.
    ("see everything; steer service-to-service")

 2. eBPF-based dataplane replacing sidecars entirely
    (cilium service-mesh mode) — L4 fast-path in kernel,
    envoy invoked only when L7 policy demands it:
      kernel handles plain forwarding; user-space L7 opt-in.

 3. eBPF purely for security observability (syscall auditing)
    alongside ANY networking choice.

 decision inputs: protocol diversity, enforcement needs,
 kernel versions on nodes (eBPF features are kernel-gated!),
 and team appetite for a younger operational stack.

Interview Framing

“Half our traffic is SQL and Redis — the mesh sees none of it” scored shape: validate the blind-spot complaint precisely, present eBPF’s kernel-level protocol visibility as the complement, combination patterns offered (baseline+mesh or eBPF-dataplane), kernel-version gating caveat named. This topic rewards honest scoping: eBPF is a lens and an emerging dataplane, not a mature replacement for every mesh feature — say which parts are which.