如何在Kubernetes中配置健康检查
本篇文章为大家展示了如何在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而不会丢失任何功能。
上述内容就是如何在Kubernetes中配置健康检查，你们学到知识或技能了吗？如果还想学到更多技能或者丰富自己的知识储备，欢迎关注行业资讯频道。
