Kubernetes liveness 和 readiness 探针可用于提高服务的可靠性。但是，如果不小心使用它们，它们可能会适得其反，并通过微妙的、意想不到的后果降低服务的可靠性。
我写了一个分别有几部分的文章(见延伸阅读)，介绍如何使用 Kubernetes 的 liveness 和 readiness 探针来避免“给自己挖坑”。我详述的一些问题与启动动态有关。Kubernetes 1.16 中引入的启动探针旨在解决其中的许多问题。如果你允许我继续：启动探针——当然，至少足够长的时间，然后用活跃度和准备度探针来避免“给自己挖坑”
Startup Issues
回顾一下，当容器变得无响应时，liveness 探针将重新启动容器，并且 readiness 探针用于决定容器何时准备好启动或停止接受流量。许多人认为就绪探测仅在启动时调用，但即使在容器被宣传为就绪后它仍会继续调用。例如，如果一个容器暂时繁忙，它可能会变得未就绪，以便将请求路由到其他 pod。如果准备就绪探测评估一组 pod 之间的共享依赖关系，那么如果配置过于激进，就有可能导致整个服务不可用。但是，没有办法在启动时进行积极的就绪探测——使容器尽快可用于请求——在稳态操作期间使用不那么积极的就绪探测。
许多应用程序的启动动态与稳态显着不同。应用程序初始化所特有的动态包括： 填充缓存；在事件源应用程序中从日志中重新实现派生状态；或建立与依赖项（如数据库）的持久连接。这使得调整 liveness 和 readiness 探针具有挑战性。例如，如果initialDelaySeconds对于一个 liveness 探测不够保守，一个容器可能在它启动之前就被杀死了。如果启动动态随时间发生变化，这尤其具有挑战性，可能随着你的系统扩展或工作负载的季节性变化。如果容器有一段时间没有重新启动并且启动时间增加了，那么在将配置修改为增加之前，你可能无法重新启动 Pod initialDelaySeconds。
Startup Probes
启动探针旨在解决这些问题。启动探针仅在启动期间调用，用于确定容器何时准备好接受请求。如果配置了启动探测，则会禁用活动性和就绪性检查，直到启动探测成功。如果启动探测超出了配置failureThreshold但没有成功，容器将被杀死并重新启动，这取决于 pod 的restartPolicy，类似于 liveness 探测的行为。
我在容器启动中描述的所有警告都适用于启动探针：
- 设置
timeoutSeconds和failureThreshold保守，以便系统动态可以临时或永久更改，而不会导致启动探测失败，从而阻止容器启动。 - 如果启动探针调用的路由直接检查依赖关系或执行昂贵的操作，请考虑设置
timeoutSeconds相同的量级，以避免积累资源或重载依赖关系。即使启动探测超时，服务可能仍在执行请求。 - 定期重启容器以锻炼启动动态并避免随着时间的推移出现意外的行为变化。如果一个 pod 运行了几个月或几年而没有重新启动，那就需要担心了。
启动探针也有一些独特的考虑：
- 要使启动缓慢的容器尽快可用，请使用具有非常短的超时但也非常长的故障阈值的启动探针，以避免在容器启动之前将其杀死。
- 就绪和活跃度探测独立于启动探测这一事实允许您对启动探测失败非常保守，或者执行不同的检查，也许检查仅在启动时相关，或者过于昂贵而无法通过定期执行准备就绪或活跃度探测。
概括
Kubernetes 启动探针现在可广泛用于领先云提供商的托管 Kubernetes 产品。将启动探针视为仅在启动时运行的活跃度和就绪度探针的组合。使用启动探针将活动性和就绪性检查与应用程序初始化分离，最终使服务更加可靠。请注意不要给自己挖坑。
延伸阅读
Kubernetes Liveness 和 Readiness 探测避免给自己挖坑续集Kubernetes探针补充重新审视kubernetes活跃探针和就绪探针 如何避免给自己挖坑2linuxea:kubernetes 存活状态liveness probe(7)linuxea:kubernetes 就绪检测readiness probe(8)Kubernetes Liveness vs Readiness ProbeKubernetes探针补充Kubernetes Startup Probes避免给自己挖坑3
