K8s集群6个同配置Pod副本始终有1个响应远慢于其余5个的故障排查

最高优先级排查（90%同类问题命中） #

• 检查应用是否存在分布式选主逻辑
  这类问题和描述的特征完全匹配：应用通过Redis/etcd做分布式选主，始终只有1个Leader Pod额外承担全量缓存同步、定时数据对账、批量日志上报、离线统计这类重CPU/IO的后台任务，剩余Follower Pod只处理普通REST请求。删除当前Leader Pod后，集群重新选主，新的Leader Pod会随机落到其他副本上，永远保持N-1个快Pod、1个慢Pod的比例。
  排查操作：
  1. 进入慢Pod执行top -H -p 1，对比快Pod的进程线程CPU占用，看是否存在高CPU占比的后台工作线程
  2. 拉取慢Pod的应用日志，搜索leader elected、full sync start、schedule task run这类选主、全量任务启动的关键字
  3. 直接调用慢Pod的内置监控接口（比如/metrics、/debug/pprof），看后台任务相关的指标是否有持续增长
     解决方案：
  • 后台任务单独部署独立的Deployment，和前台流量承载Pod物理隔离
  • 若必须混跑，Pod当选Leader后主动修改就绪探针返回非200状态，触发Service、ALB将流量自动摘除，不再转发外部请求
  • 给后台任务线程设置CPU、IO优先级限制，避免抢占前台请求的处理资源

次高优先级排查（网络链路类问题） #

• 排查Pod到Redis的链路质量差异
  排查操作：
  1. 分别进入慢Pod和正常Pod，执行redis-cli --latency -h <Redis实例地址>对比直连Redis的延迟差，执行mtr -rw <Redis实例地址>看链路是否存在丢包
  2. 在慢Pod内执行ss -ti，看TCP连接是否存在高重传率、RTO超时异常，执行ip -s link看虚拟网卡是否有丢包、错包计数
     常见根因：
  • CNI插件MTU配置错误：VXLAN模式下未正确将MTU减去封包开销（通常50字节），大报文被丢弃触发重传，某条Pod到Redis的VXLAN隧道MTU不一致时就会触发固定单Pod慢
  • kube-proxy ipvs模式连接超时配置不合理，TIME_WAIT连接堆积导致新建Redis连接排队
  • Redis客户端连接哈希倾斜：客户端一致性哈希规则刚好将高负载的Redis分片连接分配到某一个Pod，Pod重建后连接重置，哈希环偏移就会落到其他Pod上
• 确认直连PodIP的测试有效性：保证测试时携带的请求头、请求参数、报文大小和线上真实流量完全一致，排除特定请求参数触发慢查询逻辑的情况

节点与容器运行时排查 #

不要只依赖CPU利用率指标判断节点资源充足，很多隐藏瓶颈不会体现在常规CPU利用率监控上：

• 排查慢Pod所在节点的隐藏资源瓶颈
  排查操作：
  1. 执行kubectl describe node <慢Pod所在节点>，查看ephemeral-storage、PID这类容易被忽略的资源分配率，是否存在其他Pod抢占节点预留资源
  2. 登录节点执行vmstat 1，观察CPU steal时间（云主机宿主机超卖时steal值会升高，表现为CPU利用率低但实际拿不到算力）、si/so指标（不为0说明开启了swap，内存交换会导致响应速度骤降数倍）、r队列长度（长期大于CPU核数说明存在CPU调度等待）
  3. 登录节点执行iostat -x 1，观察系统盘、数据盘的await、util指标，云盘IO打满时，Pod写日志、读写本地缓存都会出现明显延迟，但Pod CPU利用率通常不会升高
  4. 检查CFS节流情况：找到慢Pod对应的cgroup路径，执行cat cpu.stat查看nr_throttled（节流次数）、throttled_time（节流总时长），和正常Pod对比是否存在明显偏高——内核版本低于4.18时存在CFS带宽控制bug，即使CPU利用率低于30%也可能被意外节流
• 排查容器运行时异常：执行crictl logs <容器ID>看是否存在日志驱动阻塞，执行crictl stats <容器ID>对比容器实际资源使用和监控平台采集的指标，排除监控数据不准导致的误判

应用运行时配置排查 #

• 检查运行时参数适配问题
  Go、Java这类依赖运行时自动设置并行线程数的应用，如果没有正确感知容器CPU limit，会默认读取宿主机CPU核数（比如节点为16核时设置16个并行线程，但Pod实际只有4核配额），导致大量上下文切换，调度到特定节点时就会触发性能骤降。排查时进入容器查看GOMAXPROCS、JVM ParallelGCThreads参数是否和Pod配置的4核匹配。
• 排查GC停顿问题：分别拉取慢Pod和正常Pod的GC日志，对比GC频率、单次停顿时间，若慢Pod的GC停顿占总时间比例超过10%，说明存在内存使用不合理、频繁GC的问题。
• 排查连接池状态：在慢Pod内执行ss -s查看TCP连接状态，是否存在大量SYN_SENT、TIME_WAIT堆积，到Redis的连接池是否被打满出现请求排队。

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