使用 Kubernetes 健康检查

这篇文章我们来聊 Kubernetes 的健康检查，以及不同健康检查是如何影响你的应用程序的。

Liveness Probes

Kubernetes 健康检查被分成 liveness 和 readiness probes。liveness probes 是用来检测你的应用程序是否正在运行。通常情况下，你的程序一崩溃，Kubernetes 就会看到这个程序已经终止，然后重启这个程序。但是 liveness probes 的目的就是捕捉到当程序还没有终止，还没有崩溃或者还没陷入死锁的情况。所以一个简单的 HTTP 回应能够满足。

以下是一个我使用的为 Go 应用程序使用健康检查的例子。

在配置中

上图就是告诉 Kubernetes，应用程序正在运行。initialDelaySeconds 告诉 Kubernetes 在看到 pod 启动之后要延迟开启健康检查，并说清楚延迟几秒。如果你的应用程序需要一些时间来启动，你可以用这个设置来帮助它。timeoutSeconds 会告诉 Kubernetes 应该为健康检查等待多长时间。对于 liveness probes，这个时间不能太长，但是万一有欠载的情况，你就真的需要给你的应用足够的时间来回应。

如果应用程序从未启动，或者回应过来一个 HTTP 错误代码，那么之后 Kubernetes 就会重新启动 pod。你最好不要在 liveness probes 中进行太炫酷的什么动作，想都不要想，因为一旦 liveness probes 功能开始失效的话，这会引起你的应用程序错误。

Readiness Probes

Readiness Probes 跟 liveness probes 十分相似，只有失效检测的结果是不一样的。Readiness Probes 是用来检查你的应用程序是否可以为通信服务。这跟 liveness 有些微妙的不同。比如，你的应用程序取决于数据库与 memcached。如果上面两个都在良好状态，为你的应用提供通信，然后你就可以说这两个都是你的应用的“readiness”。

如果你的应用的 readness probe 运行失败，那么 pod 就会从组成 service 的端点被删除。这样的话，没有准备好的 pods 就不会有流量通信通过 Kubernetes 服务发现机制来发送给他们。当遇到 service 的新 pod 启动时；拓展 events 时，滚动更新等状态的时候，这个状态十分有帮助。Readiness probes 确认在 pods 开启的时候 pods 没有被发通信，还有他们处于待服务通信的时候也没有。

Readiness probe 的定义跟 liveness probes 的定义一样。Readiness probes 被定义为 Deployment 的一部分，比如像这样：

你是不是想要检验一下是否可以在你的 readiness probe 中连接到你的应用程序的依赖。以我们依赖数据库为例，我们想要检查我们是否能够连接到两者。

情况看起来应该是这样的（下图所示）。我检查 memcached 和数据库，如果有一个不可得，那么我就会回复一个 503 回应状态。

更稳定的应用程序

Liveness 和 Readiness probes 对增加应用程序的稳定性很有帮助。他们帮助确认通信是否只流通到为它准备的实例上，当应用变得无反应的时候，自我治愈也是一样。他们就是我同事所说的叫做“12 Fractured Apps”的更好的解决方法。有了合适的健康检查，你就能够以任意顺序配置你的应用程序，不需要担心相关性或者复杂的进入点脚本。当应用程序准备好的时候，他们会开始服务通信，所以自动调度和滚动更新运行得十分顺利。

本文转载自才云 Caicloud 公众号。

原文链接：https://mp.weixin.qq.com/s/rhg_VwUp1BtI9cNLaSk4Jg