使用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”的更好的解决方法。有了合适的健康检查，你就能够以任意顺序配置你的应用程序，不需要担心相关性或者复杂的进入点脚本。当应用程序准备好的时候，他们会开始服务通信，所以自动调度和滚动更新运行得十分顺利。

原文链接

如果需要转载，请联系我们哦，尊重知识产权人人有责；）