Pod 健康检查和服务可用性检查

一、简介

K8s 对 Pod 的健康检查是通过三类探针来实现的：
LivenessProbe、ReadinessProbe、StartupProbe，其中以 LivenessProbe、ReadinessProbe这个两个探针最为主要。

其实，这里有一个问题开始对我是有一些困扰的，那就是：

到底 K8s 是通过什么东西（组件）来启动探针，进而对 Pod 进行定期的健康检查呢？

答案是：kubelet

kubelet 会在集群中每个节点（node）上运行，Ta 与 API服务器通信，并管理 TA 所在节点的容器，保证容器（containers）都运行在 Pod 中。

kubelet 接收一组通过各类机制提供给它的 PodSpecs， 确保这些 PodSpecs 中描述的容器处于运行状态且健康。 kubelet 不会管理不是由 Kubernetes 创建的容器。

二、LivenessProbe

用于判断容器是否存活（对应的是 Running 状态），当 LivenessProbe 探测到容器不健康，则 kubelet 将 kill 掉该容器，并依据容器的重启策略进行后续的处理。如果容器没有设置 LivenessProbe，那么 kubelet 则会认为该容器的 LivenessProbe 永远返回 SUCCESS。

三、ReadinessProbe

用于判断容器服务是否可用（Ready状态），达到 Ready 状态的 Pod 才可以死接收请求。拿 Service 与 Pod 来举例，Service 中的 Endpoint 与 Pod 的关联关系也是基于Pod 是否处于 Ready。Pod 在运行过程中 Ready 状态变为 False，则 K8s 会将该 Pod从 Service 的 Endpoint 列表中删除，这样，客户端的请求就不会被路由到这个 Pod 上了。当该 Pod 的 Ready 状态恢复了，K8s 又会将该 Pod 加回。

这里有一点需要注意：

ReadinessProbe 是定期触发执行的，存在于 Pod 的整个生命周期中。

四、StartupProbe

主要会用在应用启动比较慢的场景中，例如：某应用启动的时候需要进行远程的网络连接，网络情况不稳定，造成访问较慢的 情况出现，这样就会导致容器启动缓慢，此时要是使用 ReadinessProbe 有些不太适合，因为，启动这件事儿属于“有且仅有一次”的超长延时（ReadinessProbe 是定期触发执行的），此时使用 StartupProbe 更为适合。

五、如何实现这些探针

以上三种探针都可以通过下边三种方式来实现：

1. ExecAction
   容器内运行一个命令，如果该命令的返回码为0，则表表明器健康。
2. TCPSocketAction
   通过容器的IP地址和端口号执行TCP检查，如果能够简历TCP连接，则表明容器健康。
3. HTTPGetAction
   通过容器的IP地址，端口号及路径，调用HTTP Get方法，如果响应的状态码大于等于200且小于400，则认为容器健康。

对于上边提到的每种探测方式，都需要设置 initialDelaySeconds 和 timeoutSeconds两个参数，含义如下：

1. initialDelaySeconds：容器启动后进行首次健康检查的等待时间，单位为秒。
2. timeoutSeconds：健康检查发送请求后等待响应的超时时间，单位为秒。当超时发生时，kubelet会认为容器服务提供服务，将会重启该容器。