17、Health Check 健康检查

这篇具有很好参考价值的文章主要介绍了17、Health Check 健康检查。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

强大的自愈能力是kubernetes容器编排引擎的重要特性。 自愈的默认实现方式是自动重启发生故障的容器。除此之外,还可通过 Liveness和Readiness探测机制设置更精细的健康检查,进而实现如下要求:
  1. 零停机部署
  2. 避免部署无效的镜像
  3. 更加安全的滚动升级

一、Liveness探测 VS Readiness探测

  1. Liveness探测和Readiness探测是两种healthy check机制,若不特意配置,kubernetes将对两种探测采取相同的默认行为,即通过判断容器启动进程的返回值( echo $?)是否为零来判断探测是否成功。
  2. 两种探测的配置方法完全一样,支持的配置参数也一样。 不同之处在于探测失败后的行为:Liveness 探测是重启容器;Readiness 探测则是将容器设置为不可用,不接收 Service 转发的请求
  3. Liveness 探测和 Readiness 探测是独立执行的,二者之间没有依赖,所以 可以单独使用,也可以同时使用用 Liveness 探测判断容器是否需要重启以实现自愈;用 Readiness 探测判断容器是否已经准备好对外提供服务
17、Health Check 健康检查

1.1、每类探针都支持三种探测方法

  • exec: 通过执行命令来检查服务是否正常, 针对复杂检测或无 HTTP 接口的服务, 命 令返回值为 0 则表示容器健康。
  • httpGet : 通过发送 http 请求检查服务是否正常, 返回 200-400 状态码则表明容器健 康。
  • tcpSocket : 通过容器的 IP 和 Port 执行 TCP 检查, 如果能够建立 TCP 连接, 则表明 容器健康。
17、Health Check 健康检查

1.2、探针探测的结果

  • Success: Container 通过了检查。
  • Failure: Container 未通过检查。
  • Unknown: 未能执行检查, 因此不采取任何措施。

1.3、Pod 重启策略 restartpolicy

  • Always: 总是重启
  • OnFailure: 如果失败就重启
  • Never: 永远不重启

二、默认的健康检查

每个容器启动时都会执行一个进程,此进程由Dockerfile的CMD或ENTRYPOINT指定。如果 进程退出时返回码非零,则认为容器发生故障,kubernetes会根据restartPolicy重启容器。
模拟容器发生故障的场景,Pod配置文件如下:
apiVersion: v1
kind: Pod
metadata:
  name: healthcheck
  labels:
    test: healthcheck
spec:
  restartPolicy: OnFailure # 默认为Always
  containers:
  - name: healthcheck
    image: busybox
    args:
    - /bin/sh
    - -c
    - sleep 10; exit 1   # 模拟容器启动 10 秒后发生故障
17、Health Check 健康检查
可见容器当前已经重启了3次。
上述例子是容器进程返回值非0,kubernetes认为容器发生故障,重启。但在某些时候进程并不会退出,比如访问 Web 服务器时显示 500 内部错误,可能是系统超载,也可能是资源死锁,此时进程并没有异常退出,在这种情况下重启容器可能是最直接最有效的解决方案,那我们如何利用 Health Check 机制来处理这类场景呢?-----答案就是 Liveness 探测

 2.1、Liveness探测

Liveness探测让用户自定义判断容器是否健康的条件,若探测失败,kubernetes就会重启容器。
Pod配置文件如下:
apiVersion: v1
kind: Pod
metadata:
  name: liveness
  labels:
    test: liveness
spec:
  restartPolicy: OnFailure # 默认为Always
  containers:
  - name: liveness
    image: busybox
    args:
    - /bin/sh
    - -c
    - touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600
    livenessProbe:
      exec:
        command:
        - cat
        - /tmp/healthy
      initialDelaySeconds: 10 # 指定容器启动10s后开始执行Liveness探测
      periodSeconds: 5 # 指定每5s执行一次Liveness探测,默认是10s,最小是1s
      timeoutSeconds: 1 # 探测超时时间,默认是1s,最小是1s

