This is Level 8 of our Kubernetes networking series, and it's where we finally go inside the Service dataplane.
Back in Level 3, we learned that a client Pod talks to a Service's ClusterIP, which somehow routes traffic to a backend Pod: We deliberately left one question unanswered until now: how does traffic sent to that Service IP actually end up at a real Pod?
That's exactly what this article unpacks.
Table of Contents The Problem: A Service IP Isn't a Real Interface The Basic Idea: A Service Dataplane What Is kube-proxy? kube-proxy's Job kube-proxy Doesn't Create Pods kube-proxy Runs on Every Node The Classic Mental Model: iptables and DNAT What Is DNAT?
Tracing the Packet Journey The Full Picture: DNS to Pod iptables in Kubernetes Control Plane vs Dataplane Why EndpointSlices Matter Here Load Balancing Across Endpoints Session Affinity The Scaling Problem with iptables IPVS: IP Virtual Server iptables vs IPVS An Important Modern Nuance eBPF Enters the Picture Why eBPF Is Interesting for Kubernetes Cilium and eBPF eBPF Can Replace Parts of kube-proxy Don't Confuse kube-proxy Replacement with CNI Three Generations to Remember What kube-proxy Actually Watches Why Services Survive Pod Churn Where CNI Fits Into All of This Service vs CNI vs kube-proxy: A Reference Table Following One Complete Packet What Is SNAT?
Why SNAT Is Needed DNAT vs SNAT Why Return Traffic Works NodePort, Revisited LoadBalancer, Revisited A Layered Troubleshooting Model A Production Troubleshooting Tree What to Inspect on a Node How Do I Know Which Dataplane I'm Using?
The Most Important Conceptual Separation Interview Questions Level 8 Mental Model What's Next: Kubernetes Networking Internals The Problem: A Service IP Isn't a Real Interface Suppose we have a Pod at , and a Service named with ClusterIP , backed by three Pods: The frontend runs .
DNS resolves , so the outgoing packet looks like: Here's the strange part: usually isn't a real, physical network interface attached to any Pod.
So who transforms into something like ?
That transformation is the job of the Service dataplane — and that's exactly what this article is about.
The Basic Idea: A Service Dataplane Historically, Kubernetes clusters implemented this using kube-proxy.
Modern clusters can implement it very differently.
The core concepts we need to understand across this article are: kube-proxy, iptables, IPVS, and eBPF.
What Is kube-proxy?
Despite its name, kube-proxy isn't simply a traditional HTTP proxy — that's a genuinely useful interview point to remember. kube-proxy is a component that helps implement Kubernetes Service networking on each Node: It watches Kubernetes objects — specifically Services and EndpointSlices — and programs the Node's networking rules/dataplane to match what it observes. kube-proxy's Job Given a Service at with EndpointSlice entries pointing to , , and , kube-proxy's conceptual job is simple: "When traffic arrives for this Service IP and port, send it to one of these backend endpoints." kube-proxy Doesn't Create Pods Another important distinction worth locking in: Three genuinely different responsibilities, each handled by a different component. kube-proxy Runs on Every Node kube-proxy typically runs as a DaemonSet, so every Node gets its own instance: Each Node needs the ability to handle Service traffic that arrives locally.
The Classic Mental Model: iptables and DNAT Historically, kube-proxy commonly programmed iptables rules to do this work: The key term here is DNAT.
What Is DNAT?
DNAT = Destination Network Address Translation.
Suppose a packet starts out as: The Service dataplane can rewrite the destination: So — that transformation is destination NAT in action.
Tracing the Packet Journey Let's slow this down and walk through it explicitly.
Frontend: — Service: — Backend: The frontend sends a packet: , .
The Node's Service dataplane recognizes and selects a backend, say .
The packet effectively becomes: , .
From here, normal Pod networking (CNI, covered in Level 7) takes over and delivers it.
The Full Picture: DNS to Pod Connecting this back to Level 4: Or, with concrete values: iptables in Kubernetes Linux has a built-in packet-filtering and NAT framework called iptables.
Kubernetes can program iptables rules so that Service traffic gets redirected to the correct backend endpoint: Conceptually, given a Service at with endpoints , , and , the Node might carry rules that resemble: "traffic to → choose an endpoint → DNAT to one of the three addresses above." Real Kubernetes iptables rule sets are considerably more complex than this simplification — don't worry about memorizing actual chain names yet.
Control Plane vs Dataplane It helps to think of Kubernetes networking in two layers: Control plane decides what should happen: which Pods exist, which Services exist, which endpoints belong to a Service.
Dataplane actually handles packets.
Why EndpointSlices Matter Here Recall from Level 3: a Service like has an associated EndpointSlice listing its live backend IPs.
The Service dataplane depends directly on this information: Without accurate, up-to-date EndpointSlice data, the dataplane has nothing correct to forward traffic to.
Load Balancing Across Endpoints Given a Service with three backend Pods, a connection to the Service might land on any one of them: The exact algorithm and distribution behavior depends on the dataplane implementation and configuration.
The key idea to hold onto: the Service is a stable front door, while the dataplane is what actually selects a backend endpoint for each connection.
Session Affinity Kubernetes Services can optionally enable session affinity, e.g.: With this enabled, the same client tends to keep landing on the same backend Pod: Again, the precise implementation details depend on which dataplane your cluster is running.
The Scaling Problem with iptables The classic flow works well for many clusters.
But there's a scaling consideration: compare 10 Services with 100 total endpoints to 10,000 Services with 100,000 total endpoints.
The volume of networking rules involved can grow enormous.
This is exactly the pressure that led to IPVS, and eventually to eBPF.
IPVS: IP Virtual Server IPVS stands for IP Virtual Server — a Linux kernel technology purpose-built for high-performance load balancing: Instead of thinking in terms of a long chain of packet-filter rules, think of IPVS as a kernel-level virtual server / load-balancing mechanism purpose-built for exactly this job. iptables vs IPVS Simplified comparison: iptables: IPVS: IPVS can offer more specialized load-balancing behavior, and historically was attractive for clusters with large numbers of Services thanks to its performance characteristics.
That said, modern Kubernetes networking has moved beyond simply choosing between these two — eBPF-based dataplanes are increasingly significant.
An Important Modern Nuance You may hear the claim: "IPVS is always faster than iptables." Don't treat that as an absolute rule.
Real-world performance depends on cluster size, traffic patterns, kernel version, configuration, the specific dataplane implementation, and even the underlying hardware.
The important conceptual difference to remember is simpler: eBPF Enters the Picture Now we reach a genuinely important modern technology: eBPF.
You don't need to master every detail yet — at a high level: eBPF = programmable logic that can run inside the Linux kernel.
This lets networking systems perform operations directly in the kernel, rather than bouncing through separate userspace components or long rule chains.
Why eBPF Is Interesting for Kubernetes The traditional path looks like: An eBPF-based networking implementation can inject custom packet-processing logic straight into the kernel: This can avoid some of the overhead inherent in traditional networking paths and enables much more flexible dataplane behavior.
Cilium and eBPF Cilium is one of the best-known Kubernetes networking implementations built on eBPF: Th