Kubernetes 1.16中Startup Probe被忽略问题排查求助

环境与探针配置 #

我在Kubernetes 1.16版本部署了WAS服务，配置了三类探针，各自作用如下：

• Liveness探针：检查WAS进程运行状态及端口监听情况
• Readiness探针：通过HTTP GET调用WAS的healthcheck API判断服务是否就绪
• Startup探针：复用Liveness探针逻辑，额外负责初始化healthcheck API；若该探针未执行，healthcheck API无法启用，会导致Readiness探针持续失败

探针配置代码如下：

livenessProbe:
  exec:
    command:
    - liveness 
  initialDelaySeconds: 10
readinessProbe:
  exec:
    command:
    - readiness
  initialDelaySeconds: 10
startupProbe:
  exec:
    command:
    - liveness
    - -startup
  failureThreshold: 36
  periodSeconds: 5

预期逻辑与实际异常 #

预期逻辑 #

1. 若Startup探针重复失败超过阈值（36次），容器会触发重启
2. 若Startup探针正常执行，Readiness探针不应失败（注：healthcheck API启用失败会导致Startup探针失败，不存在Startup成功但Readiness失败的情况）

按此逻辑，要么容器重启，要么Readiness探针成功，不应出现Readiness探针失败的情况。

实际异常 #

Startup探针配置了failureThreshold:36、periodSeconds:5，理论上180秒内Liveness/Readiness探针不应执行，但实际观测到Readiness探针在3分钟前就出现失败记录，怀疑Startup探针行为被覆盖，导致Liveness/Readiness探针提前执行。

根据K8s文档，Startup探针的作用是确保Liveness/Readiness在正确时机运行，若该探针被忽略，仅靠initialDelaySeconds的绝对时间控时效果很差。

已尝试的排查手段 #

• 使用kubectl describe查看Pod详情
• 通过kubectl logs分析容器日志
• 查看K8s事件记录

但以上手段仅能看到Readiness探针的失败事件，无法获取Startup探针的成败状态，不确定是否是自己对Startup探针工作机制理解有误。

求助需求 #

恳请提供合理的排查方案与解决办法，帮助确认：

• Startup探针是否真的被覆盖或未按预期工作
• 为何Readiness探针会提前执行
• 如何验证Startup探针的运行状态

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