健康检查详解：机制、配置、对比、实操

若您的应用程序是面向用户的，那么确保持续可用性、尽力达到最短停机时间，是一项无比重要却也不易的挑战。因此，想要避免任何中断，良好地监控应用程序的运行状况，在此显得至关重要。

Rancher 1.6 中的健康检查

Rancher 1.6 中的编排引擎 Cattle，具有为部署好的服务添加 HTTP 或 TCP 健康检查的功能。Rancher 自己的健康检查微服务提供了健康检查支持。你可以在这此了解更多信息：

https://rancher.com/docs/rancher/v1.6/en/cattle/health-checks/

简单来说，Cattle 用户可以向服务添加 TCP 健康检查。Rancher 的健康检查容器会在不同的主机上启动，它们会测试 TCP 连接是否在服务容器的指定端口打开。请注意，对于最新版本（v1.6.20），健康检查容器也与服务容器安排在同一主机上。

在部署服务时，也可以添加 HTTP 健康检查。您可以要求 Rancher 在指定路径上发出 HTTP 请求，并指定预期的响应。

这些健康检查会定期完成，您可以自行配置检查的间隔周期，重试/超时也是可配置的。如果健康检查失败，您还可以指示 Rancher 是否以及何时重新创建容器。

例如，在 Cattle 上运行 Nginx 镜像的服务，并使用如下配置进行 HTTP 健康检查：

健康检查的参数显示在 rancher-compose.yml 文件中，而不是 docker-compose.yml，因为健康检查功能是由 Rancher 实现的。

下面让我们来看看我们是否可以在 Rancher 2.x 中配置相应的健康检查。

Rancher 2.x 中的健康检查

在 2.x 中，Rancher 使用的是原生的 Kubernetes 健康检查机制：livenessProbe 和 readinessProbe。

参考此文档的定义，探针（probe）是由 Kubelet 在容器上定期执行的诊断：链接。在 Rancher 2.x 中，与 Rancher 1.6 中的跨主机健康检查相比，健康检查由本地运行的 Kubelet 完成。

快速 Kubernetes 健康检查摘要

• livenessProbe

• livenessProbe 是对容器执行的操作，用于检查容器是否正在运行。如果探针报告失败，Kubernetes 将终止 pod 容器，并根据规范中指定的重新启动策略重新启动它。

• readinessProbe

• readinessProbe 用于检查容器是否已准备好接受请求及满足请求。当 readinessProbe 失败时，则不会通过公共端点公开 pod 容器，因此容器不会接收到任何请求。

如果您的工作负载在处理请求之前忙于执行某些启动例程，则最好为工作负载配置 readinessProbe。

可以为 Kubernetes 工作负载配置以下类型的 livenessProbe 和 readinessProbe：

• tcpSocket – Kubelet 会检查是否可以针对指定端口上的容器 IP 地址打开 TCP 连接。

• httpGet -在指定路径上发出 HTTP / HTTPS GET 请求，如果它返回 200 和 400 之间的 HTTP 响应代码，则报告为成功。

• exec - Kubelet 在容器内执行指定的命令，并检查命令是否以状态 0 退出。

您可在此查看上述探针的更多配置详细信息：

https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/#configure-probes

在 Rancher 2.x 中配置健康检查

通过 Rancher UI，用户可以向 Kubernetes 工作负载添加 TCP 或 HTTP 健康检查。默认情况下，Rancher 会要求您为工作负载配置 readinessProbe，并使用相同的配置应用 livenessProbe。您也可以选择定义单独的 livenessProbe。

如果健康检查失败，则容器会根据工作负载规范中定义的 restartPolicy 重新启动。这相当于以前的 rancher-compose.yml 文件中的 strategy 参数，那时这一参数是用于使用 Cattle 中的健康检查的 1.6 服务的。

TCP 健康检查

在 Rancher 2.x 中部署工作负载时，用户可以配置 TCP 健康检查，以检查是否可以在特定端口打开 TCP 连接。

以下是 Kubernetes YAML 规范，也就是为上文说的 Nginx 工作负载所配置的 TCP readinessProbe。Rancher 还使用相同的配置为您的工作负载添加了 livenessProbe。

从 1.6 到 2.x，健康检查参数的变化：

• port 变成 tcpSocket.port

• response_timeout 变成 timeoutSeconds

• healthy_threshold 变成 failureThreshold

• unhealthy_threshold 变成 successThreshold

• interval 变成 periodSeconds

• initializing_timeout 变成 initialDelaySeconds

• strategy 变成 restartPolicy

HTTP 健康检查

您还可以指定 HTTP 健康检查，并在 pod 容器中提供 Kubelet 将发出 HTTP / HTTPS GET 请求的路径。但是，不同于 Rancher 1.6 中支持任何 HTTP 方法，Kubernetes 仅支持 HTTP / HTTPS GET 请求。

下面是 Kubernetes YAML 规范，显示了为上文所说的 Nginx 工作负载配置的 HTTP readinessProbe 和 livenessProbe。

健康检查在行动

现在让我们看看当 Kubernetes 中的健康检查失败时会发生什么，以及工作负载如何恢复。

假定在我们的 Nginx 工作负载上执行上述 HTTP 健康检查，在/index.html 路径上执行 HTTP GET。为了刻意使健康检查失败，我使用 Rancher 中的 Execute Shell UI 选项在 pod 容器中执行了一个 exec。

exec 容器后，我移动了健康检查执行 GET 的文件。

readinessProbe 和 livenessProbe 检查失败，并且工作负载状态已变为“不可用”。

Kubernetes 很快就杀死了原 pod 并重新创建了 pod，并且由于 restartPolicy 设置为了 Always，工作负载很快恢复了。

使用 Kubectl，您可以看到这些健康检查事件日志：

小提示：Rancher 2.x UI 提供了从 Kubernetes Cluster 视图启动 Kubectl 的功能，您可以在该视图中在集群对象上运行原生的 Kubernetes 命令。

将健康检查从 Docker Compose 迁移到 Kubernetes Yaml？

Rancher 1.6 通过自己的微服务提供了健康检查，这就是为什么 Cattle 用户添加到服务中的健康检查参数会出现在 rancher-compose.yml 文件而不是 docker-compose.yml 配置文件中。

我们之前在文章《如何简洁优雅地实现Kubernetes服务暴露》中使用的 Kompose 工具适用于标准的 docker-compose.yml 参数，因此无法解析 Rancher 健康检查构造。目前，我们暂时无法使用此工具将 Rancher 健康检查从 compose 配置转换为 Kubernetes Yaml。

结论

如本文所述，可用于在 Rancher 2.x 中添加 TCP 或 HTTP 健康检查的配置参数与 Rancher 1.6 非常相似。Cattle 服务使用的健康检查配置可以完全转换为 2.x 而不会丢失任何功能。