本文翻译自 Kubernetes Probes (and Why They Matter for Autoscaling)。

除了验证我们的工作负载的健康状况之外，我们还可以使用它们来监视和收集有关影响容器的其他事件的信息。

验证我们的工作负载（在 Kubernetes 上运行的应用程序）的健康状况对于它们的成功至关重要。为了管理工作负载健康状况，我们依赖遥测信息和诊断，这些信息和诊断通常通过系统和应用程序组件捕获，然后发送到监控工具。传输后，这些数据将以度量的形式与系统管理员、DevOps 团队和站点可靠性工程师 (SRE) 共享，以帮助确定我们必须在何处采取行动。

一种收集遥测信息的方法是使用探针。这个过程是一个诊断检查，其中负载平衡器向其定义的端点（例如 web-server 集群）发送健康探针，以验证应用程序是否可用并正在运行。如果端点没有响应，负载平衡器（在这种情况下）将跳过端点而不将用户发送到可能失败的网站。这意味着探针已经失败了。

我们可以使用 Kubernetes 探针在 Kubernetes 中执行这些检查。Kubelet（每个 Kubernetes 节点服务器上的主要节点代理）定期对我们的容器进行探测。Kubernetes 探针允许我们验证集群中运行的 pod 的状态。除了验证我们的工作负载的健康状况和功能之外，我们还可以使用 Kubernetes 探针监控和收集有关影响容器的其他事件（如自动缩放）的信息。

本文将解释不同类型的探针及其重要性。我们将讨论它们的工作原理，特别是它们如何支持自动缩放。然后，我们将强调为什么找到正确的探针设置至关重要，以及为什么实验是优化探针设置的关键。

有许多因素有助于 Kubernetes 探针的有效使用，也有许多相关的好处。让我们一起探索 Kubernetes 探针是什么，突出它们的好处，以及如何充分利用它们。

在探索如何有效地使用 Kubernetes 探针之前，我们必须熟悉三种类型的 Kubernetes 探针：启动（startup），就绪（readiness）和存活（liveness）。

在运行时序列中，探针使用的流程如下：

Startup 探针是第一个启动的，它告诉 kubelet 容器内的应用程序已经成功启动。其他两个探针将被禁用，直到启动探针处于成功状态。

慢启动容器的监控中，startup 探针是非常有用的。如果使用 liveness 探针代替，因为应用程序似乎还没有成功启动，所以可能会过早地终止容器。

Readiness 探针告知 Kubernetes 集群，容器已准备好接受请求，比如允许用户连接到 Web 应用程序。如果 readiness 探测失败，则不会向 Pod 发送 IP 地址。因此，Pod 会从相应的服务中移除。

Readiness 探针可以保证运行在容器中的应用程序已经 100％ 准备好使用。但是，有时候 readiness 探针是不可能做到这一点的。例如，想象一下死锁的情况，其中应用程序进程仍在运行，但不再服务请求。由于准备性探针假定应用程序正常运行，因此不会检测到未服务的请求。这种情况表明有必要同时使用 readiness 探针和 liveness 探针。

可能你会想，是否总需要使用 liveness 和 readiness 探针。答案取决于容器化应用的性质。 既然 readiness 探针主要用于确认容器已准备好接受网络请求，因此如果我们的应用不依赖于网络请求，比如在容器内运行不需要网络交互的内部进程，则可以省略它。

Liveness 探针可以确认容器是否正在运行。如果探针发出的信号表明当前状态非运行中，Kubelet 将捕捉到这个信号并杀死容器进程。通常情况下，容器会重新启动，除非它的配置方式有所不同。

即使 liveness 探针确认容器正在运行，也不能保证容器的应用程序也在运行。Pod 可能已经就绪，但并不意味着应用程序可以提供请求服务。

但即使 liveness 探测确认容器正在运行，也不能保证容器的应用程序正在运行。 Pod 可能已经准备就绪，但这并不意味着应用程序可以处理请求。

