Kubernetes 设计模式笔记 —— Health Probe

Health Probe 模式主要关注 Kubernetes 如何获取某个应用的健康状态。为了实现完全自动化,一个云原生应用必须是高度可观测的,从而 Kubernetes 能够推断应用的状态,检测应用是否已经启动,是否已经准备好接收请求。
这些观测结果会影响 Pod 的生命周期管理,以及网络流量被路由到应用的具体路径。

Kubernetes 会定期检测容器中进程的状态,如果有错误发生,就立即重启该容器。然而在实践中,通过检查进程状态来确定应用是否健康,并不总是有效。
很多情况下应用提供的服务中断了,但进程仍旧在运行。比如 Java 应用有可能抛出 OutOfMemoryError 同时 JVM 进程仍在运行。此外,应用还有可能因为无限循环、死锁或者缓存异常等原因冻结。
因此 Kubernetes 需要一种可靠的方式来检查应用的健康状态,不关注应用的内部工作流程,而是通过某些指标,衡量应用能否对外提供服务。

软件行业已经接受了这样一个事实,即写出完全没有 bug 的软件是不现实的。因此当面对 failures 时,可以把关注点从避免 bug 转移到如何快速检测到失效并自动恢复。
但错误检测并不是一个简单的对所有应用通用的任务,存在很多不同的对于错误的定义,并且不同类型的错误也需要不同的应对方式。

Process Health Checks

process health check 是最简单的一种 health check 方式,由 Kubelet 持续对容器进程进行检测。若容器进程没有处于运行状态,即对其进行重启。
如果应用本身能够检测到任意类型的错误并自行终止,凭借 process health check 就足够完成健康检查任务。

Liveness Probes

假如应用会进入某种死锁状态,进程并未停止运行,因而从 process health check 的角度看应用仍然是健康的。Kubernetes 可以通过 liveness probes 来检测此类错误。
能够从应用外部执行健康检测,而不是仅仅依靠应用本身,这一点是非常重要的。因为有些错误有可能会阻止应用本身的 watchdog 对外报告异常。
liveness probes 看上去和 process health check 非常相似,它们都会在检测到异常时重启容器。但前者提供了更多的灵活性:

  • HTTP probe:向容器的 IP 地址发起 HTTP GET 请求,期待获取一个成功的 HTTP 响应码(200 - 399)
  • TCP Socket probe:测试是否能完成完整的 TCP 连接
  • Exec probe:在容器内部执行任意的命令,期待获取一个成功的退出码(0)

基于 HTTP 的 liveness probe 示例:

apiVersion: v1
kind: Pod
metadata:
  name: pod-with-liveness-check
spec:
  containers:
  - image: k8spatterns/random-generator:1.0
    name: random-generator
    env:
    - name: DELAY_STARTUP
      value: "20"
    ports:
    - containerPort: 8080
    protocol: TCP
    livenessProbe:
      httpGet:
        path: /actuator/health
        port: 8080
      initialDelaySeconds: 30

其中 httpGet 中的 path 项用于配置 HTTP probe 执行健康检测时请求的端点;initialDelaySeconds 用于配置执行第一次检测前等待的时间,以等待应用启动后完成 warm up。

需要注意的是,未通过 liveness probe 检查的后果就是容器被重启,若容器重启对于解决问题没有任何效果,则 liveness probe 本身也不会再有任何其他作用。

Readiness Probes

Liveness 检查通过杀掉不健康的容器并将它们替换为新的容器实例,来确保应用处于健康状态。但有些时候容器遇到问题,重启它们并不会令其恢复健康。最常见的情况就是容器正处于启动过程中,还没有准备好处理任何请求。或者有可能容器负载过高导致延迟极度增长。

在上述场景下,Kubernetes 提供了 readiness probe 特性。Readiness 检查和 Liveness 检查提供的检测方法是一样的(都是 HTTP、TCP 和 Exec),只有触发的操作不同。
失败的 Readiness 检查会将容器从 Service 端点移除,确保其不再对外提供任何服务。它关注的重点在于容器是否已经准备好,有些容器在启动时需要一定的 warm up 时间才能处理请求。
Readiness probe 在容器启动后依然会定期运行,从而将不能对外提供服务的容器屏蔽掉,保证未准备好的容器不会接收到外部的请求。

即 Liveness probe 触发的操作是重启容器,目的是不健康的容器尽可能恢复服务;Readiness probe 触发的操作是将容器从 Service 移除,目的是确保不健康的容器不会对外提供服务,用户的请求只会转发到健康的容器。
当然在容器重启时,Kubernetes 也会尽力确保该容器不会再收到用户请求,不管 Readiness probe 是否通过。

Readiness probe 示例:

apiVersion: v1
kind: Pod
metadata:
  name: pod-with-readiness-check
spec:
  containers:
  - image: k8spatterns/random-generator:1.0
    name: random-generator
    readinessProbe:
      exec:
        command: [ "stat", "/var/run/random-generator-ready" ]

Process health check 和 liveness probe 的目的都是通过重启容器来使应用能从错误中自动恢复。Readiness probe 则力求为处于恢复中的容器争取足够的时间。

总结

容器技术为打包和运行应用实现了一系列统一的接口,从而可以将应用作为黑盒(black box)看待。
然而任何致力于成为云原生应用的容器,必须为运行时环境提供一系列必要的 API,对容器的健康状态进行统一的观测,并执行对应的操作。这是容器能统一地实现自动化升级和生命周期管理的基础需求,从而提高系统的稳定性和用户体验。
这意味着容器化应用必须为多种不同的健康检测(liveness 和 readiness)提供需要的 API。
甚至更优异的应用还必须为管理平台提供其他手段,以方便更好地观测容器化应用的状态,比如与 Prometheus 进行整合。将应用视为一种黑盒,同时实现必须的 API 接口,方便平台对其进行监控和管理。

参考资料

Kubernetes Patterns

你可能感兴趣的:(Kubernetes 设计模式笔记 —— Health Probe)