|NO.Z.00125|——————————|CloudNative|——|KuberNetes&基础标签.V08|——|pod三种探针.V01|

一、Pod探针概述

### --- Pod探针startupProbe

~~~     StartupProbe：k8s1.16版本后新加的探测方式，用于判断容器内应用程序是否已经启动。
~~~     如果配置了startupProbe，就会先禁止其他的探测，直到它成功为止，成功后将不在进行探测。

### --- pod探针LivenessProbe

~~~     # LivenessProbe：用于探测容器是否运行，
~~~     如果探测失败，kubelet会根据配置的重启策略进行相应的处理。
~~~     若没有配置该探针，默认就是success。

### --- pod探针readinessProbe

~~~     # ReadinessProbe：一般用于探测容器内的程序是否健康，它的返回值如果为success，
~~~     那么久代表这个容器已经完成启动，并且程序已经是可以接受流量的状态。

### --- Pod探针的检测方式

~~~     ExecAction：在容器内执行一个命令，如果返回值为0，则认为容器健康。
~~~     TCPSocketAction：通过TCP连接检查容器内的端口是否是通的，如果是通的就认为容器健康。
~~~     HTTPGetAction：通过应用程序暴露的API地址来检查程序是否是正常的，如果状态码为200~400之间，则认为容器健康。

### --- 探针检查参数配置：

initialDelaySeconds: 60                                                             // 初始化时间
timeoutSeconds: 2                                                                   // 超时时间
periodSeconds: 5                                                                    // 检测间隔
successThreshold: 1                                                                 // 检查成功为1次表示就绪
failureThreshold: 2                                                                 // 检测失败2次表示未就绪；不能设置太大。

### --- 补充说明

~~~     # HTTPGetAction在生产环境中用的是比较多的，ExecAction，TCPSocketAction是不可靠的，
~~~     TCPSocketAction有一种假死现象是检测不到的，
~~~     比如端口是通的，但是不能连接，程序假死的现象。

~~~     # 请求容器的某一个逻辑处理接口，就是不工作，是不可靠的，最可靠的是HTTPGetAction；
~~~     可以和开发协调让暴露出来两个健康检查接口，
~~~     一个是决定LivenessProte检查程序是否是可以正常运行的，
~~~     只要这个接口通，就不杀死它，等待它启动，因为程序可能启动会特别慢，
~~~     # 第二个是ReadinessProbe：这个接口通，说明他是可以接收流量的，
~~~     可以吧Pod的状态设置为Read，就可以接收流量了。

二、查看官方探针检查配置

### --- 查看kube-system这个命名空间下这个deployment的探针健康检查是怎么做的
~~~~    查看deployment容器

[root@k8s-master01 ~]# kubectl get deployment -n kube-system
NAME                      READY   UP-TO-DATE   AVAILABLE   AGE
calico-kube-controllers   1/1     1            1           5d22h
coredns                   1/1     1            1           5d22h
metrics-server            1/1     1            1           5d22h

### --- 查看deployment探针检查配置

~~~     若是配置了LivenessProbe；那么这个容器就不会被杀掉，决定了这个Pod会不会被重启；
~~~     若是你的健康检查过了的情况下，他就不会被重启。
~~~     它提供了一个health接口，告诉kubelet只要我过了你就不要杀我的容器。
~~~     因为我的8080端口起来了。并不代表我的这个程序就能接收流量了。
~~~     因为我还有一些触发操作没有完成。所以它配置了一个LivenessProbe，可能会有一些初始化操作
~~~     若是我这个端口是通的，就在endpoint把我给加上，这样就可以接收流量，可以进行工作了。

~~~     # edit：
~~~     是在线编辑资源文件，若是后面没有跟deploy的资源名称的话，
~~~     就会把kube-system这个命名空间下的所有

[ root@k8s-master01 ~]# kubectl edit deploy coredns -n kube-system                  
# 第一个LivenessProbe：
        livenessProbe:
          failureThreshold: 5
          httpGet:
            path: /health                   // 请求了8080端口的一个health的接口
            port: 8080                      // 请求了一个8080端口
            scheme: HTTP                
# 什么时候可以接受流量呢？readinessProbe来配置
        readinessProbe:
          failureThreshold: 3
          httpGet:
            path: /ready
            port: 8181                      // 提供了8181端口，
            scheme: HTTP

### --- 它是没有配置startupProbe：既然有了LivenessProbe和readinessProbe，
~~~     # 为什么还要有startupProbe呢？

~~~     # 在我们的应用程序中比如配置了一个health，假设你的接口返回是正常的，
~~~     但是你的readinessProbe就是一直不过，
~~~     那么这个Pod的状态就是一直就是没有ready的状态，也就一直不能处理我们的请求。

~~~     # 我们这个程序正在运行的过程中，readinessProbe突然不通了，它的返回值不为0，
~~~     LivenessProbe的返回值还为0；可能会造成它的容器不会被重启掉，
~~~     而readinessProbe的返回值还是为0。所以他就会出现一直不可接受流量的状态。
~~~     若是你的多个副本都出与这种情况，那么你的这个容器就挂了。
~~~     # 比如LivenessProbe配置了health的接口，初始化时间设置的是60s;
~~~     可以等到60s之后再去检查，比如说我们部署的Java应用，
~~~     它的应用程序在60s起不来；就会进入一个死循环的状态；
~~~     就是健康检查没有过，初始化时间也过了；这样kubelet会认为你的程序是不正常的。

~~~     # 它会把你的应用程序给杀掉。程序被杀掉之后，这个程序会再启动，
~~~     但是间隔时间：failureThreshold：5错误次数+periodSeconds：10+timeoutSeconds：5=250s
~~~     若是你的程序已经是错误的状态了，
~~~     但是你需要检查10次每次5秒超时且要失败5次，也就是250秒之后才会重启。
~~~     # 在启动的过程中也是一样的，初始化时间已经过了，
~~~     但是还没有启动，kubelet就会把它杀掉，就会再次启动，陷入了一个死循环。

Walter Savage Landor:strove with none,for none was worth my strife.Nature I loved and, next to Nature, Art:I warm'd both hands before the fire of life.It sinks, and I am ready to depart

——W.S.Landor