AWS EKS集群中K8s内部Service请求负载不均衡问题排查

1. K8s ClusterIP Service的连接复用限制 #

K8s ClusterIP Service默认的轮询负载均衡是基于TCP连接的，而非基于请求。当Service A的Pod使用HTTP连接池复用长连接时，所有复用该连接的请求都会发送到同一个Service B的Pod。如果Service A的Pod数量远少于Service B，或者连接池未配置自动刷新，就会导致大量请求集中到少数后端Pod。

2. Service A的RabbitMQ消费负载不均 #

RabbitMQ的默认消费调度可能导致Service A的Pod获取消息的数量差异大：比如部分A Pod预取（prefetch）了更多消息，或者队列的分区/哈希策略导致消息集中分配给少数A Pod，进而让这些A Pod向Service B发送更多请求，加剧后端负载不均。

3. Service端点同步延迟 #

当Service B快速扩缩容到100个Pod时，K8s的Endpoint/EndpointSlice同步可能存在延迟。Service A的Pod本地缓存的Service端点列表未能及时更新，导致请求仍发送到旧的Pod集合，新启动的Pod暂时无法接收请求。

4. Pod就绪性探针配置不合理 #

如果Service B的readiness探针配置过于宽松（比如仅检查端口开放，未验证服务实际可用），部分Pod可能被标记为就绪但实际无法处理请求；反之如果探针过于严格，Pod会频繁被移出端点列表，导致有效后端数量减少，负载集中到剩余Pod。

1. 调整客户端连接池策略 #

• 给Service A的HTTP客户端配置短连接或连接超时自动回收，比如设置Connection: close请求头，或在连接池中配置连接最大空闲时间（如30秒），避免长连接复用导致的负载倾斜。
• 如果使用HTTP/2，确保客户端启用请求级负载均衡（而非连接级），部分HTTP客户端默认在单HTTP/2连接上发送所有请求，需配置多路复用的负载均衡策略。

2. 优化RabbitMQ消费调度 #

• 设置RabbitMQ消费者的prefetch_count=1，限制每个Service A的Pod同时处理的消息数，确保消息均匀分配到所有A Pod，避免单个A Pod过载发送大量请求到Service B。
• 使用RabbitMQ的公平调度模式（关闭自动确认，手动确认消息处理完成），让空闲的A Pod优先获取新消息，平衡各A Pod的消息处理量。

3. 优化K8s Service负载均衡配置 #

• 确认Service的sessionAffinity: None（默认值）未被修改，确保没有会话保持导致的负载集中。
• 对于EKS集群，确保启用EndpointSlice（EKS 1.18+默认启用），提升端点更新的效率和实时性，减少扩缩容时的端点同步延迟。
• 考虑使用Headless Service配合客户端侧负载均衡（如Spring Cloud LoadBalancer、gRPC负载均衡），让Service A的Pod直接获取所有Service B的Pod IP，在客户端实现请求级轮询，绕过ClusterIP的连接级负载限制。

4. 完善Pod就绪性探针 #

• 调整Service B的readiness探针，确保探针真正验证服务的业务就绪状态（比如调用一个健康检查接口，返回200才标记就绪），避免未就绪的Pod加入端点列表。
• 配置合理的探针参数：initialDelaySeconds（等待服务启动完成的时间）、periodSeconds（检查间隔），减少探针误判导致的Pod频繁上下线。

5. 引入Service Mesh（可选） #

• 部署Istio或Linkerd等Service Mesh，通过sidecar代理实现请求级的轮询负载均衡，自动处理连接池、端点发现和负载均衡策略，无需修改应用代码即可解决负载不均问题。

内容的提问来源于stack exchange，提问作者Lerman