启动进程首先创建文件/tmp/healthy,30s后删除,如果/tmp/healthy文件存在,则认为容器处于正常状态,反之则发生故障。文章来源地址https://www.toymoban.com/news/detail-468782.html

livenessProbe部分定义如何执行Liveness探测:
  1. 探测的方法:通过cat检查/tmp/healthy文件是否存在。若命令执行成功,返回值为0,kubernetes则认为本次Liveness探测成功;若命令返回值非0,本次Liveness探测失败;
  2. initialDelaySeconds:10,指定容器启动10s后开始执行Liveness探测,一般会根据应用启动的准备时间来设置。比如某个应用正常启动要花 30 秒,那么 initialDelaySeconds 的值就应该大于 30;
  3. periodSeconds:5,指定每5s执行一次Liveness探测。 Kubernetes 如果连续执行 3 次 Liveness 探测均失败,则会杀掉并重启容器
下面创建 Pod liveness:
17、Health Check 健康检查
从配置文件可知,最开始的 30 秒,/tmp/healthy 存在,cat 命令返回 0,Liveness 探测成功,这段时间 kubectl describe pod liveness 的 Events部分会显示正常的日志:
17、Health Check 健康检查
17、Health Check 健康检查
35 秒之后,日志会显示 /tmp/healthy 已经不存在,Liveness 探测失败。再过几十秒,几次探测都失败后,容器会被重启。
17、Health Check 健康检查
17、Health Check 健康检查

2.2、Readiness探测

用户通过Liveness探测可以告诉kubernetes什么时候通过重启容器实现自愈;
Readiness探测则是告诉kubernetes什么时候可以将容器加入到Service负载均衡池中,对外提供服务
readinessProbe探测方法:
  1. exec,通过命令的方式
  2. httpGet,判断成功的方法是http请求返回的代码在200-400之间,若不在此范围,则不接收service请求;每隔 periodSeconds时间探测一次,连续 3次探测失败,容器会从负载均衡中移除,直到下次探测成功加入。探测方式http://[container_ip]:8080/path返回值
Readiness 探测的 Pod配置文件如下:
apiVersion: v1
kind: Pod
metadata:
  name: readiness
  labels:
    test: readiness
spec:
  restartPolicy: OnFailure # 默认为Always
  containers:
  - name: readiness
    image: busybox
    args:
    - /bin/sh
    - -c
    - touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600
    readinessProbe:
      exec:
        command:
        - cat
        - /tmp/healthy
      initialDelaySeconds: 10 # 指定容器启动10s后开始执行Readiness探测
      periodSeconds: 5 # 指定每5s执行一次Liveness探测
17、Health Check 健康检查
Pod readiness 的 READY 状态经历了如下变化:
  1. 刚被创建时,READY状态为不可用;
  2. 15s后( initialDelaySeconds+ periodSeconds),第一次进行Readiness探测并成功返回,设置READY为可用;
  3. 30s后,/tmp/healthy被删除,连续3次 Readiness探测均失败后,READY被设置为不可用。
通过 kubectl describe pod readiness 也可以看到 Readiness 探测失败的日志:
17、Health Check 健康检查

三、在scale up中使用Healthy Check

    针对多副本应用,当执行Scale Up操作时,新副本会作为backend被添加到Service的负载均衡中,与已有副本一起处理客户请求。考虑到应用程序启动需要准备阶段(加载缓存数据、连接db),从容器启动到真正提供服务需要一段时间, 可以通过Readiness探测判断容器是否就绪,避免将请求发送到还没有ready的backend
示例应用的配置文件
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-deployment
spec:
  selector: # 通过标签选择被控制的pod
    matchLabels:
      app: web
  replicas: 2
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
      - name: web
        image: web:1.0
        ports:
        - containerPort: 8080 # 转发到后端pod的端口号
        readinessProbe:
          httpGet:
            scheme: HTTP
            path: /python
            port: 8080
          initialDelaySeconds: 10
          periodSeconds: 5
         
