34.2. 使用探测的容器健康检查


探测(probe)是一种 Kubernetes 操作,它会定期对运行中的容器执行诊断。目前,存在两种类型的探测,各自满足不同的目的:

存活度(Liveness)探测

存活度探测检查在其中配置的容器是否仍然在运行。如果存活度探测失败,kubelet 会终止该容器,这将受到重启策略的影响。通过配置 Pod 配置的 template.spec.containers.livenessprobe 节来设置存活度检查。

就绪度(Readiness)探测

就绪度探测(Readiness probe)决定容器是否准备好服务请求。如果某一容器的就绪度探测失败,则端点控制器将确保从所有服务的端点中移除该容器的 IP 地址。就绪度探测也可用于向端点控制器发送信号,即使有容器在运行它也不应从代理接收任何流量。通过配置 Pod 配置的 template.spec.containers.readinessprobe 节来设置就绪度检查。

探测的确切时间由两个字段控制,它们以秒为单位表示:

字段描述

initialDelaySeconds

容器启动后等待多久才能开始探测。

timeoutSeconds

等待多长时间以便探测完成(默认: 1)。如果超过这一时间,OpenShift Container Platform 会将探测视为已失败。

可以通过两种方式配置两个探测:

HTTP 检查

kubelet 使用 Web hook 来确定容器的健康状态。如果 HTTP 响应代码介于 200 和 399 之间,则检查被认定为成功。以下是使用 HTTP 检查方法就绪度检查示例:

例 34.1. 就绪度 HTTP 检查

...
readinessProbe:
  httpGet:
    path: /healthz
    port: 8080
  initialDelaySeconds: 15
  timeoutSeconds: 1
...

对于在完全初始化后返回 HTTP 状态代码的应用程序,HTTP 检查是理想的选择。

容器执行检查

kubelet 在容器内执行一个命令。退出检查时状态为 0 被视为成功。以下是使用容器执行方法的存活度检查示例:

例 34.2. 存活度容器执行检查

...
livenessProbe:
  exec:
    command:
    - cat
    - /tmp/health
  initialDelaySeconds: 15
...
注意

timeoutSeconds 参数不影响容器执行检查的就绪度和存活度探测。您可以在探测本身中使用超时机制,因为 OpenShift Container Platform 无法对进入容器的 exec 调用执行超时。在探测中实施超时的一种方法是使用 timeout 参数来运行存活度或就绪度探测:

[...]
       livenessProbe:
        exec:
          command:
            - /bin/bash
            - '-c'
            - timeout 60 /opt/eap/bin/livenessProbe.sh 1
        timeoutSeconds: 1
        periodSeconds: 10
        successThreshold: 1
        failureThreshold: 3
[...]
1
超时值和探测脚本路径。

TCP 套接字检查

kubelet 尝试向容器打开一个套接字。只有检查能够建立连接,容器才被视为健康。以下是使用 TCP 套接字检查方法的存活度检查示例:

例 34.3. 存活度 TCP 套接字检查

...
livenessProbe:
  tcpSocket:
    port: 8080
  initialDelaySeconds: 15
  timeoutSeconds: 1
...

对于只有初始化完毕后才开始侦听的应用程序,TCP 套接字检查是理想的选择。

如需有关健康检查的更多信息,请参阅 Kubernetes 文档

Red Hat logoGithubRedditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务,以及可以信赖的内容,帮助红帽用户创新并实现他们的目标。

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情,请参阅红帽博客.

關於紅帽

我们提供强化的解决方案,使企业能够更轻松地跨平台和环境(从核心数据中心到网络边缘)工作。

© 2024 Red Hat, Inc.