4.3 Kube-Proxy Service Dataplane: iptables, nftables, IPVS & eBPF

4.3 Kube-Proxy Service Dataplane: iptables, nftables, IPVS & eBPF

A Kubernetes Service provides a stable virtual address while backend Pod IPs change. On each node, kube-proxy watches Service and EndpointSlice objects and reconciles operating-system rules that capture Service traffic and redirect it to an eligible endpoint. Some networking systems replace kube-proxy with their own dataplane, but the API objects remain the source of desired state.

1. Packet Flow and Source Objects

Client packet to Service ClusterIP:port
  -> node-local Service dataplane rule
  -> select an eligible EndpointSlice endpoint
  -> destination NAT to PodIP:targetPort
  -> CNI routes packet to the backend Pod
  -> connection tracking handles return traffic

If a Service has no usable endpoints, changing proxy mode will not repair it. First verify selectors, EndpointSlices, readiness, ports, and address families:

kubectl get svc api -o yaml
kubectl get endpointslice -l kubernetes.io/service-name=api -o wide
kubectl get pods -l app=api -o wide

2. Linux kube-proxy Modes in Kubernetes v1.35

iptables

In iptables mode, kube-proxy creates Netfilter chains for Services and endpoint selection. Do not rely on the old claim that every endpoint change always rebuilds every rule: since Kubernetes v1.28, iptables mode makes more targeted updates. It remains widely deployed and supported.

Useful inspection commands include:

sudo iptables-save | grep -E 'KUBE-SVC|KUBE-SEP' | head
kubectl logs -n kube-system daemonset/kube-proxy --tail=100

nftables

The nftables mode is stable and designed as the successor to both iptables and IPVS for Linux nodes. Kubernetes v1.35 documentation requires kernel 5.13 or later. nftables uses native sets and maps, which scale and synchronize efficiently for large Service and endpoint inventories.

A kubeadm-managed cluster normally stores mode configuration in the kube-proxy ConfigMap:

apiVersion: kubeproxy.config.k8s.io/v1alpha1
kind: KubeProxyConfiguration
mode: nftables

Before migration, confirm kernel support and compatibility with the installed CNI, firewall, observability tools, and NodePort assumptions. Restart the kube-proxy DaemonSet only after saving and validating configuration:

kubectl -n kube-system get configmap kube-proxy -o yaml
kubectl -n kube-system rollout restart daemonset kube-proxy
kubectl -n kube-system rollout status daemonset kube-proxy
sudo nft list ruleset | less

The nftables mode intentionally differs from some legacy iptables defaults. For example, NodePorts are not reachable through loopback by default. Treat migration as an operational change, not a cosmetic flag edit.

IPVS: Deprecated, Not Removed

IPVS uses Linux Virtual Server plus supporting iptables behavior. In Kubernetes v1.35 the mode is deprecated because its kernel API cannot correctly express every Kubernetes Service edge case and its maintenance cost is high. Existing clusters can still run it, but kube-proxy emits a deprecation warning. New designs should prefer nftables where prerequisites are met.

IPVS requires host kernel modules such as ip_vs, an appropriate scheduler module, and connection tracking support. Current kube-proxy documentation says it exits with an error if configured for IPVS and the necessary modules are unavailable; it does not promise a silent fallback to iptables.

lsmod | grep -E '^ip_vs|nf_conntrack'
sudo ipvsadm -Ln
kubectl -n kube-system logs daemonset/kube-proxy | grep -iE 'mode|ipvs|deprecated|error'

3. eBPF Replacements

Projects such as Cilium can implement Service translation and load balancing with eBPF and may run without kube-proxy. This is a replacement architecture, not mode: ebpf in KubeProxyConfiguration. Diagnose it with the implementation's own agents and status tools as well as standard Kubernetes Service and EndpointSlice objects.

4. Mode-Aware Troubleshooting

1. Desired state: Does the Service select the intended ready Pods, and do EndpointSlices contain the right IP and port?
2. Controller state: Is the kube-proxy DaemonSet Ready on every relevant node, or is an alternative dataplane healthy?
3. Configured mode: Read the live ConfigMap and logs; do not infer mode from installed command names.
4. Kernel prerequisites: Check nftables kernel version/support or IPVS modules.
5. Rules and counters: Inspect iptables-save, nft list ruleset, or ipvsadm -Ln according to the configured mode.
6. CNI routing: If destination NAT occurs but traffic still fails, inspect Pod routes, MTU, NetworkPolicy, and return-path connectivity.

A correct CKA diagnosis moves from API objects to the selected node dataplane and then to CNI routing, rather than switching proxy modes before locating the broken layer.