为什么我在 kubernetes 中需要 3 种不同类型的探针：startupProbe、readinessProbe、livenessProbe

Question

为什么我在 kubernetes 中需要 3 种不同类型的探针：

• 启动探针
• 就绪探针
• 活性探针

有一些问题（k8s - livenessProbe 与 readinessProbe，设置就绪、活跃或启动探测器）和关于这个主题的文章。但这不是很清楚：

• 为什么我需要 3 种不同类型的探头？
• 有哪些用例？
• 什么是最佳做法？

Answer 1

这 3 种探针有 3 种不同的用例。这就是为什么我们需要 3 种探针。

活性探针

如果Liveness Probe失败，pod 将重新启动（阅读有关 failureThreshold 的更多信息）。

用例：如果 pod 已死，则重新启动 pod。

最佳实践：仅在活性探测中包含基本检查。永远不要检查与其他服务（例如数据库）的连接。检查不应花费太长时间才能完成。如果 pod真的死了，请始终指定一个light Liveness Probe以确保 pod 将重新启动。

启动探针

Startup Probes检查 pod 在启动后何时可用。

用例：一旦 Pod 在启动后可用，就将流量发送到 Pod。启动探测器可能需要更长的时间才能完成，因为它们仅在初始化时调用。他们可能会调用预热任务（但也可以考虑使用 init 容器进行初始化）。

最佳实践：如果 pod 需要很长时间才能启动，请指定Startup Probe。Startup 和 Liveness Probe 可以使用相同的端点，但Startup Probe 的故障阈值将不那么严格，以防止启动失败（s. Kubernetes in Action）。

准备探针

与Startup Probes Readiness Probes检查相比，Pod 在整个生命周期中是否可用。与Liveness Probes相比，只有到 pod 的流量才会停止，如果Readiness 探针失败，但不会重启。

用例：停止向 Pod 发送流量，如果 Pod 由于与另一个服务（例如数据库）的连接失败而暂时无法提供服务，并且 Pod 将在稍后恢复。

最佳实践：包括所有必要的检查，包括与其他服务的连接。尽管如此，检查不应花费太长时间才能完成。如果 Pod 可以正确处理传入的请求，请始终指定Readiness Probe以确保 Pod 仅获取流量。

文档

• 这篇文章很好地解释了三种探针之间的区别。
• 该官方kubernetes文档提供了有关所有配置选项很好的概述。
• 探针的最佳实践。
• Kubernetes in Action一书提供了有关最佳实践的最详细见解。

Answer 2

livenessProbe、readinessProbe、startupProbe的区别

\n

活性探针：

\n

 livenessProbe:\n      httpGet:\n        path: /healthz\n        port: 8080\n      initialDelaySeconds: 3\n      periodSeconds: 3\n

\n

\n
• 它用于指示容器是否已启动以及是否处于活动状态，即可用的证明。
\n
• 在给定的示例中，如果请求失败，它将重新启动容器。
\n
• 如果未提供，则默认状态为成功。
\n

\n

准备情况探针：

\n

 readinessProbe:\n      httpGet:\n        path: /healthz\n        port: 8080\n      initialDelaySeconds: 3\n      periodSeconds: 3\n

\n

\n
• 它用于指示容器是否已准备好提供流量服务或未准备好使用。
\n
• 它检查依赖项，例如数据库连接或容器完成其工作所依赖的其他服务。
\n
• 在给定的示例中，在请求返回 Success 之前，它将不会提供任何流量（通过从与 Pod 匹配的所有服务的端点中删除 Pod\xe2\x80\x99s IP 地址）。
\n
• Kubernetes 在滚动更新期间依赖于就绪性探测，它使旧容器保持正常运行，直到新服务声明它已准备好接收流量。
\n
• 如果未提供，则默认状态为成功。
\n

\n

启动探针：

\n

 startupProbe:\n      httpGet:\n        path: /healthz\n        port: 8080\n      initialDelaySeconds: 3\n      periodSeconds: 3\n

\n

\n
• 它用于指示Container内的应用程序是否已启动。
\n
• 如果提供了启动探测，则将禁用所有其他探测，直到启动探测成功。
\n
• 在给定的示例中，如果请求失败，它将重新启动容器。
\n
• 一旦启动探针成功一次，活性探针就会接管以提供对容器死锁的快速响应。
\n
• 如果未提供，则默认状态为成功。
\n

\n

查看K8S文档了解更多信息。

\n

Answer 3

这是我们在应用程序中使用的一个具体示例。它有一个简单的 HTTP 运行状况检查，可在http://hostname:8080/management/health.

ports:
  - containerPort: 8080
    name: web-traffic

应用程序初始化（启动）

• Spring 应用程序启动缓慢 - 30-120秒之间。
• 在应用程序启动之前不希望运行其他探测器。
• 在 k8s 进入崩溃循环之前，每 10 秒检查一次（ 5 秒后放弃）最多180 秒。

startupProbe:
  successThreshold: 1
  failureThreshold: 18
  periodSeconds: 10
  timeoutSeconds: 5
  httpGet:
    path: /management/health
    port: web-traffic

健康检查（准备情况）

• 每10秒Ping 一次应用程序以确保其正常运行（即接受 HTTP 请求）。
• 如果后续两次ping 失败，请将其关闭（防止级联）。
• 必须通过两次后续的健康检查才能再次接受流量。

readinessProbe:
  successThreshold: 2
  failureThreshold: 2
  periodSeconds: 10
  timeoutSeconds: 5
  httpGet:
    path: /management/health
    port: web-traffic

应用程序已死（活力）

• 如果应用程序连续3 次（间隔30秒）运行状况检查失败，请重新启动容器。也许应用程序进入了不可恢复的状态，例如 Java 耗尽了堆内存。

livenessProbe:
  successThreshold: 1
  failureThreshold: 3
  periodSeconds: 30
  timeoutSeconds: 5
  httpGet:
    path: /management/health
    port: web-traffic

Answer 4

我认为下表描述了每个的用例。

Feature	Readiness Probe	Liveness Probe	Startup Probe
考察	指示容器是否准备好服务请求。	指示容器是否正在运行。	指示容器内的应用程序是否启动。
论失败	如果就绪探测失败，端点控制器会从与该 Pod 匹配的所有服务的端点中删除该 Pod 的 IP 地址。	如果活性探测失败，kubelet 将终止容器，并且容器将遵循其重新启动策略。	如果启动探测失败，kubelet 将终止容器，并且容器将遵循其重新启动策略。
默认情况	初始延迟之前的默认就绪状态是“失败”。如果容器不提供就绪探针，则默认状态为成功。	如果容器不提供活性探测，则默认状态为成功。	如果容器不提供启动探测，则默认状态为成功。

资料来源：

• Kubernetes 的实际应用