这篇文章我们来聊 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
评论