15分钟快速了解如何在Kubernetes中配置健康检查

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

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退出。

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

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

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

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

拓展阅读：

“

Rancher Labs由硅谷云计算泰斗、CloudStack之父梁胜创建，致力于打造创新的开源软件，帮助企业在生产环境中运行容器与Kubernetes。旗舰产品Rancher是一个开源的企业级Kubernetes平台，是业界首个且唯一可以管理所有云上、所有发行版、所有Kubernetes集群的平台。解决了生产环境中企业用户可能面临的基础设施不同的困境，改善Kubernetes原生UI易用性不佳以及学习曲线陡峭的问题，是企业落地Kubernetes的不二之选。

Rancher在全球已有9000万次下载和超过20000个生产节点部署，且在全球范围内已经拥有包含迪斯尼、IBM、乐高、美国农业部、SONY、中国平安、海航集团在内数百家大中型政府及企业客户。

”

公众号：RancherLabs

官    网：cnrancher.com

加它好友👆进技术群

9月1日上海，Rancher携手JFrog杰蛙举办容器技术沙龙，聚焦企业容器落地实践，等你来约~！

点击“阅读原文”，报名活动