Kubernetes Service Data Plane

Kubernetes Service Data Plane refers to the collection of node-level mechanisms that actually forward network packets to implement Service abstraction, translating a Service's stable virtual IP and port into traffic delivered to one of its backing pod endpoints. It is distinct from the Service control plane, which merely tracks which pods currently back a Service; the data plane is what performs the real-time packet rewriting and forwarding decisions on every node.

Core Responsibilities

Virtual IP Interception

The data plane is responsible for intercepting traffic addressed to a Service's ClusterIP before it leaves the node (or as it arrives at a node, for externally exposed Services), since ClusterIPs are not assigned to any real network interface and are not independently routable across the underlying network. Interception is typically implemented through packet filtering hooks such as iptables, nftables, IPVS, or eBPF programs attached to kernel networking hooks.

Endpoint Selection

Once traffic destined for a Service is intercepted, the data plane selects one of the Service's current backing endpoints, typically using a randomized or weighted algorithm, and rewrites the packet's destination address and port to that endpoint before forwarding it onward through the normal pod networking path.

Implementation Backends

iptables-Based Data Plane

The iptables backend programs a set of NAT chains per Service, with probability-based jump rules used to approximate load balancing across endpoints. Because iptables evaluates rules sequentially, the cost of a lookup grows with the number of Services and endpoints in the cluster, which becomes a scalability concern in clusters with thousands of Services.

IPVS-Based Data Plane

The IPVS backend uses the Linux kernel's IP Virtual Server subsystem, which maintains hash-table-based lookup structures rather than sequential rule chains. This gives IPVS near-constant-time lookup regardless of Service count, along with support for additional load balancing algorithms such as round robin, least connection, and destination hashing.

eBPF-Based Data Plane

Some CNI implementations replace the traditional kube-proxy data plane entirely with eBPF programs attached directly to network device hooks or socket-level hooks. This approach can perform Service address translation earlier in the packet processing path, in some cases even before a packet reaches the kernel's full networking stack, reducing per-packet latency compared to iptables or IPVS.

Endpoint Tracking

EndpointSlice Synchronization

The data plane's forwarding rules must stay synchronized with the current set of ready pod endpoints for each Service, which are tracked through EndpointSlice objects. Every node's data plane agent watches these objects and reprograms its local forwarding rules whenever endpoints are added, removed, or transition between ready and not-ready states.

Handling Readiness Transitions

When a pod fails its readiness probe, it is removed from the Service's EndpointSlice, and the data plane must promptly stop routing new traffic to it, while typically allowing already-established connections to complete depending on the backend's connection tracking behavior.

Session Affinity

Client IP-Based Affinity

The data plane can be configured to maintain session affinity, ensuring that requests from the same client IP are consistently routed to the same backing pod for a configurable duration. This is implemented differently across backends: iptables uses its built-in recent-connection matching, while IPVS uses its native persistence templates.

External Traffic Handling

NodePort Data Plane Behavior

For Services exposed as NodePort, the data plane must accept traffic arriving on the designated port on every node, regardless of whether that node currently hosts a backing pod, and forward it appropriately, potentially routing it to a pod on a different node entirely through the standard pod networking path.

Source Address Preservation

By default, forwarding external traffic to a pod on a different node requires source network address translation, which replaces the original client IP with the node's IP, a behavior that can be disabled through externalTrafficPolicy settings at the cost of only routing traffic to pods on the node that received it.

Performance and Scaling Characteristics

Rule Set Growth

Regardless of backend, the size and complexity of the data plane's forwarding rule set grows with the number of Services and endpoints in a cluster. Data plane implementation choice materially affects how gracefully this growth is handled, which is why large clusters frequently favor IPVS or eBPF-based backends over the default iptables backend.