想象一个Web应用程序，它显示一个 HTTP 503 错误页面，因为它无法连接到后端数据库，这使它可以检索信息。 从 liveness 探针的角度来看，容器正在运行，因为 Web 组件就好像 Web 页面是活跃的一样运行。 然而，应用程序不处于成功状态，因为 Web 页面无法连接到数据库。

Kubernetes 探针可以做更多事情，而不仅仅是帮助我们了解应用程序的健康状况。它们还支持根据健康度量标准制定良好的计划并有效地实现自动缩放。

当 pod 自动添加以支持扩张的应用程序工作负载时（通常是在需求增加导致CPU、内存或其他关键资源需求增加时），就会实现水平 pod 自动伸缩。此外，当需求减少时，水平 pod 自动扩展也会自动停止和删除不必要的 pod。与扩张或缩小计算需求的相似反应，垂直 pod 自动伸缩是指 pod 以更大或更小的资源量进行重新配置。

正确使用和配置 startup 、 liveness 和 readiness 探针对于促进自动伸缩事件的完成至关重要。

即使探针对Kubernetes自动扩展来说不是必需的，但它们的正确使用可以通知自动伸缩过程并验证受影响的容器实际上已经启动或关闭。 如果正确地使用和配置 startup、 liveness 和 readiness 探针，此序列可以更快、更有效地完成自动伸缩事件。 为什么？ 如果探针设置在合理时间内不能返回成功响应，则可能添加或删除额外的 Pods 以满足自动伸缩的需要，而实际上当探针按预期返回成功并将第一组 Pods 标记为就绪后，它们可能不再需要。

Kubernetes提供了几个参数来调整 startup、 liveness 和 readiness 探针。

每个参数都有默认值，但是我们的特定环境可能需要使用不同的参数值。例如，探针所收集的默认参数值可能不足以理解应用程序为什么启动得很慢。或者，默认值可能会捕捉和生成太多信息，使得很难得出有用的结论。

我们可以配置以下所有参数，这些参数对于 Kubernetes 中的三种探测类型都有效。

默认情况下，timeoutSeconds 参数设置为1秒，这意味着容器有一秒的时间来响应探针请求。

假设我们容器或应用探针的 timeoutSeconds 参数默认设置为 1 秒。在这种情况下，速度较慢的容器可能没有足够的时间响应，这可能导致容器被终止。由于可能需要比平时更长的时间才能将不响应的容器标记为“失败”，因此可能需要增加此参数的值（可能需要几秒）。

periodSeconds 指定了（以秒为单位）多长时间检查一次探针。像 timeoutSeconds 参数一样，正确设置 periodSeconds 具有很重要的意义。如果检查周期过于频繁，可能会使应用程序负载超负荷。而如果检查不够频繁，可能就无法及时了解应用程序是否失败了。

FailureThreshold 体现了失败请求或响应的数量。 默认阈值是 3，这意味着当容器错失三个连续的探测（假设 timeoutSeconds 和 periodSeconds 根据默认值进行配置）时，容器将被标记为失败。

initialDelaySeconds 意味着在容器启动成功后，在发出信号之前所需的时间。默认值为零，这意味着在容器成功启动后，探针就会立即发出信号。

对于启动较慢的容器或应用，可能最好将此延迟设置为更高的值。最初，Kubernetes只提供了 readiness 和 liveness 探针。尽管这一般运作良好，但是在某些情况下，由于应用尚未准备就绪，但容器运行良好，探针会产生错误。这也是为什么引入启动探针的原因：要验证容器正在启动而不立即检查应用程序的健康状况。

successThreshold 反映了用于确保容器处于成功状态所需的正面探测信号的数量。默认数字是一，这意味着探针必须至少有一个正面信号才能将容器状态指定为成功状态。如果我们不想仅依靠探针的一个脉冲来确认容器的健康状态，我们可以将这个值更改为更高的数字。

