订阅博客
收藏博客
微博分享
QQ空间分享

详解Readiness和Liveness探测器做HealthChecks

频道:Kubernetes 标签: 时间:2019年12月10日 浏览:179次 评论:0条

前言:
分布式系统通常是难于管理的。主要是由于组件很多,且当其中一个损坏时,系统必须能探测到,绕过它,最后修复它,并且最重要的是,这一系列都需要是自动的。
如果一个实例不可用,那么系统就不应该向其分发请求,相反,应该将请求分发到其他可用的实例上,或者稍后再尝试。同时系统应该自动将失效的实例重新恢复到可用状态。

默认情况下,kubernetes(以后简称k8s)当pod中所有container一“启动”,就向其发送通信请求,并在pod崩溃后重启他们。通常来说这已经够好了。但是k8s提供了一种更直接明了的方式。
那就是readiness和liveness探测器。


HealthChecks的种类
k8s提供了两种HealthChecks的方法,理解他们的异同与用法是非常重要的。

Readiness
Readiness Probe 的设计的目的是让k8s明确知道pod何时已经完全就绪。在向POD发送请求通信之前,首先进行Readiness Probe测试。如果该测试没有通过,则k8s停止向其发送通信请求,直到测试通过。

Liveness
Liveness Probe 是为了让k8s知道pod是否存活(而不一定可用)。如果POD死掉,则k8s会将其remove并启动一个新的而取代。


HealthCheck是如何工作的?
Readiness
想象一下你的POD刚刚开始启动,但是相应的服务并不一定就会立刻就绪直到POD完全启动完成,即使相应的进程已经出现了。默认情况下k8s会立刻向POD发送请求一旦进程启动(但此时不一定可用)。
因此使用Readiness Probe,k8s会等待POD完全ready后才会向其发送请求。

Liveness
想象另一个场景,当你的POD因为某种原因一直处于挂起状态且不能响应任何请求,然而此时进程却是存在的,因此k8s会认为一切正常并持续向已经挂起的POD发送请求。
但若使用了Liveness Probe,k8s会发现该POD已经停止响应,进而重启这个有问题的POD。


Probe 的类型
有3种Probe: HTTP,Command 和 TCP。可以使用任意一个进行liveness and readiness checks.

HTTP Probe:
这是一种最常见的自定义liveness probe。 即使你POD内的应用程序不是HTTP server,你可以在应用中创建一个轻量级的HTTP server
来响应liveness probe。 k8s会ping一个指定路径,如果获得200~300之间的响应代码,则表明应用程序是健康的。
https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/#define-a-liveness-http-request

Command Probe:
k8s 在你的container内运行一段命令。如果这段命令返回值是0,则说明该container是健康的;否则它会被标记为不健康。这种探针在你不能或者不愿意运行http server时很有用,
可以仅仅通过一个命令检查你的应用时否健康。
https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/#define-a-liveness-command

TCP Probe:
这种Probe,k8s会尝试在一个特定的端口建立一个TCP连接。如果连接建立成功,则说明container健康,反之不健康。例如gPRC或者FTP服务是主要用于此类Probe。
https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/#define-a-tcp-liveness-probe


配置初始的探测延迟
我们可以指定多久运行一次Probe,包括探测成功与失败的阈值,同时也包括需要等待响应的时长。以下文档非常清楚地阐述了各种不同的选项与用途:
https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/#configure-probes
然而,有一个非常重要的设置你需要配置以决定何时使用liveness probes。 它就是initialDelaySeconds。
前面提到过,一个liveness probe如果检测失败会导致POD重启。你需要确定该Probe不会启动直到应用完全就绪。否则应用可能将一直持续重启并永远不会就绪!
我建议将Probe启动延迟设置为POD启动的平均时间并增加少许冗余。当你的应用启动的更快或者更慢是,请酌情更新这个数值。

结论:很多人告诉你HealthCheck是任何分布式系统需要的,k8s也不例外。 使用HealthCheck将让你的k8s有坚固的基础,更好的可靠性与更长的运行时间。幸好,k8s让其轻松实现了!


◎欢迎参与讨论,请在这里发表您的看法、交流您的观点。