侧边栏壁纸
博主头像
cloudnative-blog博主等级

I can break through the limitations !

  • 累计撰写 23 篇文章
  • 累计创建 12 个标签
  • 累计收到 1 条评论

目 录CONTENT

文章目录

五.探针

周锐豪
2024-01-04 / 0 评论 / 0 点赞 / 24 阅读 / 4269 字 / 正在检测是否收录...

一.探针简介

  在 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
0

评论区