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

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.0中配置相应的健康检查。

Rancher 2.0中的健康检查

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

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

快速Kubernetes健康检查摘要

livenessProbelivenessProbe是对容器执行的操作，用于检查容器是否正在运行。如果探针报告失败，Kubernetes将终止pod容器，并根据规范中指定的重新启动策略重新启动它。readinessProbereadinessProbe用于检查容器是否已准备好接受请求及满足请求。当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.portresponse_timeout 变成timeoutSecondshealthy_threshold 变成 failureThresholdunhealthy_threshold 变成successThresholdinterval 变成 periodSecondsinitializing_timeout 变成initialDelaySecondsstrategy 变成 restartPolicy

HTTP健康检查

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

下面是Kubernetes YAML规范，显示了为上文所说的Nginx工作负载配置的HTTPreadinessProbe和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而不会丢失任何功能。

在后续文章中，我们还会探讨如何将Cattle支持的调度选项映射到Rancher 2.0中的Kubernetes。敬请关注！