若您的应用程序是面向用户的,那么确保持续可用性、尽力达到最短停机时间,是一项无比重要却也不易的挑战。因此,想要避免任何中断,良好地监控应用程序的运行状况,在此显得至关重要。
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.0 中配置相应的健康检查。
Rancher 2.0 中的健康检查
在 2.0 中,Rancher 使用的是原生的 Kubernetes 健康检查机制:livenessProbe
和readinessProbe
。
参考此文档的定义,探针(probe)是由 Kubelet 在容器上定期执行的诊断:链接。在 Rancher 2.0 中,与 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 退出。
您可在此查看上述探针的更多配置详细信息:
在 Rancher 2.0 中配置健康检查
通过 Rancher UI,用户可以向 Kubernetes 工作负载添加 TCP 或 HTTP 健康检查。默认情况下,Rancher 会要求您为工作负载配置readinessProbe
,并使用相同的配置应用livenessProbe
。您也可以选择定义单独的livenessProbe
。
如果健康检查失败,则容器会根据工作负载规范中定义的restartPolicy
重新启动。这相当于以前的 rancher-compose.yml
文件中的 strategy 参数,那时这一参数是用于使用 Cattle 中的健康检查的 1.6 服务的。
TCP 健康检查
在 Rancher 2.0 中部署工作负载时,用户可以配置 TCP 健康检查,以检查是否可以在特定端口打开 TCP 连接。
以下是 Kubernetes YAML 规范,也就是为上文说的 Nginx 工作负载所配置的 TCP readinessProbe
。Rancher 还使用相同的配置为您的工作负载添加了livenessProbe
。
从 1.6 到 2.0,健康检查参数的变化:
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.0 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.0 中添加 TCP 或 HTTP 健康检查的配置参数与 Rancher 1.6 非常相似。Cattle 服务使用的健康检查配置可以完全转换为 2.0 而不会丢失任何功能。
评论