10-k8s中pod的探针

Linux高级---k8s三种探针readinessProbe、livenessProbe和startupProbe-CSDN博客

存活探针(Liveness)、就绪探针(Readiness)、启动探针(Startup)_readinessprobe和livenessprobe-CSDN博客

一、POD状态

1、POD常见的状态

1) Pending：挂起，我们在请求创建pod时，条件不满足，调度没有完成，没有任何一个节点能满足调度条件。已经创建了但是没有适合它运行的节点叫做挂起，这其中也包含集群为容器创建网络，或者下载镜像的过程。    

2) Running：Pod内所有的容器都已经被创建，且至少一个容器正在处于运行状态、正在启动状态或者重启状态。    

3) Succeeded：Pod中所以容器都执行成功后退出，并且没有处于重启的容器。

4) Failed：Pod中所以容器都已退出，但是至少还有一个容器退出时为失败状态。

5) Unknown：未知状态，所谓pod是什么状态是apiserver和运行在pod节点的kubelet进行通信获取状态信息的，如果节点之上的kubelet本身出故障，那么apiserver就连不上kubelet，得不到信息了，就会看Unknown

2、POD重启策略

Always: 只要容器失效退出就重新启动容器。
OnFailure: 当容器以非正常(异常)退出后才自动重新启动容器。
Never: 无论容器状态如何，都不重新启动容器。

如果pod的restartpolicy没有设置，那么默认值是Always。

二、就绪、存活两种探针

​​​​​K8S 提供了3种探针

存活探针(Liveness)

就绪探针(Readiness)

启动探针(Startup)（这个1.16版本增加的）

0、探针介绍

在 Kubernetes 中 Pod 是最小的计算单元，而一个 Pod 又由多个容器组成，相当于每个容器就是一个应用，应用f服务在运行期间，可能因为某也意外情况致使程序挂掉。

那么如何监控这些容器状态稳定性，保证应用服务在运行期间不会发生问题，发生问题后进行重启等机制，就成为了重中之重的事情，考虑到这点 kubernetes 推出了存活探针机制。

有了存活性探针能保证程序在运行中如果挂掉能够自动重启，但是还有个经常遇到的问题，比如说，在Kubernetes 中启动Pod，显示明明Pod已经启动成功，且能访问里面的端口，但是却返回错误信息。还有就是在执行滚动更新时候，总会出现一段时间，Pod对外提供网络访问，但是访问却发生404，这两个原因，都是因为Pod已经成功启动，但是 Pod 的的容器中应用程序还在启动中导致，考虑到这点Kubernetes推出了就绪性探针机制。

1、livenessProbe存活探针

livenessProbe：存活性探针，用于判断容器本身是不是健康，如果不健康，那么 Kubelet 将根据 Pod 中设置的 restartPolicy （重启策略）来判断，Pod 是否要进行重启操作。

livenessProbe按照配置去探测 ( 进程、或者端口、或者命令执行后是否成功等等)，来判断容器是不是正常。如果探测不到，代表容器不健康（可以配置连续多少次失败才记为不健康），则 kubelet 会杀掉该容器，并根据容器的重启策略做相应的处理。

简短总结：

- 当我们设置了这个探针之后，检查不通过，pod容器就会重启，周期性检查服务是否存在；

- 检查若失败，将“重启容器”，本质上就是删除原来的容器，重新创建；

- 若没设置健康检查探针，默认就是成功的，检查成功；

2、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中。

简短总结：

    - 当我们设置这个探针之后，检查不通过，pod容器不会重启，周期性检查服务是否可用，从而判断容器是否准备就绪；

   - 若检查服务不可用，就是检查失败，则会将pod从service的endppints列表中移除；

   - 若检查可用，则会将pod重新添加会secvice的endppints列表中；

   - 若不设置这个探针，则默认是检查成功状态；

3、就绪、存活两种探针的区别

ReadinessProbe 和 livenessProbe 可以使用相同探测方式，只是对 Pod 的处置方式不同：
readinessProbe 当检测失败(应用服务没启动成功)后，只是将 Pod 的 IP:Port 从对应的 EndPoint 列表中删除，并不会删除容器重启容器。
livenessProbe 当检测失败(容器没启动成功)后，将删除容器并根据 Pod 的重启策略来决定作出对应的措施。

readinessProbe失败并不会导致重启pod，只有startupProbe、livenessProbe失败才会重启pod；

4、就绪、存活探针的使用方法

目前 LivenessProbe 和 ReadinessProbe 两种探针都支持下面三种探测方法：

1，命令检查：exec：就是在容器中执行一段命令，根据返回的结果判断是否成功，返回0或者非0（类似shell中echo $?）。如果执行成功，退出码为 0 则探测成功。

2，http请求检查：httpGet：根据返回的状态码，判断是否正常；通过容器的IP地址、端口号及路径调用 HTTP Get方法，如果响应的状态码大于等于200且小于400，则认为容器 健康。

3，端口检查：tcpSocket：通过容器的 IP 地址和端口号执行 TCP 检 查，如果能够建立 TCP 连接，则表明容器健康。类似于telnet，nc等网络工具；
 
