健康检查配置

本文视频教程: https://www.bilibili.com/video/BV16q4y1y7B9

本文分享 K8S 健康检查配置的最佳实践，文末也分享配置不当的案例。

Kubernetes 健康检查介绍 ​

K8S 支持三种健康检查：

三种健康检查配置格式都是一样的，以 readinessProbe 为例:

readinessProbe:
  successThreshold: 1 # 1 次探测成功就认为健康
  failureThreshold: 2 # 连续 2 次探测失败认为不健康
  periodSeconds: 3 # 3s 探测一次
  timeoutSeconds: 2 # 2s 超时还没返回成功就认为不健康
  httpGet: # 使用 http 接口方式探测，GET 请求 80 端口的 "/healthz" 这个 http 接口，响应状态码在200~399之间视为健康，否则不健康。
    port: 80
    path: "/healthz"
  #exec: # 使用脚本探测，执行容器内 "/check-health.sh" 这个脚本文件，退出状态码等于0视为健康，否则不健康。
  #  command: ["/check-health.sh"]
  #tcp: # 使用 TCP 探测，看 9000 端口是否监听。
  #  port: 9000

探测结果一定要真实反应业务健康状态 ​

首选 HTTP 探测 ​

通常是推荐业务自身提供 http 探测接口，如果业务层面健康就返回 200 状态码；否则，就返回 500。

备选脚本探测 ​

如果业务还不支持 http 探测接口，或者有探测接口但不是 http 协议，也可以将探测逻辑写 到脚本文件里，然后配置脚本方式探测。

尽量避免 TCP 探测 ​

另外，应尽量避免使用 TCP 探测，因为 TCP 探测实际就是 kubelet 向指定端口发送 TCP SYN 握手包，当端口被监听内核就会直接响应 ACK，探测就会成功:

当程序死锁或 hang 死，这些并不影响端口监听，所以探测结果还是健康，流量打到表面健康但实际不健康的 Pod 上，就无法处理请求，从而引发业务故障。

所有提供服务的 container 都要加上 ReadinessProbe ​

如果你的容器对外提供了服务，监听了端口，那么都应该配上 ReadinessProbe，ReadinessProbe 不通过就视为 Pod 不健康，然后会自动将不健康的 Pod 踢出去，避免将业务流量转发给异常 Pod。

谨慎使用 LivenessProbe ​

LivenessProbe 失败会重启 Pod，不要轻易使用，除非你了解后果并且明白为什么你需要它，参考 Liveness Probes are Dangerous 。

探测条件要更宽松 ​

如果使用 LivenessProbe，不要和 ReadinessProbe 设置成一样，需要更宽松一点，避免因抖动导致 Pod 频繁被重启。

通常是失败阈值 ( failureThreshold ) 设置得更大一点，避免因探测太敏感导致 Pod 很容易被重启。

另外如果有必要，超时时间 ( timeoutSeconds ) 和探测间隔 ( periodSeconds ) 也可以根据情况适当延长。

保护慢启动容器 ​

有些应用本身可能启动慢(比如 Java)，或者用的富容器，需要起一大堆依赖，导致容器启动需要的较长，如果配置了存活检查，可能会造成启动过程中达到失败阈值被重启，如此循环，无限重启。

对于这类启动慢的容器，我们需要保护下，等待应用完全启动后才开始探测:

避免依赖导致级联故障 ​

LivenessProbe 探测逻辑里不要有外部依赖 (db, 其它 pod 等)，避免抖动导致级联故障。

如上图，Pod B 探测逻辑里查 DB，Pod A 探测逻辑里调用 Pod B，如果 DB 抖动，Pod B 变为不健康，Pod A 调用 Pod B 也失败，也变为不健康，从而级联故障。

反面教材 ​

突然无限重启且流量异常 ​

故障现象: Pod 突然不断重启，期间有流量进入，这部分流量异常。