16 K8S 之容器健康监测

监测容器自身运行的 API 包括分别用于健康状态检测、指标、分布式跟踪和日志等实现类型。即便没有完全实现，至少容器化应用也应该提供用于健康状态检测（liveness 和 readiness）的 API，以便编排系统能更准确地判定应用程序的运行状态。

存活状态检测：用于判定容器是否处于“运行”状态；若此类检测未通过，kubelet 将杀死容器并根据其 restartPolicy 决定是否将其重启；未定义存活性检测的容器的默认状态为 Success。

就绪状态检测：用于判断容器是否准备就绪并可对外提供服务；未通过该检测时，端点控制器（例如 Service 对象）会将其 IP 地址从所有匹配到此 Pod 对象的 Service 对象的端点列表中移除；检测通过之后，会再次将其 IP 添加至端点列表中；未定义就绪状态检测的容器的默认状态为 Success。

kubelet 可在活动容器上分别执行由用户定义的启动状态检测（startupProbe）、存活状态检测（livenessProbe）和就绪状态检测（readinessProbe），定义在容器上的存活状态和就绪状态操作称为检测探针，它要通过容器的句柄（handler）进行定义。

ExecAction：通过在容器中执行一个命令并根据其返回的状态码进行的诊断操作称为 Exec 探测，状态码为 0 表示成功，否则即为不健康状态。

TCPSocketAction：通过与容器的某 TCP 端口尝试建立连接进行诊断，端口能够成功打开即为正常状态，否则为不健康状态。

HTTPGetAction：通过向容器 IP 地址的某指定端口的指定 path 发起 http GET 请求进行诊断，响应码为 2xx 或 3xx 即为成功，否则为失败。

一个容器之上仅能定义一种类型的探针，即 exec、httpGet 和 tcpSocket 三者互斥，它们不可在一个容器同时使用。

initialDelaySeconds <integer>：首次发出存活探测请求的延迟时长，即容器启动多久之后开始第一次探测操作，显示为 delay 属性；默认为 0 秒，即容器启动后便立刻进行探测；该参数值应该大于容器的最大初始化时长，以避免程序永远无法启动。

timeoutSeconds <integer>：存活探测的超时时长，显示为 timeout 属性，默认为 1 秒，最小值也为 1 秒；应该为此参数设置一个合理值，以避免因应用负载较大时的响应延迟导致 Pod 被重启。

periodSeconds <integer>：存活探测的频度，显示为 period 属性，默认为 10 秒，最小值为 1 秒；需要注意的是，过高的频率会给 Pod 对象带来较大的额外开销，而过低的频率又会使得对错误反应不及时。

successThreshold <integer>：处于失败状态时，探测操作至少连续多少次的成功才被认为通过检测，显示为 #success 属性，仅可取值为 1。

failureThreshold：处于成功状态时，探测操作至少连续多少次的失败才被视为检测不通过，显示为 #failure 属性，默认值为 3，最小值为 1；尽量设置宽容一些的失败计数，能有效避免一些场景中的服务级联失败。

HTTP 探针这种检测方式仅对分层架构中的当前一层有效，例如，它能检测应用程序工作正常与否的状态，但重启操作却无法解决其后端服务（例如数据库或缓存服务）导致的故障。此时，容器可能会被反复重启，直到后端服务恢复正常。其他两种检测方式也存在类似的问题。

restartPolicy 适用于 Pod 对象中的所有容器，而且它仅用于控制在同一个节点上重新启动 Pod 对象的相关容器。首次需要重启的容器，其重启操作会立即进行，而再次重启操作将由 kubelet 延迟一段时间后进行，反复的重启操作的延迟时长依次为 10 秒、20 秒、40 秒、80 秒、160 秒和 300 秒，300 秒是最大延迟时长。

就绪探针也支持 Exec、HTTP GET 和 TCP Socket 这 3 种探测方式，且它们各自的定义机制与存活探针相同。因而，将容器定义中的 livenessProbe 字段名替换为 readinessProbe，并略做适应性修改即可定义出就绪性检测的配置来，甚至有些场景中的就绪探针与存活探针的配置可以完全相同。