基于Kubernetes的服务可用性问题咨询

我们每5秒对服务执行一次内部健康检查，同时每1秒执行一次Kubernetes存活探针（liveness probes）。最坏情况下，Kubernetes负载均衡器每6秒才能获取到最新的健康状态信息。想咨询：当客户端请求命中已故障但未被Kubernetes负载均衡器识别为不健康的Pod时，该如何处理？是由客户端实现重试逻辑，还是由后端实现对应处理逻辑来应对此类场景？

核心思路：两者结合，分层容错 #

K8s负载均衡器的状态同步延迟是分布式系统里的常见问题，单靠某一层的容错都不够稳妥，建议客户端重试+后端兜底配合来处理。

1. 客户端侧该做的事

• 对幂等请求（比如GET查询、带唯一请求ID的幂等POST/PUT），一定要做重试：
  • 控制重试次数（别超过3次），防止引发集群雪崩
  • 用指数退避的方式间隔重试，别一股脑全打回去
  • 只对明确的服务端错误重试（比如连接超时、5xx状态码），4xx客户端错误别瞎重试
• 非幂等请求谨慎重试，除非后端已经实现了请求去重逻辑（比如基于请求ID去重）

2. 后端侧的兜底处理

• 快速失败：如果Pod自身通过内部健康检查发现故障，直接返回503 Service Unavailable这类明确的错误，别让请求挂着或者返回模糊报错
• 加速状态同步：把K8s的就绪探针（readiness probes）和内部健康检查对齐——就绪探针直接决定负载均衡器会不会把流量打过来，把它的检测频率设成1秒，比存活探针更敏感，能大幅缩短负载均衡器感知故障的时间
• 请求降级转发：如果故障Pod还能正常处理网络请求，可以把请求转发到集群内的健康实例，但要注意加个判断，别循环转发增加额外开销

3. 额外优化建议

• 把内部健康检查的频率调到和就绪探针一致（比如1秒），从根源缩小状态同步的时间差，减少最坏情况的延迟窗口
• 如果业务允许，开启负载均衡器的会话亲和性，但要提前考虑故障时的会话迁移问题
• 加个监控告警：针对“已故障但仍在接收流量”的Pod设置告警，能及时发现问题介入排查

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