Understanding Traffic Flow from Pod to Service and Back in Kubernetes and Handling Long‑Lived Connections

This article will introduce two main topics: how traffic flows from a pod to a Service and back to another pod in Kubernetes, and how long‑lived connections are handled.

From pod to service and back

First, a multi‑replica Deployment is created; Kubernetes assigns each pod a cluster‑wide reachable IP address via the CNI.

Next, a service of type ClusterIP is created, pointing to the Deployment (i.e., all its pods). The Service receives a virtual IP (VIP).

When another pod sends a request to the Service’s virtual IP or its internal CoreDNS name, the Service randomly forwards the request to one of the backend pods, completing the pod‑to‑pod connection.

However, the Service itself does not forward traffic; it is merely a configuration object. The actual forwarding is performed by kube-proxy running on each node, which watches all Services and programs either iptables (default) or ipvs (controlled by the --proxy-mode flag) to handle the traffic.

iptables and long‑lived connections

iptables is a Linux utility for configuring network rules, used by Kubernetes for L4 TCP/UDP forwarding. It supports both random (probability‑based) and nth (round‑robin) forwarding strategies, but Kubernetes fixes the strategy to random and does not allow configuration.

For long‑lived connections such as HTTP/1.1 keep‑alive, HTTP/2, gRPC, or WebSocket, iptables selects a target pod only when the TCP connection is first created; thereafter, the kernel’s connection‑tracking mechanism keeps the flow bound to that pod, so long‑lived connections are supported in Kubernetes.

Nevertheless, this can cause load imbalance: a particular pod may receive all long‑lived connections while other pods remain idle.

To mitigate imbalance, two common approaches are used: (1) client‑side load balancing, where the client obtains the IPs of pods behind the Service and implements its own balancing logic (increasing client complexity), and (2) introducing an intermediate layer such as a service mesh, which handles traffic distribution.

Reference material:

https://learnk8s.io/kubernetes-long-lived-connections

https://scalingo.com/blog/iptables

https://learnk8s.io/kubernetes-network-packets