A Kubernetes Service with ten healthy backend Pods can still send most of the workload to just one or two of them. This often looks like a broken load balancer, but the usual cause is simpler: the Service distributes network connections, while the application sends many requests through each connection.

Consider an HTTP client that opens one TCP connection to a Service and keeps it alive. The first connection is directed to one backend Pod. Every HTTP request subsequently carried over that connection continues to reach the same Pod. Kubernetes does not reconsider the destination for each request inside the established connection.

This distinction matters because one connection may represent very different amounts of work. A short command-line request might create a connection, receive a response, and close it. A reverse proxy, application server, or gRPC client may keep a small pool of connections open for hours and send thousands of requests through them.…