为了进行容器是否活着的健康检查，活动性探针将在容器无响应时重新启动容器，而就绪性探针用于确定容器何时准备开始或停止接受流量。
许多人认为就绪探针仅在启动时被调用，但是即使在容器被通知为就绪后仍继续被调用。例如，如果某个容器暂时很忙，则它可能无法准备就绪，因此请求将被路由到其他容器。如果准备就绪探针评估一组Pod之间的共享依赖关系，则如果配置过于激进，则可能会使整个服务不可用。但是，没有一种方法做到：可以在启动时使用积极的准备状态探针（使容器尽可能快地用于请求），而在稳态期间则是做到没有那么积极的准备状态探针。
许多应用程序的启动动态与稳态大不相同。应用程序初始化所独有的动态特性包括：填充缓存；在事件源应用程序中重新实现从日记的派生状态；或建立与依赖关系（如数据库）的持久连接。这使调整活动性和就绪性探针变得颇具挑战性。
例如，如果initialDelaySeconds活动性探针的保守度不够，则可能在启动容器之前将其杀死。如果启动动态随时间变化（尤其是随着您的系统扩展或工作负载具有季节性），这尤其具有挑战性。如果一段时间未重新启动容器，并且启动时间增加，则可能要等到修改配置增加initialDelaySeconds时，才能重新启动Pod
Kubernetes 1.16中引入的启动探针旨在解决许多此类问题。
启动探针旨在解决这些问题。仅在启动期间调用启动探针，用于确定容器何时准备接受请求。如果配置了启动探针，则将禁用活动性和就绪性检查，直到启动探针成功为止。如果启动探针超出配置，failureThreshold但没有成功，则容器将被杀死并重新启动，这取决于容器的restartPolicy行为，类似于活动探针的行为。
最佳实践：
- 进行保守设置timeoutSeconds，failureThreshold以便可以动态或临时更改系统动态，而不会导致启动探针故障而阻止容器启动。
- 如果启动探针调用的路由直接检查依赖项或执行昂贵的操作，请考虑将其设置timeoutSeconds为相同的大小，以避免积累资源或使依赖项过载。即使启动探测超时，该服务可能仍在执行请求。
- 定期重新启动容器以行使启动动态，并避免随时间变化意外的行为。如果某个Pod运行了数月或数年却没有重新启动，则值得关注。
启动探针还具有一些独特的注意事项：
- 要使缓慢启动的容器尽快可用，请使用超时时间非常短但故障阈值也非常长的启动探针，以避免在启动容器之前将其杀死。
- 准备就绪和活跃性探针与启动探针无关，这一事实使您对启动探针故障非常保守，或者执行不同的检查，也许仅在启动时才相关的检查，或者过于昂贵，无法通过以下方式定期执行准备或活跃度调查。
Kubernetes启动探针现已广泛用于领先云提供商的托管Kubernetes产品。将启动探针视为仅在启动时才运行的活动和就绪探针的组合。使用启动探针将活动性和就绪性检查与应用程序初始化脱钩，最终使服务更可靠。