Whose Packet Is It Anyway? Life of a Packet Through a Service Mesh
summary
Traces a TCP packet through a sidecar mesh and shows exactly how iptables rewrites destination to the proxy (inbound port 4143, outbound 4140) and how the proxy uses getsockopt SO_ORIGINAL_DST to forward to the original IP. Reproduces a Kafka metadata failure by capturing traffic with tcpdump on loopback and on the host virtual interface (capture shows 579 packets); shows use of nsenter, cri-o inspect, kubectl debug/netshoot, Wireshark, and notes TCP telemetry is much weaker than HTTP and proxy TLS encrypts inter-pod traffic.
AI-written summary · about
chapters (5)
- 0:00Start
- 1:55How is a packet routed in a service mesh?
- 3:26What is the sidecar proxy model
- 11:20How does a proxy redirect a packet?
- 29:25Ephemeral containers
related talks
34mIt's Not Always the Network (But Here's How to Prove It): Kubernetes Packet...
26mFrom veth Pairs to Services: The Secret Life of Container Packets
26mNetworking the Service Mesh Proxy: Where We Are, Where We’re Going
53mWhat is eating my traffic? Packet thieves revealed
35mFollowing a packet journey through the networking stack in OpenShift
48mProxies, Gateways, and Service Mesh. Why Are Words so Confusing?
38mPacket Capture the Flag
25mFollow the Packets: DevOps for Network Engineers