探针探测结果有以下值：
Success：表示通过检测。
Failure：表示未通过检测。
Unknown：表示检测没有正常进行。

LivenessProbe 和 ReadinessProbe 两种探针的相关属性

探针(Probe)有许多可选字段，可以用来更加精确的控制Liveness和Readiness两种探针的行为(Probe)：
 
initialDelaySeconds：表示在容器启动后延时多久秒才开始探测，单位“秒”，默认是 0 秒，最小值是 0

periodSeconds：表示执行探测的频率，即间隔多少秒探测一次，默认间隔周期是10秒，最小1秒；

timeoutSeconds：表示探测超时时间，默认1秒，最小1秒，表示容器必须在超时时间范围内做出响应，否则视为本次探测失败；

successThreshold：表示最少连续探测成功多少次才被认定为成功，默认是1，对于liveness必须是1，最小值是1；

failureThreshold：表示连续探测失败多少次才被认定为失败，默认是3，连续3次失败，k8s 将根据pod重启策略对容器做出决定；
 

注意1：定义存活探针时，一定要设置initialDelaySeconds属性，该属性为初始延时，如果不设置，默认容器启动时探针就开始探测了，这样可能会存在应用程序还未启动就绪，就会导致探针检测失败，k8s就会根据pod重启策略杀掉容器然后再重新创建容器的莫名其妙的问题。

在生产环境中，一定要定义一个存活探针。

注意2：initialDelaySeconds在readinessProbe其实可以不用配置，不配置默认pod刚启动，开始进行readinessProbe探测，但那有怎么样，除了
startupProbe，readinessProbe、livenessProbe运行在pod的整个生命周期，刚启动的时候readinessProbe检测失败了，只不过显示READY状态一直是0/1，readinessProbe失败并不会导致重启pod，只有startupProbe、livenessProbe失败才会重启pod。而等到多少s后，真正服务启动后，检查success成功后，READY状态自然正常；

5、startupProbe探针

startupProbe 启动探针，startupProbe探针是1.16版本加入的探针，用于判断容器进程是否已经启动，主要解决在慢启动程序或复杂程序中readinessProbe、livenessProbe探针无法较好的判断程序是否启动、是否存活。引入startupProbe探针是为readinessProbe、livenessProbe探针服务。

当配置了startupProbe启动探针，会先禁用其他探针，直到startupProbe探针成功，成功后将退出不在进行探测，如果startupProbe探针探测失败，pod将会重启。

简短总结：

        从k8s的1.16版本之后才新加的功能，1.16版本之前没有这个探针；

        - 如果设置了这个探针，则其他所有探针都会被禁用，指导这个探针检查成功为止；

        - 如果检查失败，kubelet会杀死容器，而容器依照我们的重启策略进行重启；

        - 如果没有设置这个探针，默认是成功状态；

6、三个探针的执行顺序

如果三个探针同时存在，则先执行startupProbe探针，其他两个探针将会被暂时禁用，直到startupProbe一次探测成功，其他2个探针才启动；如果startupProbe探测失败，kubelet 将杀死容器，并根据restartPolicy重启策略来判断容器是否要进行重启操作。

就绪探针与存活探针之间的重要区别：如果容器未通过准备检查，则不会被终止或重新启动

存活探针：通过杀死异常的容器，并用新的正常容器替代他们来保持Pod正常工作
就绪探针：确保只有准备好处理请求的Pod才可以接收探针请求

三、livenessProbe健康检查探针

1，exec方式

[root@k8s231 pod]# cat 13-probe.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: mylinux-livenessprobe
spec:
  containers:
  - name: c1
    image: nginx:1.20.1-alpine
    #声明健康检查探针livenessProbe
    livenessProbe:
      #使用exec方式做检查；
      exec:
        #自定义检查命令
        command:
        - cat
        - /etc/hosts
      #检查失败几次算【不存活】，默认值是3，最小值是1，检查成功后，值会重置重1开始数；
      failureThreshold: 3
      #容器启动后多久开始进行健康检查，即此时间段内，检测到服务失败并不计数；默认1，最小值1
      initialDelaySeconds: 15
      #探针检测频率，多久检测一次，默认10（秒），最小值1（秒）
      periodSeconds: 1
      #检查成功几次算【存活】，默认1，最小值1
      successThreshold: 1
      #一次检查超时时间，默认1（秒），最小值1（秒）
      timeoutSeconds: 1

[root@k8s231 pod]# kubectl apply -f 13-probe.yaml

#下面将删除容器，看存活探针是否生效
[root@k8s232 ~]# docker kill 9c58681295c3   #删掉容器
[root@k8s231 pod]# kubectl get pods  
NAME                    READY   STATUS    RESTARTS      AGE
m-nginx-k8s231          1/1     Running   0             23m
m12                     1/1     Running   0             19m
mylinux-livenessprobe   1/1     Running   1 (10s ago)   12m
pod容器重启了1次，说明容器挂过后自动重启，验证存活探针成功

