是否应设置存活探针initialDelaySeconds≥就绪探针相关参数之和？最佳实践探讨

在Kubernetes配置中，将存活探针的initialDelaySeconds设置为大于等于就绪探针的initialDelaySeconds加上periodSeconds与timeoutSeconds的乘积，是否属于最佳实践？

示例配置 #

readinessProbe:
  initialDelaySeconds: 360
  periodSeconds: 30
  timeoutSeconds: 30
livenessProbe:
  initialDelaySeconds: 660
  periodSeconds: 60
  timeoutSeconds: 30
  failureThreshold: 1
startupProbe:
  initialDelaySeconds: 60
  failureThreshold: 30
  periodSeconds: 10

应用启动实测数据 #

该应用在Pod中启动64次：

• 最长初始化耗时120秒
• 99分位数为115秒
• 三分之二的应用在60秒内完成初始化

配置分析与结论 #

这种设置方式属于贴合业务实际的最佳实践，核心逻辑与优势如下：

1. 避免存活探针误判：存活探针延迟启动，确保应用已经过就绪探针的多轮检查后，再开始存活状态探测，防止应用在初始化后期或就绪验证阶段被误判为故障重启。
2. 适配应用初始化特性：结合实测启动数据，启动探针设置为最长初始化时间的3倍（360秒），给足应用初始化的容错空间；就绪探针在360秒后启动，此时绝大多数应用已完成初始化，能准确判断是否可接收流量。
3. 减少无效资源消耗：存活探针延迟至10分钟后启动，减少了应用初始化阶段不必要的探测请求，降低了Kubelet与应用的额外资源开销。

需注意，具体数值需结合应用实际启动性能、运行环境调整，核心原则是保证存活探针的启动时间晚于应用大概率完成就绪检查的节点，避免误操作。

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