滚动部署场景下readinessProbe使用及依赖服务就绪校验问题

问题1解答 #

采用滚动部署策略发布应用新版本时，一定会用到就绪探针（readinessProbe）。
滚动部署的核心逻辑是渐进式替换旧版本Pod：先启动少量新版本Pod，待确认这些Pod可以正常对外提供服务后，再逐步下线旧版本Pod、扩容更多新版本Pod，避免全量发布引发整体服务故障。其中用于判断新版本Pod是否具备服务能力的核心依据，就是就绪探针的探测结果。如果新版本Pod的就绪探针连续探测失败，滚动部署流程会自动暂停，不会将流量切到异常的新版本实例，也不会继续推进部署进度，直到异常Pod恢复或者用户手动终止部署。

问题2解答 #

如果需要在就绪探针中校验依赖服务的就绪状态，可以选用以下三种常用方案：

• 自定义当前服务的健康检测接口：在业务代码中新增一个专用的健康检测接口，接口内部会同时校验自身服务状态和所有依赖服务的可用性，只有全部状态正常时才返回200状态码，再将就绪探针的path字段指向这个自定义接口即可，这是生产环境最常用的方案。
• 改用exec类型的就绪探针：不使用httpGet模式，改为通过执行自定义脚本完成探测，脚本中可以自定义任意检测逻辑，包括同时探测本地服务和依赖服务的端口、接口状态，所有检测项通过时脚本返回0，否则返回非0值即可。参考配置示例：

readinessProbe:
  exec:
    command:
    - /bin/sh
    - -c
    - "curl -s localhost:80/index.html && curl -s 依赖服务的集群内地址/健康检测路径"
  initialDelaySeconds: 3
  timeoutSeconds: 3
  periodSeconds: 10
  failureThreshold: 3

• 配合InitContainer实现预检测：如果只需要在Pod启动前校验依赖服务状态，不需要运行时持续检测，可以给Pod配置InitContainer，在InitContainer中执行依赖服务探测逻辑，只有探测成功才会启动主业务容器。注意这种方式无法感知Pod运行过程中依赖服务的故障，需要持续检测的场景不适用。

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