一、pod存活性探测
pod spec为容器列表中的相应容器定义其专用的探针即可启用存活性探测，目前，k8s的容器支持存活性探测的方法包含：ExecAction、TCPSocketActon和HTTPGetAction。
1、设置exec探针
exec类型的探针通过在目标容器中执行由用户自定义的命令来判定容器的健康状态，若命令状态返回值为0则表示成功通过探测。spec.containers.livenessProbe.exec字段用于定义此类检测，它只有一个属性“command”，用于定义要执行的命令。
exec指定的命令运行于容器中，会消耗容器的可用资源配额，另外，考虑到探测操作的效率本身等因素，探测操作的命令应该尽可能简单和轻量。
2、设置HTTP探针
基于HTTP的探测向目标容器发起一个HTTP请求，根据其响应码进行结果判定，响应码形如2**或3**时表示检测通过。spec.containers.livenessProbe.httpGet字段用于定义此类检测，它的可用配置字段包括如下：
host：请求的主机地址，默认为podIP；也可以在httpHeaders中使用host来定义
httpHeaders：定义的请求报文首部
path：请求的HTTP资源路径，即URL path
scheme：建立连接使用的协议，仅可为HTTP或HTTPS，默认为HTTP
这种检测方式仅对分层架构中的当前一层有效，例如，它能检测应用程序工作正常与否的状态，但重启操作却无法解决其后端服务（如数据库或缓存服务）导致的故障。此时，容器可能会被一次次的重启，直到后端服务恢复正常为止。其他两种方式也存在类似的问题。
3、设置TCP探针
基于TCP的存活性探测用于向容器的特定端口发起TCP请求并尝试建立连接进行结果判定，连接建立成功即为通过检测。它比基于HTTP的探测要更高效更节省资源，但精确度略低，毕竟建立连接成功未必意味着页面资源可用。spec.containers.livenessProbe.Socket字段用于定义此类检测，主要包含以下两个可用的属性：
host：请求连接的目标IP地址，默认为podIP
port：请求连接的目标端口，必选字段。
4、存活性探测行为属性
使用kubectl describe命令可查看配置了存活性探测的pod对象的相关信息，它给出了探测方式及额外的配置属性delay、timeout、period、success和failure及其各自的相关属性值。用户没有明确定义这些属性字段时，它们会使用各自的默认值。这些属性信息可通过spec.containers.livenessProbe的如下属性字段来给出：
initialDelaySeconds：存活性探测延迟时长，即容器启动多久之后再开始第一次探测操作，显示为delay属性；默认为0s，即容器启动后立刻便开始进行探测。
timeoutSeconds：存活性探测的超时时长，显示为timeout属性，默认为1s，最小值也是1s。
periodSeconds：存活性探测的频度，显示为period属性，默认为10s，最小值为1s；过高的频率会对pod对象带来较大的额外开销，而过低的频率又会使得对错误的反应不及时。
successThreshold：处于失败状态时，探测操作至少连续多少次的成功才被认为是通过检测，显示为success属性，默认值为1，最小值也为1。
failureThreshold：处于成功状态时，探测操作至少连续多少次的失败才被视为检测不通过，显示为failure属性，默认值为3，最小值为1。
二、pod就绪行探测
pod对象启动后，容器应用通常需要一段时间才能完成其初始化过程，避免pod对象启动后立即让其处理客户端请求，而等待容器初始化工作执行完成并转为就绪状态，尤其是存在其他提供相同服务的pod对象的场景更是如此。
与存活性探测机制相同，就绪性探测也支持Exec、HTTP GET和TCPSocket三种探测方式，且各自的定义机制也都相同。但与存活性探测触发的操作不同的是，探测失败时，就绪性探测不会杀死或重启容器以保证其健康性，而是通知其尚未就绪，并触发依赖于其就绪状态的操作（例如，从service对象中移除此pod对象）以确保不会有客户端请求接入此pod对象。未定义就绪性探测的pod对象在pod进入running状态后将立即就绪，在容器需要时间进行初始化的场景中，在应用真正就绪之前必然无法正常相应客户端请求，因此，生成时间中，必须为关键性pod资源中的容器定义就绪性探测机制。
将容器定义中的livenessProbe字段替换为readinessProbe即可定义就绪性探测的配置。