Kubernetes 负载均衡现象解析：为何同一批次请求集中于单个 Pod

背景

《在 Windows 上使用 Kind 创建本地 Kubernetes 集群并集成Traefik 进行负载均衡》在这篇文章中，通过这个命令验证负载均衡。

bash 复制代码

 1..10 | ForEach-Object {
   curl.exe http://hello.local
}

实际的情况是：

比如，我第一次执行这个命令，所有的请求全部打到pod1中，过一会再执行这个命令，所有的请求全部打到pod2中，再过一会儿执行这个命令，所有的请求全部打到pod3中。

和预期并不相符合：

为什么for循环中10次请求，没有分别打到不同的pod中呢？这个traefik的负载均衡，是实现把流量转发到不同的pod中么？如果是转发到不同的pod中，是如何实现的呢？

同一批次请求集中到一个 Pod，间隔后切换的核心原因是 Kubernetes Service 的会话亲和性（Session Affinity）与连接复用 共同作用的结果。

当前负载均衡的实际链路

从配置来看，流量路径是：
客户端（curl）→ Traefik → Kubernetes Service（NodePort）→ Pod

其中，实际的 Pod 负载均衡是由 Kubernetes Service 完成的 ，而非 Traefik。因为你的 Traefik 配置中，hello-service只指向了一个后端（Kubernetes Service 的 NodePort：http://172.18.0.2:32599），Traefik 自身并没有感知到多个 Pod 的存在，只是单纯将所有请求转发给这个 NodePort。

为什么同一批次请求会集中到一个 Pod？

Kubernetes Service 默认的负载均衡策略是 轮询（Round Robin） ，但存在一个关键特性：对同一客户端连接的请求会 "粘住" 同一个 Pod（默认启用短时间的会话亲和性）。

具体来说：

curl命令在默认情况下会启用 HTTP/1.1 的长连接（Keep-Alive），10 次循环请求会复用同一个 TCP 连接。
Kubernetes Service 检测到这是同一个连接，会将该连接上的所有请求转发到同一个 Pod（这是为了避免分布式场景下的会话状态丢失，是默认优化）。
当连接断开（间隔一段时间后），新的连接会触发 Service 重新轮询到下一个 Pod，因此你会看到 "间隔后切换 Pod" 的现象。