Kubernetes提供了两种探针来检查容器的状态，Liveliness和Readiness，根据官方文档

Liveliness探针是为了查看容器是否正在运行，翻译为存活探针（livenessProbe）

Readiness探针是为了查看容器是否准备好接受HTTP请求，翻译为就绪探针（readinessProbe）

存活探针（livenessProbe）

Liveness探测器是让Kubernetes知道你的应用是否活着。如果你的应用还活着，那么Kubernetes就让它继续存在。如果你的应用程序已经死了，Kubernetes将移除Pod并重新启动一个来替换它。

就绪探针（readinessProbe）

就绪探针旨在让Kubernetes知道你的应用是否准备好为请求提供服务。Kubernetes只有在就绪探针通过才会把流量转发到Pod。如果就绪探针检测失败，Kubernetes将停止向该容器发送流量，直到它通过。

让我们看看两个场景，来看看就绪探针和存活探针怎样帮助我们构建更高可用的的系统。

存活探针（livenessProbe）

让我们想象一种情况，当我们的应用在成功启动以后因为一些原因“宕机”，或者遇到死锁情况，导致它无法响应用户请求。 在默认情况下，Kubernetes会继续向Pod发送请求，通过使用存活探针来检测，当发现服务不能在限定时间内处理请求（请求错误或者超时），就会重新启动有问题的pod

就绪探针（readinessProbe）

 一个应用往往需要一段时间来预热和启动，比如一个后端项目的启动需要连接数据库执行数据库迁移等等，一个Spring项目的启动也需要依赖Java虚拟机。即使该过程已启动，您的服务在启动并运行之前也无法运行。应用在完全就绪之前不应接收流量，但默认情况下，Kubernetes会在容器内的进程启动后立即开始发送流量。通过就绪探针探测，直到应用程序完全启动，然后才允许将流量发送到新副本。

探针类型 探针类型是指通过何种方式来进行健康检查，K8S有三种类型的探测：HTTP，Command和TCP。

HTTP

HTTP探测可能是最常见的探针类型。即使应用不是HTTP服务，也可以创建一个轻量级HTTP服务器来响应探测。比如让Kubernetes通过HTTP访问一个URL，如果返回码在200到300范围内，就将应用程序标记为健康状态，否则它被标记为不健康。 更多关于HTTP探测可参考这里。

命令

对于命令探测，是指Kubernetes在容器内运行命令。如果命令以退出代码0返回，则容器将标记为正常。否则，它被标记为不健康。 更多关于命令探测可参考这里。

TCP

最后一种类型的探测是TCP探测，Kubernetes尝试在指定端口上建立TCP连接。如果它可以建立连接，容器被认为是健康的; 如果它不能被认为是不健康的。这常用于对gRPC或FTP服务的探测。 更多关于TCP探测可参考这里。

初始探测延迟 我们可以配置K8S健康检查运行的频率，检查成功或失败的条件，以及响应的超时时间。可参考有关配置探针的文档。 存活探针探测失败会导致pod重新启动，所以配置初始探测延迟 initialDelaySeconds十分重要，要确保在应用准备之后探针才启动。否则，应用将无限重启！ 我建议使用p99启动时间作为initialDelaySeconds，或者取平均启动时间外加一个buffer。同时根据应用程序的启动时间更新这个值。