• readiness probe（就绪探针）

• 用于判断容器是否启动完成，即容器的Ready是否为True，可以接收请求，如果ReadinessProbe探测失败，则容器的Ready将为False，控制器将此Pod的Endpoint从对应的service的Endpoint列表中移除，从此不再将任何请求调度此Pod上，直到下次探测成功。通过使用Readiness探针，Kubernetes能够等待应用程序完全启动，然后才允许服务将流量发送到新副本。

• 比如使用tomcat的应用程序来说，并不是简单地说tomcat启动成功就可以对外提供服务的，还需要等待spring容器初始化，数据库连接没连上等等。对于spring boot应用，默认的actuator带有/health接口，可以用来进行启动成功的判断。

• liveness probe（存活探针）

• 用于判断容器是否存活，即Pod是否为running状态，如果LivenessProbe探针探测到容器不健康，则kubelet将kill掉容器，并根据容器的重启策略是否重启。如果一个容器不包含LivenessProbe探针，则Kubelet认为容器的LivenessProbe探针的返回值永远成功。

• 有时应用程序可能因为某些原因（后端服务故障等）导致暂时无法对外提供服务，但应用软件没有终止，导致K8S无法隔离有故障的pod，调用者可能会访问到有故障的pod，导致业务不稳定。K8S提供livenessProbe来检测应用程序是否正常运行，并且对相应状况进行相应的补救措施。
  

• 例1. 基于TCP的存活性探测(TCPSocketAction)用于向容器的特定端口发起TCP请求并尝试建立连接，连接成功即为通过检测。

cat <<END>nginx.yaml
kind: Deployment
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:alpine
        ports:
          - containerPort: 80
        livenessProbe:
          initialDelaySeconds: 15
          tcpSocket:
            port: 80
          periodSeconds: 300
          timeoutSeconds: 10
          failureThreshold:  2
---
apiVersion: v1
kind: Service
metadata:
  name: nacos-hs
spec:
  clusterIP: None
  ports:
  - name: http
    port: 80
    protocol: TCP
    targetPort: 80
  type: ClusterIP
  selector:
    app: nginx
END
复制

• 检测80是否存在

livenessProbe: 
  initialDelaySeconds: 15 #pod启动10秒执行第一次检查
  tcpSocket:  #检测80是否存在
    port: 80
  periodSeconds: 300  #第一次检查后每隔300秒检查一次
  timeoutSeconds: 3  # 检查超时的时间，默认为1秒，最小为1秒
  failureThreshold: 3        #最少连续探测失败多少次才被认定为失败
复制

• 两个同时使用，Kubelet将尝试在指定的端口上打开容器上的套接字，如果能建立连接，则表明容器健康

      - name: nginxhttps
        image: ymqytw/nginxhttps:1.5
        command: ["/home/auto-reload-nginx.sh"]
        ports:
          - containerPort: 80
        livenessProbe:
          tcpSocket:
            port: 80
          initialDelaySeconds: 30
          periodSeconds: 15
          successThreshold: 1
          failureThreshold: 3
          timeoutSeconds: 1
		  
        readinessProbe:
          tcpSocket:
            port: 80
          initialDelaySeconds: 30
          periodSeconds: 10
          successThreshold: 1
          failureThreshold: 3
          timeoutSeconds: 1
复制

• TCP检查方式和HTTP检查方式非常相似，示例中两种探针都使用了，在容器启动5秒后，kubelet将发送第一个readinessProbe探针，这将连接到容器的80端口，如果探测成功，则该Pod将被标识为ready，10秒后，kubelet将进行第二次连接.除此之后，此配置还包含了livenessProbe探针，在容器启动15秒后，kubelet将发送第一个livenessProbe探针，仍然尝试连接容器的80端口，如果连接失败则重启容器。

• ReadinessProbe探针配置

• 1 ReadinessProbe探针的使用场景livenessProbe稍有不同，有的时候应用程序可能暂时无法接受请求，比如Pod已经Running了，但是容器内应用程序尚未启动成功，在这种情况下，如果没有ReadinessProbe，则Kubernetes认为它可以处理请求了，然而此时，我们知道程序还没启动成功是不能接收用户请求的，所以不希望kubernetes把请求调度给它，则使用ReadinessProbe探针。

• 2 ReadinessProbe和livenessProbe可以使用相同探测方式，只是对Pod的处置方式不同，ReadinessProbe是将Pod IP:Port从对应的EndPoint列表中删除，而livenessProbe则Kill容器并根据Pod的重启策略来决定作出对应的措施。

• 3 ReadinessProbe探针探测容器是否已准备就绪，如果未准备就绪则kubernetes不会将流量转发给此Pod

• 5 ReadinessProbe探针与livenessProbe一样也支持exec、httpGet、TCP的探测方式，配置方式相同，只不过是将livenessProbe字段修改为ReadinessProbe。

readinessProbe:
 exec:
   command:
   - cat
   - /tmp/healthy
 initialDelaySeconds: 5
 periodSeconds: 5
复制

• pods没有健康检测的情况下，默认是监听主进程，如果主进程不再了，pods就会重启重新初始化