使用Kubernetes探针使用一二

概念

Kubernetes调度Pod到Kubernetes节点上，节点上的Kubelet运行Pod的容器。如果容器内进程终止运行（容器的主进程崩溃），Kubelet会自动重启容器，这体现了Kubernetes赋予应用的自愈能力。在某些情况下，即使容器内进程没有崩溃，应用程序仍可能处于非正常工作状态。Kubernetes默认只是检查Pod的容器是否正常运行，但容器正常运行并不一定代表应用健康。我们可以通过Kubernetes提供的探针来探测容器应用是否健康，然后决定是否重启恢复应用到正常工作状态，以及决定容器是否能接收请求。

Kubernetes探针有三种类型：

• 存活探针（Liveness Probe）：探测容器内应用程序是否健康。若不健康，意味探测失败，Kubemetes将定期执行探针并重新启动容器。
• 就绪探针（Readiness Probe）：探测容器是否已经就绪。只有当Pod内所有容器都处于就绪状态时kubelet才会认定该Pod处于就绪状态。若不健康，意味探测失败，Pod将会被Kubernetes从相应的Endpoint list中移除，请求不再分发到该Pod的容器上。特别是在容器创建后，应用程序需要进行初始化或加载数据，可能是几秒或者更长时间，这段时间里不能对外提供服务，因此不应该将请求分发到该Pod上。
• 启动探针（Startup Probe）：探测容器内应用是否启动完成。在启动探针探测成功前，存活探针和启动探针不会执行！

Kubernetes 1.16 引入了启动探针，目的是为了确保在容器内应用启动成功前，存活探针和就绪探针不会执行，以避免在启动过程中探测失败导致容器重启，容器陷入无限重启循环。在不使用启动探针时，做法是设置initialDelaySeconds的值，这样探针在该时间过后才会开始执行，这个值既不能太短也不能太长。太短，容器可能陷入无限重启循环；太长，不能及时发现应用不可用，流量可能已经被分配到Pod上。而启动时间并不好判断设置多少合适（每次启动时间差异可能较大）。使用启动探针，可以将failureThreshold和periodSeconds设置较为宽松，一旦启动探针有一次探测成功，即可将后续的探针交给存活探针和就绪探针。

Kubernetes支持三种探测方式：

• EXEC：在容器中执行一个命令，如果命令退出码返回 0 则表示探测成功，否则表示失败。
• TCPSocket：对指定的容IP及端口执行一个TCP检查，如果端口是开放的则表示探测成功，否则表示失败。
• HTTPGet：对指定的容器IP、端口及路径执行一个HTTP Get请求，如果返回的状态码在 200, 399 之间则表示探测成功，否则表示失败。

配置探针

EXEC探测

通过在目标容器中执行由用户自定义的命令来判断容器的监控状态，若命令状态返回值为 0 则表示“成功”通过检测，其他值则均为“失败”状态。执行命令例如/bin/sh -c echo liveness-http test > /usr/share/nginx/html/health

HTTPGet探测

基于HTTP的探测（HTTPGetAction）向目标容器发起一个HTTP请求，根据请求响应码进行结果判定，响应码如 2xx 和 3xx 时表示探测成功。

• 请求协议（scheme）：默认是HTTP，还可指定HTTPS
• 访问路径（path）：请求URL里除服务地址（或域名）和端口外的部分，例如 /health_check。
• 容器端口（port）：访问的容器的端口名字或者端口号，例如 80、8080等。端口号必须介于1 ~ 65525之间。当然这里还可以引用一个端口资源的名称。
• 请求头（httpHeaders）：自定义请求的header，例如 X-Custom-Header=Awsome

TCP探测

Kubelet将尝试在指定端口上打开容器的套接字。 如果可以建立连接，容器被认为是健康的，如果不能就认为是失败的。容器端口与HTTPGet里的容器端口一样。

其他配置项

探针还有其他配置项，以便更加精确地控制探针。

• 探测开始前等待时间（initialDelaySeconds）：容器启动后第一次执行探测需要等待的时间。默认值是 0 ，最小值也是 0。
• 探测间隔时间（periodSeconds）：执行探测的频率。默认是 10 秒，最小 1 秒。
• 探测超时时间（timeoutSeconds）：探测超时时间，探测未在改时间内完成将被视为失败。默认 1 秒，最小 1 秒。
• 最少连续成功次数（successThreshold）：探测失败后，最少连续探测成功多少次才被认定为成功。默认是 1，最小值是 1。注意：对于存活探针，此项必须是 1。
• 最少连续失败次数（failureThreshold）：探测成功后，最少连续探测失败多少次才被认定为失败。默认是 3，最小值是 1。

注意事项

错误使用探针会对程序运行造成坏的影响，可能让应用变得不可靠。

1. 探测开始前等待时间必须要合理，时间过短容器内程序启动未完成，可能让探测失败。在配置存活探针的情况下，容器可能会不断被重启。时间过长，探针没有及时检测到容器的状态，影响下一步操作。
2. 探测间隔时间是两次相邻探测之间的间隔时间，时间过短，探测频率高，增加了Kubelet执行压力以及容器处理请求或执行命令的压力。时间过长，探针不能及时检测到容器状态，影响下一步操作。
3. 探测超时时间对EXEC探测方式无效，Kubelet不会终止执行命令，若要让执行命令超时后退出，容器需要自行处理。
4. 对HTTPGet探测方式，访问路径对应的接口最好是不要处理业务的，而是专门判断服务是否正常，处理业务失败并不意味应用发生了异常。可单独写一个接口比如/health_check。该接口不处理任何业务逻辑，并能够很快响应请求。

参考

1. Configure Liveness, Readiness and Startup Probes 2. Liveness and Readiness Probes