一.探针简介

  在 Kubernetes 中 Pod 是最小的计算单元，而一个 Pod 又由多个容器组成，
相当于每个容器就是一个应用，应用在运行期间，可能因为某也意外情况致使程序挂掉。
那么如何监控这些容器状态稳定性，保证服务在运行期间不会发生问题，发生问题后进行重启等机制，
就成为了重中之重的事情，考虑到这点 kubernetes 推出了活性探针机制。
有了存活性探针能保证程序在运行中如果挂掉能够自动重启，但是还有个经常遇到的问题，比如说，
在Kubernetes 中启动Pod，显示明明Pod已经启动成功，且能访问里面的端口，但是却返回错误信息。还有就是在执行滚动更新时候，
总会出现一段时间，Pod对外提供网络访问，但是访问却发生404，这两个原因，都是因为Pod已经成功启动，但是 Pod 的的容器中应用程序还在启动中导致，
考虑到这点Kubernetes推出了就绪性探针机制。

二.k8s探针

1.startupProbe(启动探针)

k8s 在1.16版本后增加startupProbe探针，
主要解决在复杂的程序中readinessProbe、livenessProbe探针无法更好的判断程序是否启动、是否存活。
进而引入startupProbe探针为readinessProbe、livenessProbe探针服务。

2.livenessProbe(存活探针)

livenessProbe：存活性探针，用于判断容器是不是健康，如果不满足健康条件，
那么 Kubelet 将根据 Pod 中设置的 restartPolicy （重启策略）来判断，Pod 是否要进行重启操作。
LivenessProbe按照配置去探测 ( 进程、或者端口、或者命令执行后是否成功等等)，来判断容器是不是正常。
如果探测不到，代表容器不健康（可以配置连续多少次失败才记为不健康），
则 kubelet 会杀掉该容器，并根据容器的重启策略做相应的处理。如果未配置存活探针，
则默认容器启动为通过（Success）状态。即探针返回的值永远是 Success。即Success后pod状态是RUNING

3.readinessProbe(就绪探针)

readinessProbe 就绪性探针，用于判断容器内的程序是否存活（或者说是否健康），
只有程序(服务)正常， 容器开始对外提供网络访问（启动完成并就绪）。
容器启动后按照readinessProbe配置进行探测，无问题后结果为成功即状态为 Success。
pod的READY状态为 true，从0/1变为1/1。如果失败继续为0/1，状态为 false。
若未配置就绪探针，则默认状态容器启动后为Success。
对于此pod、此pod关联的Service资源、EndPoint 的关系也将基于 Pod 的 Ready 状态进行设置，
如果 Pod 运行过程中 Ready 状态变为 false，则系统自动从 Service资源 关联的 EndPoint 列表中去除此pod，
届时service资源接收到GET请求后，kube-proxy将一定不会把流量引入此pod中，
通过这种机制就能防止将流量转发到不可用的 Pod 上。如果 Pod 恢复为 Ready 状态。将再会被加回 Endpoint 列表。
kube-proxy也将有概率通过负载机制会引入流量到此pod中。

4.探针的区别

startupProbe: 如果三个探针同时存在，先执行startupProbe探针，其他两个探针将会被暂时禁用，直到pod满足startupProbe探针配置的条件，其他2个探针启动，如果不满足按照规则重启容器
另外两种探针在容器启动后，会按照配置，直到容器消亡才停止探测，而startupProbe探针只是在容器启动后按照配置满足一次后，不在进行后续的探测。
livenessProbe: 当检测失败后，将杀死容器并根据 Pod 的重启策略来决定作出对应的措施。
readinessProbe: 当检测失败后，将 Pod 的 IP:Port 从对应的 EndPoint 列表中删除。

5.探针方法、属性

ExecAction：在容器中执行指定的命令，如果执行成功，退出码为 0 则探测成功。
HTTPGetAction：通过容器的IP地址、端口号及路径调用 HTTP Get方法，如果响应的状态码大于等于200且小于400，则认为容器 健康。
TCPSocketAction：通过容器的 IP 地址和端口号执行 TCP 检 查，如果能够建立 TCP 连接，则表明容器健康。

探针探测结果有以下值：
Success：表示通过检测。
Failure：表示未通过检测。
Unknown：表示检测没有正常进行。

6.探针的相关属性和配置

initialDelaySeconds：容器启动后要等待多少秒后就探针开始工作，单位“秒”，默认是 0 秒，最小值是 0
periodSeconds：执行探测的时间间隔（单位是秒），默认为 10s，单位“秒”，最小值是 1
timeoutSeconds：探针执行检测请求后，等待响应的超时时间，默认为 1s，单位“秒”，最小值是 1
successThreshold：探针检测失败后认为成功的最小连接成功次数，默认为 1s，在 Liveness 探针中必须为 1s，最小值为 1s。
failureThreshold：探测失败的重试次数，重试一定次数后将认为失败，在 readiness 探针中，Pod会被标记为未就绪，默认为 3s，最小值为 1s
 
注：initialDelaySeconds在readinessProbe其实可以不用配置，不配置默认pod刚启动，开始进行readinessProbe探测，但那有怎么样，除了
startupProbe，readinessProbe、livenessProbe运行在pod的整个生命周期，刚启动的时候readinessProbe检测失败了，只不过显示READY状
态一直是0/1，readinessProbe失败并不会导致重启pod，只有startupProbe、livenessProbe失败才会重启pod。而等到多少s后，真正服务启动
后，检查success成功后，READY状态自然正常
注：在startupProbe执行完之后，其他2种探针的所有配置才全部启动，相当于容器刚启动的时候，所以其他2种探针如果配置了initialDelaySeconds，建议不要给太长

三.配置探针

1.配置startupProbe

        startupProbe:
          httpGet:           #使用http的方法检测
            port: 80         #检测端口为80
            path: /          #检测目录为主页
          initialDelaySeconds: 5   #pod启动后延迟5秒进行检测
          periodSeconds: 5         #重试时间间隔
          timeoutSeconds: 5        #超时时间设置

2.配置livenessProbe

        livenessProbe:
          tcpSocket:          #TCP方式做健康探测
            port: 8080        #检测端口为8080
          initialDelaySeconds: 300   #pod启动后延迟300秒进行检测
          periodSeconds: 18000    #重试时间间隔
          timeoutSeconds: 5       #超时时间设置
          failureThreshold: 3     #检测失败3次表示未就绪

3.配置readinessProbe

      readinessProbe:
        initialDelaySeconds: 10   #延迟检测时间
        periodSeconds: 5          #检测时间间隔
        exec:                     #使用命令检查
          command:                #指令，类似于运行命令sh
          - cat                   #sh 后的第一个内容，直到需要输入空格，变成下一行
          - /tmp/healthy          #由于不能输入空格，需要另外声明，结果为sh cat"空格"/tmp/healthy