Kubernetes单Pod多容器场景下cache崩溃导致Service不可用如何解决

Kubernetes默认判定Pod就绪的规则为Pod内所有容器的readinessProbe（就绪探测）均通过，只要有任意一个容器未就绪，整个Pod会被标记为未就绪状态，进而被移出关联Service的负载均衡后端列表，你遇到的503报错就是这个机制导致的。

以下是三类可落地的实现方案：

方案1：调整cache容器的探测配置（改动最小） #

• 移除cache容器的readinessProbe配置，仅保留livenessProbe（如果需要容器崩溃后自动重启的话）
• 没有配置readinessProbe的容器默认启动后即被判定为就绪，且后续运行过程中不会因为进程崩溃触发就绪状态变更，此时Pod的就绪状态仅由server容器的探测结果决定，只要server正常，Pod就会保留在Service后端列表中

注意：该方案需要server服务本身做好降级逻辑，cache故障时可以正常返回响应，避免出现服务内部错误

方案2：配置Pod就绪门限自定义就绪规则 #

Kubernetes 1.14及以上版本支持Readiness Gates特性，可以自定义Pod就绪的判定条件，替代默认的所有容器就绪规则：

• 在Pod的spec.readinessGates字段中配置绑定server容器状态的自定义就绪条件
• 配置后Kubernetes只会根据你指定的规则判定Pod是否就绪，cache容器的状态不会影响Pod的就绪标记

方案3：拆分容器到独立Pod（符合云原生最佳实践） #

将server和cache拆分为两个独立的Deployment分别部署，各自关联独立的Service：

• server的Pod仅运行自身业务容器，就绪状态完全不受cache影响
• server通过cache的Service域名访问缓存服务，cache故障时仅需在server侧做降级处理即可，不会触发流量被Kubernetes截断的问题
• 该方案长期维护性更好，支持server和cache独立扩缩容、独立升级

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