【每日一个云原生小技巧 #16】Liveness Probes 与 Readiness Probes

在 Kubernetes 环境中，Probes 是用来检测容器内应用程序的状态的工具。具体来说，有两种类型的 Probes：Liveness 和 Readiness，它们用于确保服务按预期运行。

Liveness Probes

Liveness Probes 用来判断容器是否在运行。如果 Liveness Probe 失败，Kubernetes 会认为该容器已经死亡，这时候 Kubernetes 的 kubelet 将会重启该容器。使用 Liveness Probe 的目的是捕捉到应用程序陷入死锁的情况，无法正常工作，但进程还在运行。

使用场景：

应用程序陷入死循环
死锁
任何导致进程不响应的情况，但进程本身还没有退出

Readiness Probes

Readiness Probes 确定容器是否准备好接受流量。只有当 Readiness Probe 报告成功时，服务才会开始向该容器发送请求。如果一个 Pod 的容器未通过 Readiness Probe，那么该 Pod 将从 Service 的负载均衡中移除。

使用场景：

等待外部依赖如数据库、缓存等
应用程序正在加载大量的初始数据
动态配置加载

使用技巧

设置合适的检查间隔：
- 间隔太短可能会对容器内的应用程序或外部服务造成不必要的压力。
- 间隔太长可能会导致故障恢复不及时。
合理配置启动时间：
- 对于需要较长时间启动的应用，应适当延长 initialDelaySeconds 的时间，以免在应用未完全启动之前就被 Kubernetes 认为是不健康的。
利用成功和失败阈值：
- 可以设置 failureThreshold 和 successThreshold 来确定失败或成功的连续次数，以防止由于临时的问题而过早地重启应用。
区分 Readiness 和 Liveness：
- 避免使用相同的检查作为 Liveness 和 Readiness Probe，因为启动就绪不一定意味着健康，反之亦然。
注意 Probe 路径的选择：
- 对于 HTTP 探针，选择不需要太多资源即可响应的路径，例如 /healthz，这样可以避免探针调用对应用造成影响。
利用 exec 和 tcpSocket：
- 如果应用不提供 HTTP/S 接口，可以使用 exec 命令或 tcpSocket 检查。

实际使用案例

假设我们有一个 Web 应用程序，需要一段时间来加载数据，在这个过程中不应该接受流量。同时，应用程序可能会由于内部错误进入死锁状态，我们希望能够自动重启。

示例代码：

代码语言：javascript

复制

apiVersion: v1
kind: Pod
metadata:
  name: my-web-application
spec:
  containers:
  - name: web-container
    image: my-web-application:1.0
    livenessProbe:
      httpGet:
        path: /healthz
        port: 8080
      initialDelaySeconds: 15
      timeoutSeconds: 2
      periodSeconds: 5
      failureThreshold: 1
    readinessProbe:
      httpGet:
        path: /readiness
        port: 8080
      initialDelaySeconds: 5
      timeoutSeconds: 2
      periodSeconds: 5
      successThreshold: 1

在这个配置中：

Liveness Probe:
- 当 /healthz 端点失败时（即应用程序死锁或崩溃），在 15

秒的启动延迟后，每 5 秒检查一次。

如果探针失败，kubelet 会立即重启容器（failureThreshold 为 1）。
Readiness Probe:
- 应用启动 5 秒后，每 5 秒检查一次 /readiness 端点，以确保应用已经准备好接收流量。
- 一旦探针成功，容器将接受流量（successThreshold 为 1）。