Kubernetes应用健康检查

关注

转载最新推荐文章于 2026-04-04 09:29:03 发布 717 阅读 AI 写同款· GEO 优化 ›

在准备秋招之前就前辈们的简历制作，面试经验等做一总结 {在准备秋招之前就前辈们的简历制作，面试经验做一总结} 写简历的要求 1.内容与所招聘的岗位匹配。 2.措辞具体完整，真实的呈现自己胜任能力（亮化能力）。 3.模板简单，易于阅读。 4.手机号码，邮箱，性别（可写可不写），姓名（注：培训经历，籍贯，名族，身体状况，婚姻状况，邮编，住址都不要），教... 阅读详情

目录贴：Kubernetes学习系列

　　在实际生产环境中，想要使得开发的应用程序完全没有bug，在任何时候都运行正常，几乎是不可能的任务。因此，我们需要一套管理系统，来对用户的应用程序执行周期性的健康检查和修复操作。这套管理系统必须运行在应用程序之外，这一点非常重要一一如果它是应用程序的一部分，极有可能会和应用程序一起崩溃。因此，在Kubernetes中，系统和应用程序的健康检查是由Kubelet来完成的。

1、进程级健康检查

　　最简单的健康检查是进程级的健康检查，即检验容器进程是否存活。这类健康检查的监控粒度是在Kubernetes集群中运行的单一容器。Kubelet会定期通过Docker Daemon获取所有Docker进程的运行情况，如果发现某个Docker容器未正常运行，则重新启动该容器进程。目前，进程级的健康检查都是默认启用的。

2．业务级健康检查

　　在很多实际场景下，仅仅使用进程级健康检查还远远不够。有时，从Docker的角度来看，容器进程依旧在运行；但是如果从应用程序的角度来看，代码处于死锁状态，即容器永远都无法正常响应用户的业务

　　为了解决以上问题，Kubernetes引人了一个在容器内执行的活性探针（liveness probe）的概念，以支持用户自己实现应用业务级的健康检查。这些检查项由Kubelet代为执行，以确保用户的应用程序正确运转，至于什么样的状态才算“正确”，则由用户自己定义。Kubernetes支持3种类型的应用健康检查动作，分别为HTTP Get、Container Exec和TCP Socket。个人感觉exec的方式还是最通用的，因为不是每个服务都有http服务，但每个服务都可以在自己内部定义健康检查的job，定期执行，然后将检查结果保存到一个特定的文件中，外部探针就不断的查看这个健康文件就OK了。

2.1 Container Exec

　　Kubelet将在用户容器内执行一次命令，如果命令执行的退出码为0，则认为容器运转正常，否则认为容器运转不正常。其中执行命令的默认目录是容器文件系统的根目录/，要执行的命令在Pod配置文件中定义。每进行一次Container Exec健康检查，都会执行一次livenessprobe：exec：command段下的Shell命令。以下给出exec探针的示例：

复制代码

[root@k8s-master livenessProbe]# cat test-livenessprobe-hostpath.yaml 
apiVersion: v1
kind: Pod
metadata:
  labels:
    name: test-livenessprobe-hostpath
  name: test-livenessprobe-hostpath
spec:
  containers:
    - name: test-livenessprobe-hostpath
      image: registry:5000/back_demon:1.0
      volumeMounts:
       - name: testhost
         mountPath: /home/laizy/test/hostpath
         readOnly: false
      livenessProbe:
        exec:
          command:
          - cat
          - /home/laizy/test/hostpath/healthy
        initialDelaySeconds: 5
        periodSeconds: 5
      command:
      - /run.sh
  volumes:
  - name: testhost
    hostPath:
     path: /home/testhost

复制代码

　　由yaml的配置可以看出，健康探针主要探测的是/home/laizy/test/hostpath/下是否存在healthy文件，对应的是宿主机上/home/testhost这个文件夹。若不存在则判定不健康，若存在则健康。笔者在实验的过程中发现，当在宿主机上删除这个文件的时候，大概需要40S的时间，系统才会判定pod失败，并将其删除；之后一直不断重启，且不会将pod调度到别的node上；当在宿主机上重新生成这个文件之后，大概需要四五分钟的时间，pod一直处于CrashLoopBackOff的状态，之后才正常提供服务。对于这两个时间的产生，还需要进一步的探究其原理。

2.1 HTTP Get

　　Kubelet将调用容器内Web应用的web hook，如果返回的HTTP状态码在200和399之间，则认为容器运转正常，否则认为容器运转不正常。每进行一次HTTP健康检查都会访问一次指定的URL。给出httpGet的简单示例如下：

复制代码

[root@k8s-master livenessProbe]# cat test-livenessprobe.yaml
apiVersion: v1
kind: Pod
metadata:
  labels:
    name: test-livenessprobe
  name: test-livenessprobe
spec:
  containers:
    - name: test-livenessprobe
      image: registry:5000/back_demon:1.0
      livenessProbe:
        httpGet:
          path: /starott_cloud_client/test/overview-frontend
          port: 8080
        initialDelaySeconds: 15
        periodSeconds: 5
        timeoutSeconds: 1
      command:
      - /run.sh

复制代码

在容器内部kill掉jboss进程之后（我的镜像用脚本run.sh启动，kill掉业务主进程之后，还可以通过其他的程序将容器“卡住”），模拟出调用http接口返回不在200~399之间，在node的/var/log/messages下会出现如下日志，并随后将pod创建。

复制代码

Apr  6 13:22:03 k8s-node-1 kubelet: I0406 13:22:03.470882   19861 docker_manager.go:2015] pod "test-livenessprobe_default(77b73469-1a88-11e7-b3d5-fa163ebba51b)" container "test-livenessprobe" is unhealthy, it will be killed and re-created.
Apr  6 13:22:03 k8s-node-1 dockerd-current: time="2017-04-06T13:22:03.471442565+08:00" level=info msg="{Action=stop, LoginUID=4294967295, PID=19861}"
Apr  6 13:22:33 k8s-node-1 dockerd-current: time="2017-04-06T13:22:33.472842885+08:00" level=info msg="Container 77c700d8564f2d7b8b0b455563b7530f5657df9b8a0de528587c6e0fb8a28237 failed to exit within 30 seconds of signal 15 - using the force"

复制代码

2.3 TCP Socket

　　理论上Kubelet将会尝试打开一个到用户容器的Socket连接。如果能够建立这条连接，则可以认为容器运转正常，否则认为容器运转不正常。

　　不论哪种检查类型，一旦Kubelet发现容器运转不正常，就会重新启动该容器。容器的健康检查行为在容器配置文件的livenessprobe字段下配置。需要注意的是，livenessprobe：initialDelaySecods字段代表了一个从容器启动到执行健康检查的延迟时间，设计这个延迟时间的目的是让容器进程有时间完成必要的初始化工作。

收录于