2，httpGet检查方式

[root@k8s231 pod]# cat 12-probe.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: mylinux-livenessprobe
spec:
  containers:
  - name: c1
    image: nginx:1.20.1-alpine
    #声明健康检查探针livenessProbe
    livenessProbe:
      #使用httpGet方式做检查；
      httpGet:
        #检查那个端口，通过哪个端口访问页面？
        port: 80
        #指定探测的页面路径
        path: /usr/share/nginx/html/index.html
      #检查失败几次算【不存活】，默认值是3，最小值是1，检查成功后，值会重置重1开始数；
      failureThreshold: 3
      #容器启动后多久开始进行健康检查，即此时间段内，检测到服务失败并不计数；默认1，最小值1
      initialDelaySeconds: 15
      #探针检测频率，多久检测一次，默认10（秒），最小值1（秒）
      periodSeconds: 1
      #检查成功几次算【存活】，默认1，最小值1
      successThreshold: 1
      #一次检查超时时间，默认1（秒），最小值1（秒）
      timeoutSeconds: 1

验证httpGet方式的存活探针是否生效：

[root@k8s231 pod]# kubectl exec mylinux-livenessprobe -it -- sh
/ # ls
bin                   home                  proc                  sys
dev                   lib                   root                  tmp
docker-entrypoint.d   media                 run                   usr
docker-entrypoint.sh  mnt                   sbin                  var
etc                   opt                   srv
/ # rm -rf /usr/share/nginx/html/index.html
/ # command terminated with exit code 137
[root@k8s231 pod]# kubectl get pods
NAME                    READY   STATUS    RESTARTS     AGE
m-nginx-k8s231          1/1     Running   0            36m
m12                     1/1     Running   0            32m
mylinux-livenessprobe   1/1     Running   2 (7s ago)   41s

[root@k8s231 pod]# kubectl describe pod mylinux-livenessprobe

Events:
  Type     Reason     Age                 From               Message
  ----     ------     ----                ----               -------
  Normal   Scheduled  109s                default-scheduler  Successfully assigned default/mylinux-livenessprobe to k8s232
  Normal   Pulled     58s (x4 over 109s)  kubelet            Container image "nginx:1.20.1-alpine" already present on machine
  Normal   Created    58s (x4 over 109s)  kubelet            Created container c1
  Normal   Started    58s (x4 over 109s)  kubelet            Started container c1
  Normal   Killing    58s (x3 over 92s)   kubelet            Container c1 failed liveness probe, will be restarted
  Warning  Unhealthy  43s (x10 over 94s)  kubelet            Liveness probe failed: HTTP probe failed with statuscode: 404

3，tcpSocket检测方式

[root@k8s231 pod]# cat 12-probe.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: mylinux-livenessprobe
spec:
  containers:
  - name: c1
    image: nginx:1.20.1-alpine
    #声明健康检查探针livenessProbe
    livenessProbe:
      #使用tcpSocket方式做检查；
      tcpSocket:
        #检查哪一个端口
        port: 80
      failureThreshold: 3
      initialDelaySeconds: 15
      periodSeconds: 1
      successThreshold: 1
      timeoutSeconds: 1

四、readinessProbe可用性探针检查

[root@k8s231 pod]# cat 12-probe.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: mylinux-livenessprobe
spec:
  containers:
  - name: c1
    image: nginx:1.20.1-alpine
    #声明健康检查探针readinessProbe
    readinessProbe:
      #使用tcpSocket方式做检查；
      tcpSocket:
        #检查哪一个端口
        port: 80
      failureThreshold: 3
      initialDelaySeconds: 15
      periodSeconds: 1
      successThreshold: 1
      timeoutSeconds: 1

五、startupProbe启动探针检查

[root@k8s231 pod]# cat 12-probe.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: mylinux-livenessprobe
spec:
  containers:
  - name: c1
    image: nginx:1.20.1-alpine
    #声明启动探针startupProbe
    startupProbe:
      tcpSocket:
        port: 80
      failureThreshold: 3
      initialDelaySeconds: 15
      periodSeconds: 1
      successThreshold: 1
      timeoutSeconds: 1

六、三个探针一起使用

[root@k8s231 pod]# cat 12-probe.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: mylinux-livenessprobe
spec:
  containers:
  - name: c1
    image: nginx:1.20.1-alpine
    #声明启动探针startupProbe
    startupProbe:
      tcpSocket:
        port: 80
      failureThreshold: 3
      initialDelaySeconds: 15
      periodSeconds: 1
      successThreshold: 1
      timeoutSeconds: 1
    #声明启动探针livenessProbe
    livenessProbe:
      tcpSocket:
        port: 80
      failureThreshold: 3
      initialDelaySeconds: 15
      periodSeconds: 1
      successThreshold: 1
      timeoutSeconds: 1
    #声明启动探针readinessProbe
    readinessProbe:
      tcpSocket:
        port: 80
      failureThreshold: 3
      initialDelaySeconds: 15
      periodSeconds: 1
      successThreshold: 1
      timeoutSeconds: 1