AWS EKS集群同微服务Pod副本CPU使用率不均问题排查

以下是可能导致同一微服务下Pod CPU负载差异过大的关键配置或机制遗漏点：

• Service会话亲和性配置
  Kubernetes Service默认采用轮询（RoundRobin）策略分配流量，但如果配置了sessionAffinity: ClientIP或基于Cookie的会话粘滞，会导致同一客户端的请求持续指向特定Pod。高并发客户端会直接拉高对应Pod的负载，而其他Pod流量极少。检查Service的YAML配置，确认是否存在不必要的sessionAffinity及sessionAffinityConfig字段。

• 就绪探针（Readiness Probe）配置问题
  若就绪探针缺失、检查逻辑不合理或参数设置不当，会引发流量分配异常：

  • 探针检查过于宽松（如超时时间过长、检测频率过低）：过载的Pod未被及时从Service端点列表移除，持续接收流量；
  • 探针检查过于严格：健康Pod被误判为未就绪，剩余Pod承担全部流量；
  • 探针逻辑与业务实际就绪状态不匹配：仅检查端口而未验证服务是否能处理请求，导致未真正就绪的Pod接收流量。

• 容器资源请求与限制配置缺失
  未设置resources.requests.cpu会导致kube-scheduler无法基于资源需求合理调度Pod，可能将多个高负载Pod集中调度到同一节点，引发资源争抢；resources.limits.cpu设置过低则会导致Pod达到CPU限制后被节流，表现为负载高但处理能力不足，而其他节点的Pod因资源充足负载偏低。同时需检查EKS节点组的实例类型与自动扩缩容配置，确保节点资源池能支撑Pod调度需求。

• Ingress Controller负载策略配置
  若使用AWS ALB Ingress Controller等Ingress组件，需检查Ingress的注解配置：

  • 是否开启了会话粘滞（如alb.ingress.kubernetes.io/target-group-attributes: stickiness.enabled=true）；
  • 是否为不同Pod设置了权重分配，导致流量倾斜；
  • ALB的目标组路由策略是否被修改为非轮询模式。

• 应用层负载分发逻辑缺陷
  部分微服务自身的连接管理或服务发现逻辑可能导致流量集中：

  • 客户端侧启用了连接复用，持续向同一Pod发送请求；
  • 服务注册发现的缓存过期时间过长，新启动的Pod未被客户端及时识别，老Pod持续承担流量；
  • gRPC等协议的客户端默认采用pick_first策略，会固定连接到第一个发现的Pod，需手动配置为轮询或其他均衡策略。

• Kube-proxy模式与调度算法
  EKS中kube-proxy默认使用IPVS或iptables模式：

  • iptables模式下，Pod数量较多时规则更新存在延迟，可能导致流量分配不均；
  • IPVS模式的调度算法（如rr、lc、dh）若未按需配置，也会引发负载倾斜。可通过检查kube-proxy的配置确认模式与算法设置。

• Pod/节点亲和性配置不合理
  若Pod配置了节点亲和性（nodeAffinity）或Pod反亲和性（podAntiAffinity），规则不当会导致Pod扎堆：

  • 节点亲和性强制Pod调度到特定标签的节点，若这类节点数量不足，会引发Pod集中；
  • Pod反亲和性规则过于严格，导致部分节点无法调度Pod，剩余节点承载过多Pod。

内容的提问来源于stack exchange，提问作者Vishwanath.M