Kubernetes对Pod的健康状态可以通过三类探针来检查：LivenessProbe、ReadinessProbe及StartupProbe，其中最主要的探针为LivenessProbe与ReadinessProbe，kubelet会定期执行这两类探针来诊断容器的健康状况。
（1）LivenessProbe探针：用于判断容器是否存活（Running状态），如果LivenessProbe探针探测到容器不健康，则kubelet将“杀掉”该容器，并根据容器的重启策略做相应的处理。如果一个容器不包含LivenessProbe探针，那么kubelet认为该容器的LivenessProbe探针返回的值永远是Success。
（2）ReadinessProbe探针：用于判断容器服务是否可用（Ready状态），达到Ready状态的Pod才可以接收请求。对于被Service管理的Pod，Service与Pod Endpoint的关联关系也将基于Pod是否Ready进行设置。如果在运行过程中Ready状态变为False，则系统自动将其从Service的后端Endpoint列表中隔离出去，后续再把恢复到Ready状态的Pod加回后端Endpoint列表。这样就能保证客户端在访问Service时不会被转发到服务不可用的Pod实例上。需要注意的是，ReadinessProbe也是定期触发执行的，存在于Pod的整个生命周期中。
（3）StartupProbe探针：某些应用会遇到启动比较慢的情况，例如应用程序启动时需要与远程服务器建立网络连接，或者遇到网络访问较慢等情况时，会造成容器启动缓慢，此时ReadinessProbe就不适用了，因为这属于“有且仅有一次”的超长延时，可以通过StartupProbe探针解决该问题。
以上探针均可配置以下三种实现方式。
（1）ExecAction：在容器内部运行一个命令，如果该命令的返回码为0，则表明容器健康。
在下面的例子中，通过运行cat/tmp/health命令来判断一个容器运行是否正常。在该Pod运行后，将在创建/tmp/health文件10s后删除该文件，而LivenessProbe健康检查的初始探测时间（initialDelaySeconds）为15s，探测结果是Fail，将导致kubelet“杀掉”该容器并重启它：
（2）TCPSocketAction：通过容器的IP地址和端口号执行TCP检查，如果能够建立TCP连接，则表明容器健康。
在下面的例子中，通过与容器内的localhost：80建立TCP连接进行健康检查：
（3）HTTPGetAction：通过容器的IP地址、端口号及路径调用HTTP Get方法，如果响应的状态码大于等于200且小于400，则认为容器健康。
在下面的例子中，kubelet定时发送HTTP请求到localhost：80/_status/healthz来进行容器应用的健康检查：
对于每种探测方式，都需要设置initialDelaySeconds和timeoutSeconds两个参数，它们的含义分别如下。
◎ initialDelaySeconds：启动容器后进行首次健康检查的等待时间，单位为s。
◎ timeoutSeconds：健康检查发送请求后等待响应的超时时间，单位为s。当超时发生时，kubelet会认为容器已经无法提供服务，将会重启该容器。
如下代码片段是StartupProbe探针的一个参考配置，可以看到，这个Pod可以有长达30×10=300s的超长启动时间：
Kubernetes的Pod可用性探针机制可能无法满足某些复杂应用对容器内服务可用状态的判断，所以Kubernetes从1.11版本开始，引入了Pod Ready++特性对Readiness探测机制进行扩展，在1.14版本时达到GA稳定版本，称其为Pod Readiness Gates。Pod Readiness Gates给予了Pod之外的组件控制某个Pod就绪的能力，通过Pod Readiness Gates机制，用户可以设置自定义的Pod可用性探测方式来告诉Kubernetes某个Pod是否可用，具体使用方式是用户提供一个外部的控制器（Controller）来设置相应Pod的可用性状态。
Pod的Readiness Gates在Pod定义中的ReadinessGate字段进行设置。下面的例子设置了一个类型为www.example.com/feature-1的新Readiness Gate：
新增的自定义Condition的状态（status）将由用户自定义的外部控制器设置，默认值为False。Kubernetes将在判断全部readinessGates条件都为True时，才设置Pod为服务可用状态（Ready为True）。