What is a service mesh

• Service Mesh adds ‘intelligence’ without the rework. You can extend an applicatoin with authentication, encryption, load-balancing, observability, canary and blue/green deployment etc. without modifying the application.

Cilium Service Mesh vs. Others

• Normally with a service mesh, a sidecar proxy container is used to facilitate traffic
• Cilium instead enforces L3/L4 traffic in the kernel via eBPF, with no per-pod proxy container required

Sidecar-Based Routing (e.g. Istio)

flowchart LR
    subgraph NodeA["Node 1"]
        subgraph PodA["Pod A"]
            AppA[App Container]
            SidecarA[Envoy Sidecar]
            AppA <-->|"localhost, redirected by iptables/iptables-nft"| SidecarA
        end
    end
    subgraph NodeB["Node 2"]
        subgraph PodB["Pod B"]
            SidecarB[Envoy Sidecar]
            AppB[App Container]
            SidecarB <-->|"localhost, redirected by iptables/iptables-nft"| AppB
        end
    end
    SidecarA -->|mTLS over the network| SidecarB

• Every pod carries its own proxy container; all ingress/egress is intercepted and routed through it
• Adds a container (memory/CPU) and a network hop per pod, plus startup-ordering races between app and sidecar

eBPF-Based Routing (Cilium, Sidecarless)

flowchart LR
    subgraph NodeA["Node 1"]
        AppA["App Container (Pod A)"]
        eBPFA{{"eBPF Datapath (socket/tc hooks)"}}
        AppA --> eBPFA
    end
    subgraph NodeB["Node 2"]
        eBPFB{{"eBPF Datapath (socket/tc hooks)"}}
        AppB["App Container (Pod B)"]
        eBPFB --> AppB
    end
    eBPFA -->|"L3/L4 routed + policy enforced in-kernel, no proxy hop"| eBPFB

• No sidecar container; the kernel’s eBPF programs enforce identity-based policy and route the packet directly
• Removes the extra container and the localhost proxy hop, at the cost of needing eBPF/kernel support

Envoy + Cilium for Layer 7 Traffic

• eBPF alone can’t parse L7 protocols (HTTP, gRPC, Kafka, etc.); it only sees up through L4
• When an L7 policy or L7 visibility requirement exists, Cilium’s eBPF datapath redirects just that traffic to a single Envoy proxy (one per node, not one per pod), which handles the L7 parsing/enforcement, then hands the traffic back to the eBPF datapath

flowchart LR
    App["App Container"] -->|socket syscall| Check{{"eBPF: policy check"}}
    Check -->|"L3/L4 policy only"| Dest["Destination Pod (via eBPF datapath)"]
    Check -->|"L7 policy or visibility needed"| Envoy["Per-Node Envoy Proxy"]
    Envoy -->|"HTTP/gRPC/Kafka parsing + L7 rules"| Reinject{{"eBPF: re-inject packet"}}
    Reinject --> Dest

• Only traffic that actually needs L7 handling takes the Envoy detour; everything else stays on the fast, in-kernel eBPF path
• Because Envoy is shared per-node (not per-pod), this avoids the N-sidecars-per-node resource cost of the sidecar model while still supporting full L7 features