Kubernetes(k8s)-健康检查(HealthCheck)介绍

最新推荐文章于 2025-11-30 03:46:55 发布

原创最新推荐文章于 2025-11-30 03:46:55 发布 · 1.1k 阅读

13 ·

CC 4.0 BY-SA版权

文章标签：

#kubernetes #容器 #云原生 #云计算 #运维

Kubernetes(k8s) 专栏收录该内容

81 篇文章

订阅专栏

作者介绍：简历上没有一个精通的运维工程师。请点击上方的蓝色《运维小路》关注我，下面的思维导图也是预计更新的内容和当前进度(不定时更新)。

我们上一章介绍了Docker基本情况，目前在规模较大的容器集群基本都是Kubernetes，但是Kubernetes涉及的东西和概念确实是太多了，而且随着版本迭代功能在还增加，笔者有些功能也确实没用过，所以只能按照我自己的理解来讲解。

前面几个小节，我们介绍了pod的引用的资源，下面几个小节我们讲介绍pod的几个配置包括健康检查和reques&limit。

我们前面在讲解pod的时候，都有一个类似的状态1/1，这里前面的1是准备好pod数量，后面是pod数量。我们再考虑一个问题，比如一个比较复杂的pod，这个业务启动假设需要1分钟，但是我们的在创建pod的时候，只要容器运行起来未出错就算准备好，就在对外提供服务，但是这个时候真实的业务其实并没有启动成功，就会导致访问出现异常。针对这个问题，k8s给我们一种健康检查机制，我们可以自定义一个检查，当这个检查通过以后，pod才对外提供服务，这个就是我们要讲解健康检查。另外一种情况就是当pod运行的时候，容器还在运行，但是业务其实已经发生故障无法响应服务，这个时候我们的pod还在继续提供服务，但是业务其实已经不可用，都可用用健康检查来规避掉这2个问题。

HealthCheck

在 Kubernetes 中，健康检查（Health Checks）主要通过两种机制来实现：Liveness Probes 和 Readiness Probes。这些检查帮助 Kubernetes 理解应用程序内部的状态，并相应地管理 Pod。配置健康检查确保 Kubernetes 能够响应应用的故障，提供自动恢复的能力，并确保流量不会发送到尚未准备好处理请求的 Pod。

Readiness Probes

Readiness Probes 确定容器是否已经准备好接受流量。如果 Pod 不准备好，它就不会加入服务的后端提供服务。Readiness Probes 通常用于在启动时，容器需要加载大量数据或配置文件、与外部服务进行连接等场景，但是在pod生命周期里面其实它都在持续运行。

这里是一个 Readiness Probe 的示例配置：

readinessProbe:
  httpGet:
    path: /ready
    port: 8080
  initialDelaySeconds: 5
  periodSeconds: 5

Liveness Probes

Liveness Probes 确定何时需要重启容器。例如，当应用陷入死锁，能够响应 Web 服务器的 ping，但无法进行进一步操作时，最好是重启容器。

这里是一个 Liveness Probe 的示例配置：

livenessProbe:
  httpGet:
    path: /healthz
    port: 8080
  initialDelaySeconds: 3
  periodSeconds: 3

健康检查类型

httpGet：Kubernetes 尝试对指定的路径和端口执行 HTTP GET 请求。如果返回的状态码是 200-399 之间，那么就认为是成功的。

exec：Kubernetes 会在容器内执行指定的命令。如果命令退出代码为 0，则认为探测成功。

   livenessProbe:
      exec:
        command:
        - my-command
      initialDelaySeconds: 10
      periodSeconds: 5

tcpSocket：Kubernetes 尝试打开容器的指定端口。如果能够建立 TCP 连接，则探测被认为是成功的。

   readinessProbe:
      tcpSocket:
        port: 8080
      initialDelaySeconds: 5
      periodSeconds: 10

常见参数

initialDelaySeconds：容器启动后延迟多少秒后开始进行第一次探测，因为不同的pod启动所需要的时间是不一样的，所以需要先等待一段时间以后才开始执行第一次健康检查。
periodSeconds：执行探测的频率。
timeoutSeconds：探测请求超时的秒数。
successThreshold：探测被认为成功之前的最小连续成功次数。
failureThreshold：当探测失败后，Kubernetes 尝试重启之前的最小连续失败次数。