Kubernetes负载不均衡问询：K6压测下节点与Pod CPU使用率异常

一、Ingress负载不均的可能原因及排查方向 #

1. 会话粘性配置导致流量集中 #

若你的Ingress（如Nginx Ingress）开启了会话保持（粘性会话），请求会被绑定到特定Pod，进而导致该Pod所在节点CPU持续高位，另一节点负载偏低。

• 检查Ingress资源注解：执行kubectl describe ingress <你的Ingress名称>，查看是否存在nginx.ingress.kubernetes.io/affinity、nginx.ingress.kubernetes.io/session-cookie-name这类配置，若有则尝试移除，切换为非粘性模式。
• 验证Ingress Controller配置：进入Ingress Pod执行cat /etc/nginx/nginx.conf，确认是否存在ip_hash或cookie_hash相关规则。

2. Ingress Controller自身部署瓶颈 #

如果Ingress Controller仅部署1个Pod且运行在CPU居高的节点上，所有流量都会先经过这个Pod，导致节点CPU被Ingress Controller占满，而后端API Pod因未被充分利用负载较低。

• 检查Ingress Controller副本数：执行kubectl get deployment <Ingress控制器部署名> -n <命名空间>，若副本数为1，调整为至少2个，并通过节点反亲和性配置确保Pod调度到不同节点。
• 查看Ingress Controller Pod资源占用：执行kubectl top pod <Ingress Pod名> -n <命名空间>，确认是否是Ingress Controller本身消耗了节点的CPU资源。

3. Pod调度与Service路由异常 #

• 确认API Pod的节点分布：执行kubectl get pods -o wide，若两个Pod都在同一节点，另一节点自然无负载；若分布在不同节点但流量集中，需检查Kube-proxy转发规则，或确认Service的Endpoint是否正常更新（执行kubectl describe service <API服务名>查看Endpoint列表）。

二、资源充足但性能下降的原因 #

1. Ingress Controller成为流量瓶颈 #

即便后端API Pod资源充足，若Ingress Controller处理能力不足（单Pod、资源限制过低），会导致请求在Ingress层排队，进而拉长请求时长。

• 调整Ingress Controller资源配置：为其设置合理的CPU/内存请求与限制（例如requests: {cpu: "1", memory: "1Gi"}，limits: {cpu: "2", memory: "2Gi"}），并增加副本数。

2. .NET API的并发配置限制 #

无数据库的.NET API仍可能因Kestrel服务器设置或线程池配置无法支撑高并发请求：

• 检查Kestrel并发连接数：在Program.cs中确认是否配置了KestrelServerOptions.Limits.MaxConcurrentConnections，默认值可能不足以承载每秒1000次请求。
• 优化.NET线程池：通过ThreadPool.SetMinThreads增加最小工作线程数，避免高并发下线程池扩容延迟导致的请求排队。
• 启用Server GC：在项目文件中添加<ServerGarbageCollection>true</ServerGarbageCollection>，提升高并发场景下的垃圾回收性能。

3. 网络层面隐性瓶颈 #

• 节点间网络质量：若两个节点跨可用区或网络带宽不足，即使Pod分布合理，也会导致请求转发延迟。可通过iperf测试节点间带宽，或tcpping检测延迟。
• Kube-proxy模式瓶颈：默认iptables模式下，大量Service和Endpoint会累积过多规则，增加转发延迟。可切换为IPVS模式提升负载转发效率。

三、验证与修复步骤 #

1. 优先排查Ingress Controller的副本数、资源占用及节点分布，确保其具备足够的流量处理能力。
2. 关闭Ingress的会话粘性配置，重新压测验证流量是否均匀分发到两个API Pod。
3. 调整.NET API的Kestrel和线程池配置，再次压测观察请求时长变化。
4. 若问题仍存在，在Ingress Pod和API Pod上执行tcpdump抓包，分析流量转发路径是否存在异常。

内容的提问来源于stack exchange，提问作者Son Of Earth