伴随着容器管理和运行 Kubernetes 的复杂性，要确定上述参数的“绝对正确”值可能很困难。我们必须了解应用程序启动速度以及在负载下的行为，以便决定各种探测设置应该是什么，以满足 SLA 或 SLO 。必须考虑各种参数和设置的组合及它们彼此之间的作用，这意味着探针调优不是一门精准科学。

实验探针允许我们验证不同的参数设置，并了解它们如何影响 Kubernetes pods 的行为。

进行实验乃至关重要，通常在测试环境上进行，探针实验可以验证不同的参数设置，了解它们如何影响 Kubernetes Pod 的行为。它还有助于我们理解容器、应用程序和集群的整体健康状况。

通过在不同场景下使用探测试验流程来运行多次测试，我们可以提高探测器参数设置的准确性。

探针和它们相应的参数通过 Kubernetes YAML 文件配置，类似于部署其他 Kubernetes 资源的方式。

下面是一个 YAML 文件的例子:

apiVersion: v1
kind: Pod
metadata:
  labels:
    test: readiness
    name: readiness-demo
spec:
  containers:
  - name: probe-app
    image: registry.k8s.io/alpine
    ports:
      containerPort: 8080
    readinessProbe:
      httpGet:
        path: /health
        port: 8080
      initialDelaySeconds: 5
      timeoutSeconds: 1
    livenessProbe:
      httpGet:
        path: /health
        port: 8080
      initialDelaySeconds: 15
      timeoutSeconds: 1

这个例子中，容器在端口 8080 上侦听，并且在网络应用程序中构建了一个 /health 端点用于健康检查。它有助于验证应用程序的 readiness 状态和 liveness 状态。

Readiness 探针会通过 HTTP GET 请求发送到该端点，带有 5 秒的初始延迟和 1 秒的超时。如果端点在给定时间内返回成功响应（HTTP 200），则容器被认为是就绪的。

Liveness 探测也是类似的，但它用于检查容器是否仍在运行并响应请求。在本例中，它具有 15 秒的初始延迟和 1 秒的超时时间。如果 liveness 探测失败，Kubernetes 会重新启动容器以尝试恢复它。

Readiness 探针和 liveness 探针都可以确保应用程序正常运行，并可以处理来自Kubernetes集群其他部分的请求。

在选择这些探针及其参数的正确值时，没有金科玉律。 我们可以使用手动方法开始调整和测试不同的探针值，验证容器行为及基于探针运行容器的自动缩放方面的影响。

然而，这种手动方法非常繁琐，耗时，并可能代价很高。此外，很可能我们无法在合理的时间内收集足够的数据点来提供准确的配置决策。

通过利用自动化和基于机器学习的实验工具，我们可以收集足够的支持数据点，以了解各种配置组合如何影响并启用所需的探针行为。StormForge Optimize Pro 等工具可以将实验时间缩短数量级，并收集更多的数据点，从而帮助我们看到如何达到所需的行为。

在本文中，我们探讨了健康检查在验证容器中的重要作用，以及 Kubernetes 探针如何使我们能够执行这些检查。它们包括 startup 探针，用于验证容器工作负载的启动序列，以及定期执行诊断测试的 readiness 和 liveness 探针，以帮助我们了解正在运行的容器和应用程序的健康状况。

有效地使用 Kubernetes 探针需要我们对不同的探针参数进行实验，并进行多次测试，其中考虑包括峰值负载、缓慢启动和伸缩在内的真实应用程序或容器环境条件。 我们越准确地调整探针参数，我们的探针检查、自动缩放能力和整体 Kubernetes 应用程序性能就会越好。 但是，手动实验是乏味的和耗时的。 随着当今复杂的应用程序环境，利用自动化和基于机器学习的实验工具将帮助我们更快地找到正确的探针设置，且更准确。