Google Cloud Platform Load Balancer 多POD负载分布不均问题咨询

这类单微服务多Pod部署、基于round-robin调度出现的Pod间负载倾斜、低流量Pod存在明显接收空档的问题，是K8s服务间通信排查的高频共性问题，大量团队在压测阶段都遇到过同类现象，核心诱因基本集中在负载均衡全链路的几个断点上，可按以下方向逐层排查：

• 确认kube-proxy的实际调度逻辑与配置
  • 多数集群默认的kube-proxy并非实现真正的逐请求轮询：如果运行在iptables模式，后端分流依赖随机数命中规则，当上游发起请求的Pod数量远小于后端Pod规模时，随机命中的概率偏差会直接导致部分后端Pod长期没有被命中，表现出明显的流量接收空档；如果运行在ipvs模式，需要检查实际配置的调度算法，不少集群默认调度器为源端哈希、加权轮询而非纯round-robin，若开启了会话保持参数，同上游的请求会被固定路由到同一后端，直接造成负载倾斜。
  • 结合规则验证：在节点层面查看针对微服务2 ClusterIP的iptables/ipvs规则分布，确认每个后端Pod的命中权重配置是否一致。
• 排查应用层的连接复用逻辑
  • 上游微服务1基于Nginx、Node.js通信时，默认会开启长连接与连接池复用，一旦上游Pod与某个微服务2 Pod建立了持久化连接，连接存续期间的所有请求都会复用该链路，不会触发kube-proxy的重新分流。以上游仅3个Pod的链路为例，若每个上游Pod仅与2-3个微服务2 Pod建立了长连接，剩余3-4个微服务2 Pod长期收不到流量，完全匹配观测到的“流量空档”现象。
  • 验证方式：在每个上游Pod内执行连接状态查询，统计其与所有微服务2 Pod的已建立TCP连接数，对比连接分布与实际流量分布是否高度重合。
• 核查跨可用区的路由亲和策略
  • 当前集群跨3个可用区部署，不少云厂商的K8s集群默认开启了可用区优先的服务拓扑、节点本地路由缓存策略，会优先将请求路由到同可用区的后端Pod，仅当同AZ后端资源不足时才会跨AZ转发。若微服务1的Pod集中部署在某2个可用区，剩余1个可用区内的微服务2 Pod拿到的流量会显著偏低，且接收请求的时间间隔会明显拉长，出现空档。
  • 检查项：确认是否启用了Service拓扑规则、节点级的路由亲和权重配置，跨AZ流量的实际占比是否符合预期。
• 校验低流量Pod自身的接收能力
  • 排除负载均衡分流问题后，需确认低流量Pod是否存在能力瓶颈：由于微服务2基于Node.js开发，若出现事件循环周期性阻塞、TCP全连接队列溢出、SYN包丢弃等问题，分流到该Pod的请求会在内核层直接被丢弃，上游重试时会自动选择其他可用Pod承接，长期累积后就会表现为该Pod整体流量偏低、且流量间隔存在明显空档。
  • 可验证的指标：每个Pod的TCP层丢包计数、Node.js进程事件循环延迟、GC停顿时长、应用层请求处理成功率。

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