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

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完成。

livenessProbe

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

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

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

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

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

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

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

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

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

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

您还可以指定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命令。

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

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