---
apiVersion: v1
kind: Service
metadata:
  name: web-svc
spec:
  type: NodePort # 添加NodePort类型的Service
  selector:
    app: web
  ports:   # 将 Service 的 8080 端口映射到 Pod 的 8080 端口,使用 TCP 协议
  - protocol: TCP
    port: 8080   # service监听端口
    targetPort: 8080 # 转发到后端pod的端口号
readinessProbe使用了不同于exec的另一种探测方法: httpGet
kubernetes对于httpGet方法探测成功的判断条件是http请求的返回代码在200-400之间。
  • schema 指定协议,支持 HTTP(默认值)和 HTTPS。
  • path 指定访问路径。
  • port 指定端口。
上面配置的作用是:
  1. 容器启动10s后开始探测;
  2. 如果http://container_ip:8080/python返回代码不是200-400,表示容器没有就绪,不接收Service web-svc的请求;
  3. 每隔5s再探测一次;
  4. 直至代码返回200-400,表明容器已经就绪,然后将其加入到web-svc的负载均衡中,开始处理客户请求;
  5. 探测会继续以5s的间隔请求,若连续3次失败,容器又会从负载均衡中移除。直到下次探测成功重新加入。

四、在Rolling Update中使用Healthy Check

现有一个正常运行的多副本应用,接下来对应用进行更新(比如使用更高版本的 image),Kubernetes 会启动新副本,然后发生了如下事件:
  1. 正常情况下新副本需要 10 秒钟完成准备工作,在此之前无法响应业务请求。
  2. 但由于人为配置错误,副本始终无法完成准备工作(比如无法连接后端数据库)。
先别继续往下看,现在请花一分钟思考这个问题:如果没有配置 Health Check,会出现怎样的情况?-------- 因为新副本本身没有异常退出,默认的 Health Check 机制会认为容器已经就绪,进而会逐步用新副本替换现有副本,其结果就是:当所有旧副本都被替换后,整个应用将无法处理请求,无法对外提供服务。如果这是发生在重要的生产系统上,后果会非常严重。
如果正确配置了 Health Check,新副本只有通过了 Readiness 探测,才会被添加到 Service;如果没有通过探测,现有副本不会被全部替换,业务仍然正常进行。
示例应用的配置文件
apiVersion: apps/v1
kind: Deployment
metadata:
  name: app
spec:
  selector: # 通过标签选择被控制的pod
    matchLabels:
      app: app
  replicas: 10
  template:
    metadata:
      labels:
        app: app
    spec:
      containers:
      - name: app
        image: busybox
        args:
        - /bin/sh
        - -c
        - sleep 10; touch /tmp/healthy; sleep 30000
        readinessProbe:
          exec:
            command:
            - cat
            - /tmp/healthy
          initialDelaySeconds: 10
          periodSeconds: 5
10 秒后副本能够通过 Readiness 探测。

