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

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

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

Rancher 1.6 中的健康检查

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

简单来说,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 健康检查摘要

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

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

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

top="2546.890625">在 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,健康检查参数的变化:

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 而不会丢失任何功能。

声明:本文来自用户分享和网络收集,仅供学习与参考,测试请备份。