Aflevering 144: Kubernetes Doesn't Build Your Network

We sit down with Simone Rodigari, software engineer in Azure Core Container Networking and one of the maintainers of Retina, the eBPF-based observability project. Simone had just delivered his session on Kubernetes networking, and we asked him to give our listeners the same mental model, the one you need when something breaks and you have no idea where to start tracing.

We start at the ground rules: every pod gets an IP, every pod can reach every other pod. That's the expectation Kubernetes sets, but Kubernetes doesn't implement it, the CNI does. Simone walks us through the pod network namespace, the veth pair that works like a virtual cable, and what actually happens to a packet on its way out of the node.

From there we get into the real trade-offs:

• Overlay (VXLAN, IP-in-IP, Geneve) versus underlay and direct routing with BGP portability versus performance, and why the answer is always "it depends"
• Why pods being ephemeral forces the Service abstraction, and how DNAT and load balancing actually work underneath
• kube-proxy modes iptables, IPVS, nftables and why linear rule traversal hurts at scale while eBPF maps give you constant-time lookups
• Where eBPF has its own limits: map sizes, memory and CPU
• Hubble as a Kubernetes-aware tcpdump, and how Retina brings that same flow visibility to any CNI even Flannel
• Jan's production pain: hitting the Cilium identity ceiling on managed AKS and the hack he needed to work around it

We close on the future: operating clusters at massive scale, AI moving from training to inference, and Simone's warning that the community should solve real problems instead of bending Kubernetes to fit every new one.

🎧 A grounded, practical episode for anyone who has ever stared at a dropped packet and wondered which component to blame.

Stuur ons een bericht.

ACC ICT Specialist in IT-CONTINUÏTEIT
Bedrijfskritische applicaties én data veilig beschikbaar, onafhankelijk van derden, altijd en overal

‍