Kubernetes健康检查如何做？官方推荐教程

编者语：这是 Google 开发者布道师 Sandeep Dinesh[1]的视频[2]和博客系列 “如何充分利用 Kubernetes 环境” 的第三部分。

分布式系统管理比较困难。很重要的原因是系统正常工作依赖很多不同的组件。任何一个组件出了问题，系统必须要能发现出问题的组件，绕开并且修复它，所有的这些都要自动完成。

健康检查是发现你的应用实例是否正常工作的简单方式。如果应用的某个实例不能工作，其他的服务不应该访问或者请求该实例。请求应该发送给应用的其他正常实例，过一段时间再尝试异常实例。系统应该保证应用处于正常状态。

默认情况下，Kubernetes 在容器内的 Pod 启动后开始向 Pod 发送流量，并在容器崩溃时重新启动容器。虽然这已经“足够好”，然而你可以通过自定义的健康检查让部署过程更加完美。Kubernetes 非常容易实现自定义健康检查，所以没有理由不去用它。

我们详细介绍一下如何在 Kubernetes 集群中选择和设置 Readiness 和 Liveness 探针[3]。

健康检查类型

Kubernetes 提供了2种健康检查的方式。下面我们来了解一下这两种健康检查的区别和使用。

READINESS

设计 Readiness 探针的目的是用来让 Kubernetes 知道你的应用何时能对外提供服务。在服务发送流量到 Pod 之前，Kubernetes必须确保 Readinetes 探针检测成功。如果 Readiness 探针检测失败了，Kubernetes 会停掉 Pod 的流量，直到 Readiness 检测成功。

LIVENESS

Liveness 探针能让 Kubernetes 知道你的应用是否存活。如果你的应用是存活的，Kubernetes 不做任何处理。如果是挂掉的，Kubernetes 会移除异常的 Pod，并且启一个新的 Pod 替换它。

健康检查的作用

我们来看两种场景下，如何使用Readiness 和 Liveness 探针帮助你构建更健壮的应用。

READINESS

假设你的应用需要时间进行预热和启动。即便进程已经启动，你的服务依然是不可用的，直到它真的运行起来。如果想让你的应用横向部署多实例，这也可能会导致一些问题。因为新的复本在没有完全准备好之前，不应该接收请求。但是默认情况下，只要容器内的进程启动完成，Kubernetes 就会开始发送流量过来。如果使用 Readiness 探针， Kubernetes 就会一直等待，直到应用完全启动，才会允许发送流量到新的复本。

LIVENESS

我们设想另外一种场景，你的应用产生了死锁，导致进程一直夯住，并且停止处理请求。因为进程还处在活跃状态，默认情况下， Kubernetes 认为一切正常，会继续向异常Pod 发送流量。通过使用 Liveness 探针， Kubernetes 会发现应用不再处理请求，然后重启异常的 Pod 。

探针类型

接下来就是如何定义 Liveness 和 Readiness 探针了。有3种类型的探针实现方式可以选择，分别是：HTTP、Command、TCP。你可以使用任何一种方式实现 Liveness 和 Readiness 探针。

HTTP

HTTP 可能是 Liveness 探针的最常用的实现方式。即便你的应用不是一个 HTTP 服务，你也可以通过在应用内部集成一个轻量级的HTTP 服务，以支持 Liveness 探针。Kubernetes 通过 ping 一个路径，如果 HTTP 响应的状态码是 2xx 或者 3xx ，说明该应用是健康状态，否则就是不健康状态。
更多 HTTP探针信息[4]

COMMAND

对于命令行探针，kubernetes 在容器内运行命令，如果返回0，说明服务是健康状态，否则就是不健康状态。当你不能或者不想提供额外的 HTTP 服务，但是能使用命令行的时候，通过命令行来进行健康检查很有用的。
更多 Command探针信息[5]

TCP

最后一种是 TCP 探针。Kubernetes 尝试跟某个端口建立一个 TCP 连接。如果能建立连接，表示容器是健康状态，否则是不健康状态。
假如 HTTP 和命令行都不能使用的情况下， TCP 的方式就派上用场了。例如 gRPC[6]或者 FTP 服务中，TCP 类型就是首选。

更多 TCP探针信息[7]

配置探针启动的延迟

探针有多种配置。你能指定探针多久执行一次、成功和失败的阈值、多长时间的响应等待等等。 探针配置文档[8]非常清楚的介绍了这些不同的配置的作用。
当你使用 Liveness 探针的时候，initialDelaySeconds 是你需要设置的非常重要的配置。

如前面说的，Liveness 探针检查失败会导致 Pod 重启。你必须确保 Liveness 探针在应用准备好之后生效。否则，应用会一直不停被重启。

我推荐使用 p99[9]作为 initialDelaySeconds 的生效时间，或者简单的使用平均启动时间加一个缓冲时间。如果应用的启动时间变长或者变短了，确保更新了这个配置。

总结

很多人都会告诉你，分布式系统必须有健康检查，Kubernetes 也不例外。Kubernetes 提供了非常方便的健康检查，为你Kubernetes 中的服务提供更稳定的、更可靠的、更高的正常运行时间。

本文作者Sandeep Dinesh，由邓启明翻译。转载译文请注明出处，技术原创及架构实践文章，欢迎通过公众号菜单「联系我们」进行投稿。

参考链接

[1] https://twitter.com/sandeepdinesh?lang=en

[2] https://www.youtube.com/playlist?list=PLIivdWyY5sqL3xfXz5xJvwzFW_tlQB_GB

[3] https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/

[4] https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/#define-a-liveness-http-request

[5] https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/#define-a-liveness-command

[6] https://grpc.io/

[7] https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/#define-a-tcp-liveness-probe

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

[9] https://www.quora.com/What-is-p99-latency

相关阅读：

活动预告：

6 月 1 ~ 2 日，GIAC 全球互联网架构大会将于深圳举行。GIAC 是高可用架构技术社区推出的面向架构师、技术负责人及高端技术从业人员的技术架构大会。今年的 GIAC 已经有腾讯、阿里巴巴、百度、今日头条、科大讯飞、新浪微博、小米、美图、Oracle、链家、唯品会、京东、饿了么、美团点评、罗辑思维、ofo、旷视、LinkedIn、Pivotal等公司专家出席。

本期 GIAC 大会上，部分精彩的议题如下：

参加 GIAC，盘点2018最新技术。点击“阅读原文”了解大会更多详情