突然想到这个问题，幸好K8s的issue上有相关问题：

issue 27114

我们最初的理解是LivenessProbe会在ReadinessProbe成功后开始检查，但事实并非如此。

我们正在测试具有较长启动时间的系统，启动时间大约在 1-3 分钟之间。

我们将ReadinessProbe指定为与 LivenessProbe相同的 url，并将 LivenessProbe的初始延迟指定为 30 秒，我们发现 pod 因 LivenessProbe失败而被kill，而ReadinessProbe仍然失败。

那么，为什么我们不指定LivenessProbe的初始延迟超过 3 分钟呢？即ReadinessProbe在第一分钟成功，但是LivenessProbe没有成功，pod任然无法运行。
所以，它会影响正在运行的服务。

为什么我们不只用ReadinessProbe而放弃LivenessProbe？
当ReadinessProbe再次失败时，它也可能会停止服务，因此不会对正在运行的服务造成任何影响，问题是：Pod不会重新启动，我们必须手动重新启动它们。

kubelet 使用存活探测器来知道什么时候要重启容器。 例如，存活探测器可以捕捉到死锁（应用程序在运行，但是无法继续执行后面的步骤）。 这样的情况下重启容器有助于让应用程序在有问题的情况下更可用。
kubelet 使用就绪探测器可以知道容器什么时候准备好了并可以开始接受请求流量， 当一个 Pod 内的所有容器都准备好了，才能把这个 Pod 看作就绪了。 这种信号的一个用途就是控制哪个 Pod 作为 Service 的后端。 在 Pod 还没有准备好的时候，会从 Service 的负载均衡器中被剔除的。
kubelet 使用启动探测器(startupProbe)可以知道应用程序容器什么时候启动了。 如果配置了这类探测器，就可以控制容器在启动成功后再进行存活性和就绪检查， 确保这些存活、就绪探测器不会影响应用程序的启动。 这可以用于对慢启动容器进行存活性检测，避免它们在启动运行之前就被杀掉。

真正的启动顺序

Caution: Liveness probes do not wait for readiness probes to succeed. If you want to wait before executing a liveness probe you should use initialDelaySeconds or a startupProbe.

也就是 Liveness probes并不会等到Readiness probes成功之后才运行
  • 根据上面的官方文档，Liveness 和 readiness 应该是某种并发的关系