到了这里,关于17、Health Check 健康检查的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • python - kubernetes中grpc服务健康检查实现

    概述 kubernetes本身不支持gRPC健康检查,本文记录使用 ‘grpc-health-probe’ 实现grpc服务的健康检查 ‘grpc-health-probe’,这是 Kubernetes 原生的健康检查 gRPC 应用程序的方法 官方参考文档:https://kubernetes.io/zh-cn/blog/2018/10/01/health-checking-grpc-servers-on-kubernetes/ 示例 下载grpc-health-probe文件

    2024年02月09日
    浏览(36)
  • 【k8s】:如何进行 Kubernetes 集群健康检查?

    💖The Begin💖点点关注,收藏不迷路💖 在使用 Kubernetes(k8s)部署应用程序时,保证集群的健康状态至关重要。通过定期的健康检查,可以及时发现并解决可能导致应用程序中断或故障的问题,确保集群的稳定性和可靠性。 将列出所有节点的状态,包括节点的名称、状态、版

    2024年04月16日
    浏览(41)
  • Kubernetes Pod的重启策略+健康检查(实现应用自修复);

    指的是容器什么时候才会被重启,如果没有健康检查的话,默认是根据pod的status来判断的 有三个值,分别是: Always : 只要容器被终止退出后,总是重启容器,默认策略; 应用场景:常驻进程(例如nginx,tomcat、mysql等) OnFailure :只有当容器异常退出(退出状态码非0)时,

    2024年02月03日
    浏览(35)
  • 【探索 Kubernetes|作业管理篇 系列 10】Pod 健康检查和恢复机制

    大家好,我是秋意零。 上一篇中介绍了,Pod 的服务对象,从而对 Pod 有了更深的理解; 今天的主题是 Pod 健康检查和恢复机制,我们将结束 Pod 的内容。 最近搞了一个扣扣群,旨在技术交流、博客互助,希望各位大佬多多支持!在我主页推广区域,如图: 文章底部推广区域

    2024年02月09日
    浏览(39)
  • Kubernetes(k8s)健康性检查:livenessprobe探测和readinessprobe探测

    目录 一.系统环境 二.前言 三.Kubernetes健康性检查简介 四.创建没有探测机制的pod 五.添加livenessprobe探测 5.1 使用command的方式进行livenessprobe探测 5.2 使用httpGet的方式进行livenessprobe探测 5.3 使用tcpSocket的方式进行livenessprobe探测 六.readinessprobe探测 七.总结 本文主要基于Kubernetes1.

    2024年02月07日
    浏览(47)
  • Rabbit health check failed

    说明: 项目并未配置rabbitmq,但是每次项目启动的时候总是会报错,rabbitmq连接异常,健康检查失败,但是不影响项目运行。 具体报错信息如下: 具体查看报错内容后发现: 原来是项目配置了spring健康检查: 解决: 在配置文件中添加rabbitmq的健康检查忽略 再次启动项目,报

    2024年02月11日
    浏览(31)
  • elasticsearch索引health 健康状态变为yellow,red处理

    查看所有索引健康状态 看到所有索引都出现yellow,red 1.绿色——最健康的状态,代表所有的主分片和副本分片都可用; 2 黄色——所有的主分片可用,但是部分副本分片不可用; 3 红色——部分主分片不可用。(此时执行查询部分数据仍然可以查到,遇到这种情况,还是赶快

    2024年02月11日
    浏览(51)
  • 华为运动健康服务Health Kit 6.10.0版本新增功能速览!

    华为运动健康服务(HUAWEI Health Kit)6.10.0 版本新增的能力有哪些? 阅读本文寻找答案,一起加入运动健康服务生态大家庭! 一、支持三方应用查询用户测量的连续血糖数据 符合申请Health Kit服务中开发者申请资质要求的企业开发者,可申请访问用户的心率、压力、血糖等健康

    2023年04月11日
    浏览(64)
  • Elasticsearch health check failed java.net.ConnectException: Connection refused: no further informat

    这个错误信息表示Java程序尝试连接到Elasticsearch服务进行健康检查时失败了,具体原因是网络连接被拒绝,没有获取到进一步的信息。\\\"Connection refused: no further information\\\"通常意味着目标Elasticsearch服务可能没有运行、未监听请求的端口或者防火墙阻止了连接。 解决这个问题,请

    2024年04月13日
    浏览(38)
  • ORACLE- check 检查约束

    某列取值范围限制、格式限制等 格式:check(字段名 like \\\'约束条件\\\')  或者 check(regexp_like(字段名,\\\'约束条件\\\')) 1.检查性别只能是男或女 2.在一个范围中间 3.长度大于等于某个值 以下内容仅写第一种方法(表中check约束) 4.数大于某个值 5.只能是8位字符,前两位是0,3~4位为

    2023年04月15日
    浏览(37)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包