k8s探针生存之道：排除错误观念，拨开迷雾见“ readiness”

2023-10-26 13:26:02

livenessProbe 与 readinessProbe：并非一模一样的健康探针

在 Kubernetes (k8s) 中，确保容器健康至关重要。为了实现这一目标，k8s 使用探针（probe）来检查容器是否正在运行并能够正常处理请求。然而，存在两种不同类型的探针：livenessProbe 和 readinessProbe，很多人错误地认为它们是一样的。本文将深入探讨这两种探针，揭示它们不同的目的和作用，并解释为什么它们必须不一样。

livenessProbe：容器生死之别

livenessProbe 承担着至关重要的职责：检查容器是否存活。如果容器没有响应 livenessProbe 检查，k8s 将认为该容器已死亡并将其重新启动。这类似于呼吸检测，当医生检查患者是否还活着时，他们会观察他们的呼吸。

livenessProbe 旨在检测容器内部故障，例如进程崩溃或死锁。通过定期检查，它可以快速识别和解决问题容器，确保应用程序持续可用。

readinessProbe：请求准备就绪的信号

另一方面，readinessProbe 关注的是容器是否准备好处理请求。如果容器没有响应 readinessProbe 检查，k8s 将认为该容器不健康并不会将流量路由到该容器。这就好比服务员检查桌子是否已准备好就餐：如果桌子没有摆好餐具或没有干净，他们就不会让顾客入座。

readinessProbe 对于避免将请求发送到尚未准备好处理它们的容器至关重要。这可以防止糟糕的用户体验，例如加载时间长或错误响应，从而保护应用程序的声誉。

为什么 livenessProbe 和 readinessProbe 必须不一样？

可能有人认为，使用同一种探针来检查容器是否存活和是否准备好处理请求更容易。然而，这种方法会产生严重的问题：

容器启动故障： 如果 livenessProbe 和 readinessProbe 都检查容器是否正在运行，则容器在启动时可能会被认为不健康，因为它们尚未准备好处理请求。这会导致容器启动失败。
无法处理请求： 如果 livenessProbe 和 readinessProbe 都检查容器是否能够处理请求，则容器在运行时可能会被错误地标记为不健康，即使它们实际上可以处理请求。这会导致流量中断和用户的不满。
终止困难： 如果 livenessProbe 和 readinessProbe 都检查容器是否正在运行，则容器在终止时可能会被认为不健康，因为它们还没有完全终止。这会阻止容器正常终止，从而浪费资源。

示例

以下是一个使用 livenessProbe 和 readinessProbe 的示例：

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
  - name: my-container
    image: my-image
    livenessProbe:
      httpGet:
        path: /healthz
        port: 8080
        scheme: HTTP
      initialDelaySeconds: 30
      periodSeconds: 10
      timeoutSeconds: 5
      failureThreshold: 3
    readinessProbe:
      httpGet:
        path: /readyz
        port: 8080
        scheme: HTTP
      initialDelaySeconds: 15
      periodSeconds: 10
      timeoutSeconds: 5
      failureThreshold: 3

在这个示例中，livenessProbe 检查容器是否正在运行（路径：/healthz），而 readinessProbe 检查容器是否准备好处理请求（路径：/readyz）。

结论

livenessProbe 和 readinessProbe 在 Kubernetes 中扮演着截然不同的角色，确保容器正常运行和响应请求。livenessProbe 负责检测容器故障，而 readinessProbe 负责检查容器是否准备好接受流量。通过正确区分这两种探针，我们可以防止应用程序出现重大问题，并为用户提供可靠且高效的体验。

常见问题解答