Packets in the Mesh

• The Kubernetes service data plane and the two costs that matter: data path and sync.
• How iptables expresses services as rule chains, and why both costs grow O(n).
• How eBPF (Cilium) uses hash-map lookups at kernel hooks to keep costs flat.
• A measured iptables sync-time curve, plus a cited comparison with IPVS and eBPF.
• A workload-driven framework for choosing a data plane, with four worked clusters.
• A protocol for measuring your own cluster, and full references.

1. Preface

   Preface

   Sets up the book's narrow comparison of the three production Kubernetes service data planes (iptables, IPVS, eBPF/Cilium), states its audience, and is explicit about which figures in the book are measured directly versus cited from external sources.

2. Chapter 1

   The Service-Routing Problem

   Frames how a Kubernetes Service's ClusterIP is translated to a live pod endpoint on every packet, defines data-path cost and sync cost as the two costs that must scale with cluster size, and previews how iptables, IPVS, and eBPF each answer the problem.

3. Chapter 2

   Inside the iptables Data Plane

   Traces how kube-proxy's iptables mode turns each Service into netfilter rule chains and DNAT, and explains why both the per-packet lookup and the full-table sync via iptables-restore are linear in the number of services, plus the shared conntrack bottleneck.

4. Chapter 3

   Inside the eBPF Data Plane

   Explains how Cilium attaches eBPF programs to kernel hooks that resolve services via an O(1) BPF hash-map lookup instead of a rule chain, keeping both data-path and sync costs flat, and notes extra capabilities like direct server return.

5. Chapter 4

   The Measured Comparison

   Reports the harness's directly measured iptables-restore sync times across 100 to 10,000 services and places them alongside cited IPVS and eBPF figures in a single comparison table, marking clearly which cells are measured versus cited.

6. Chapter 5

   Choosing a Data Plane

   Converts the cost comparison into an ordered decision framework built around cluster scale/churn, kernel availability, and operational maturity, then applies it to four representative cluster scenarios.

7. Chapter 6

   Conclusion: Measure Your Own Cluster

   Recaps that data planes should be chosen by how their costs grow rather than raw speed, and lays out a five-step protocol for measuring sync time and tail latency on the reader's own cluster.

• Platform or SRE engineers who operate Kubernetes clusters
• Engineers choosing a CNI for their cluster
• Engineers debugging slow service/endpoint updates
• Readers who want to reason about which service data plane keeps up as a cluster's size and change rate grow
• Anyone comparing kube-proxy (iptables/IPVS) against Cilium's eBPF kube-proxy replacement

The preface says familiarity with Linux networking basics and with big-O reasoning is enough; where kernel mechanism is needed, the book builds it up from first principles.

The bench/ harness builds a Kubernetes-style nat table with 3 DNAT rules per service for service counts from 100 to 10,000, and times how long iptables-restore (nf_tables backend) takes to install that table atomically - the same operation kube-proxy performs on every sync - on an AMD Ryzen 7 5700X inside a privileged Alpine Docker container. This iptables sync curve is the only figure measured directly; the IPVS and eBPF (Cilium) numbers are cited from the projects' own documentation and published sources, because the IPVS kernel module is absent from Docker Desktop's WSL2 kernel and eBPF service routing needs a real multi-node cluster. The appendix provides a kind+Cilium recipe (installing Cilium in kube-proxy-replacement mode) so readers can reproduce the full three-way comparison themselves, and notes the measured iptables curve is a lower bound since production kube-proxy emits more rules per service and reloads the whole table on every change.

A Kubernetes Service is a stable virtual address for a shifting set of pods. Something must translate that address into a real endpoint on every packet, and keep doing so as pods come and go. That something is the service data plane, and this book is about how it is built.