使用 Kubernetes 健康检查

2016-06-10

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

点击体验,开启谷歌级数字化之旅
立即体验
立即咨询