[译]Kubernetes 最佳实践：使用readiness和liveness探测器做HealthChecks

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

默认情况下，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让其轻松实现了！