~/dataplane-visualizer

cat about.md

about this page

A side-by-side look at what actually changes when you swap a Kubernetes cluster's dataplane — the same LoadBalancer Service pushed through GKE's legacy path (kube-proxy programming iptables) and Dataplane V2 (managed Cilium, in eBPF), traced layer by layer.

Everything here is real

Every output block is a verbatim capture from a live GKE cluster in us-central1 — nothing is mocked or hand-written. The two sides were captured on the same cluster configuration (same version, release channel, machine type, and zone); the only variable is the dataplane. That single-variable setup is the whole point: any difference you see is attributable to the dataplane and nothing else.

A capture script deploys an identical workload — three nginx replicas behind a LoadBalancer Service — to whichever dataplane is active, auto-detects V1 vs V2, and records a trace at each layer. It runs the same way on both, so the comparison is genuinely apples-to-apples.

How to read it

Managed, not hand-built

On GKE, Dataplane V2 is managed Cilium: you get the datapath and its introspection tools (cilium-dbg, Hubble), but Google curates the surface — there's no CiliumNetworkPolicy CRD, so you write standard Kubernetes NetworkPolicy, and Hubble is leaner than on a self-managed cluster. Where that boundary shows up, the page calls it out. Knowing where the line falls between "the cloud manages this" and "you build this yourself" is half the reason the comparison exists.

back to the comparison