How the Game Maps Kubernetes Networking Concepts
Entzmann built a 3D underwater game after finding Kubernetes networking confusing despite two decades in networking and telecoms. Buildings are nodes. Lit rooms are running pods. The fish is the packet. A four-color backpack represents OSI layers: layer 2 for MAC, layer 3 for IP (shown as room numbers), layer 4 for TCP, and layer 7 for the payload. Two-digit numbers are pod IPs, three-digit numbers are service IPs, and four-digit numbers are node or external IPs. A shellfish in each room represents the routing table. Doors are network interfaces.
Pod-to-Pod Routing with Cilium eBPF
The packet leaves the source pod through a veth pair (the corridor) and hits the host interface. An eBPF program attached at that interface reads the layer 3 destination and routes the packet directly. It bypasses the netfilter stack entirely: no iptables, no nftables, no IPVS. The packet jumps straight to the destination container’s interface, enters through a second eBPF program, and traverses the corridor into the target room. The layer 4 port must match the listening process or the packet is dropped.
Service Resolution and Cross-Node VXLAN Tunneling
When the destination is a hostname, the packet first reaches CoreDNS on port 53. An egress network policy (the blowfish) checks the source and permits the DNS query. CoreDNS returns a three-digit service IP. Back at the source pod, another egress policy checks the backend destination, then the eBPF program translates the service IP to a pod IP on a different node. The packet is encapsulated in a VXLAN header, adding new layer 2, 3, and 4 headers. At the far node, decapsulation strips the outer header. An ingress network policy then checks the source before admitting the packet to the backend pod.
Ingress and Sidecar-Based Service Mesh
External traffic targets a four-digit IP on a LoadBalancer-type service. Traditional routing delivers the packet to the node interface, where an eBPF program maps the external IP to the ingress gateway pod, which listens on port 443. Inside the gateway, layer 7 processing reads the hostname and starts the service mesh. A new mTLS packet is created targeting the frontend service. At the destination pod, iptables rules injected by the sidecar redirect traffic to the Envoy proxy on port 15006. Envoy handles observability, tracing, and advanced routing, then forwards the packet over a loopback interface to the application container inside the same pod.
Ambient Mode: ztunnel and Waypoint Processing
Ambient mode removes the per-pod sidecar. The istio-cni DaemonSet installs iptables rules into the application at enrollment time, redirecting traffic to the ztunnel DaemonSet (one pod per node, coded in Rust). ztunnel processes only layer 4: mTLS, observability, and tracing with no layer 7 visibility. When layer 7 processing is configured, ztunnel forwards the packet to a waypoint, which is a Deployment (not a DaemonSet) running Envoy. The waypoint inspects layer 7, applies policies, then returns the packet to ztunnel. The packet arrives at the frontend decrypted, with no sidecar separation inside the pod.
Notable Quotes
I had this idea to develop a 3D games just to explain the basics and go up to more advanced scenario. Benoit Entzmann · ▶ 00:48
but with Ebpf it stopped before is the shortest point at the output of the interface to reach your uh destination. Benoit Entzmann · ▶ 07:35
there is nothing more ungrateful than the packet. It just need a destination. Benoit Entzmann · ▶ 24:52
Z tunnel is not envoy is coded in rust now and it only process the layer four of the packet. Benoit Entzmann · ▶ 27:05
Key Takeaways
- Cilium’s eBPF programs route packets at the interface, skipping the netfilter stack entirely.
- A Kubernetes Service provides a stable IP because pod IPs change on every restart.
- Ambient mode splits layer 4 (ztunnel) and layer 7 (waypoint) processing into separate components, removing the sidecar entirely.
About the Speaker(s)
Benoit Entzmann is a DevSecOps consultant at Feesh in Switzerland with two decades of networking and telecoms experience. He spends his time delivering workshops and presentations and supporting customers through DevOps transformations, with a focus on making complex architecture topics approachable through original formats.