Kubernetes 探针详解！

分 布式系统和微服务体系结构的挑战之一是自动检测不正常的应用程序，并将请求（request）重新路由到其他可用系统，恢复损坏的组件。健康检查是应对该挑战的一种可靠方法。 使用 Kubernetes，可以通过探针配置运行状况检查，以确定每个 Pod 的状态。

默认情况下，Kubernetes 会观察 Pod 生命周期，并在容器从挂起（pending）状态转移到成功（succeeded）状态时，将流量路由到 Pod。Kubelet 会监控崩溃的应用程序，并重新启动 Pod 进行恢复。许多开发人员认为这样的基本设置就足够了，尤其是当 Pod 内的应用程序还配置了守护进程管理器（例如 Node.js 的 PM2）时。

但有一种意外情况，当 Kubernetes 在所有容器启动后，认为 Pod 是健康且可以接受请求时，但应用程序在实际准备就绪之前就已收到流量，比如应用程序在处理应用程序逻辑之前，初始化了一些状态，建立了数据库连接或加载了数据。当 Deployment 开始扩展时，未就绪的应用程序会接收流量并返回 500 错误，这造成了 应用程序实际的准备就绪与 Kubernetes 认为的准备就绪之间的时间间隔问题 。

同样的，这也是 Kubernetes 探针用来定义容器何时准备接受流量，以及何时重新启动容器的方式。从 Kubernetes v1.16 开始，已经支持三种类型的探针。 在本文中将介绍这三种类型的探针、最佳实践和有关工具，以检测可能存在的配置问题。

Kubernetes 探针

Kubernetes 版本小于 v1.15 时支持 readiness 和 liveness 探针，在 v1.16 中添加了 startup 探针作为 Alpha 功能，并在 v1.18 中升级为 Beta。

这三种探针均具有以下参数：

• initialDelaySeconds
  ：启动 liveness、readiness 探针前要等待的秒数。
• periodSeconds
  ：检查探针的频率。
• timeoutSeconds
  ：将探针标记为超时（未通过运行状况检查）之前的秒数。
• successThreshold
  ：探针需要通过的最小连续成功检查数量。
• failureThreshold
  ：将探针标记为失败之前的重试次数。对于 liveness 探针，这将导致 Pod 重新启动。对于 readiness 探针，将标记 Pod 为未就绪（unready）。

Readiness 探针

readiness 探针可以让 kubelet 知道应用程序何时准备接受新流量。 如果应用程序在进程启动后需要一些时间来初始化状态，要配置 readiness 探针让 Kubernetes 在发送新流量之前进行等待。readiness 探针的主要作用是将流量引导至 service 后的 deployment。

关于 readiness 探针有一点很重要，它会在容器的整个生命周期中运行。 这意味着 readiness 探针不仅会在启动时运行，而且还会在 Pod 运行期间反复运行。 这是为了处理应用程序暂时不可用的情况（比如加载大量数据、等待外部连接时）。 在这种情况下，我们不一定要杀死应用程序，可以等待它恢复。 readiness 探针可用于检测这种情况，并在 Pod 再次通过 readiness 检查后，将流量发送到这些 Pod。

Liveness 探针

liveness 探针用于重新启动不健康的容器。 Kubelet 会定期地 ping liveness 探针，以确定健康状况，并在 liveness 检查不通过的情况下杀死 Pod。liveness 检查可以帮助应用程序从死锁中恢复。如果不进行 liveness 检查，Kubernetes 会认为死锁中的 Pod 处于健康状态，因为从 Kubernetes 的角度来看，Pod 的子进程仍在运行，是健康的。通过配置 liveness 探针，kubelet 可以检测到应用程序处于不健康状态，并重新启动 Pod 以恢复可用性。

Startup 探针

startup 探针与 readiness 探针类似，但它仅在启动时执行，能针对启动缓慢的容器或在初始化过程中有不可预测行为的应用程序进行优化。 借助 readiness 探针，我们可以配置  initialDelaySeconds  来确定 readiness 探测在准备就绪前要等待多长时间。

假设有一个偶尔需要下载大量数据的应用程序，由于  initialDelaySeconds  是一个静态数字，因此该应用程序即使不需要那么长的初始化等待时间，我们也必须设置最保守的等待时间。通过 startup 探针，我们可以配置  failureThreshold  和  periodSeconds  来解决该问题，例如设置  failureThreshold  为 15， periodSeconds  为 5，这意味着应用程序在失败之前会有 10×5=75s 的启动时间。

配置探针

现在我们了解了不同类型的探针，下面是配置每种探针的三种不同方式。

HTTP

kubelet 将 HTTP GET 请求发送到 endpoint，并检查 2xx 或 3xx 响应。我们可以重复使用现有的 HTTP endpoint 或设置轻量级 HTTP 服务器以进行探测（例如，具有  /healthz  endpoint 的 Express server）。HTTP 探针包含其他额外参数：

• host
  ：要连接的主机名（默认值：pod 的 IP）。
• scheme
  ：HTTP（默认）或 HTTPS。
• path
  ：HTTP/S 服务器上的路径 。
• httpHeaders
  ：自定义标头（如果需要标头用于身份验证、CORS 设置等） 。
• port
  ：访问服务器的端口名称或端口号。

TCP

如果仅需要检查是否可以建立 TCP 连接，则可以指定 TCP 探针。如果建立 TCP 连接，则将 Pod 标记为运行状况良好。对于不适合使用 HTTP 探针的 gRPC 或 FTP 服务器，TCP 探针可能会有用。

Command

可以将探针配置为运行 shell 命令。如果命令返回的退出代码为 0，则检查通过，否则 Pod 将被标记为不健康。如果不希望公开 HTTP 服务器与端口，或者希望通过命令检查初始化步骤（例如，检查是否已创建配置文件、运行 CLI 命令），这种类型的探针会很有用。

最佳实践

虽然说探针的确切参数和使用方法取决于应用程序，但也有一些常用的最佳实践：

• 对于较旧的（≤v1.15）Kubernetes 集群，使用具有初始延迟的 readiness 探针来处理容器启动阶段。

• 对于较新的（≥v1.16）Kubernetes 集群，如果是具有不可预测或可变启动时间的应用程序应使用 startup 探针。
  startup 探针与 readiness 和 liveness 探针共享相同的 endpoint（例如 
  /healthz
  ），但能将 
  failureThreshold
   设置得比其他探针更高，以拥有更长的启动时间，相对于 liveness 和 readiness 而言，设置的失败时间会更合理。

• 如果 readiness 探针不用于其他信号目的，readiness 和 liveness 探针可以共享相同的 endpoint，但如果只有一个 Pod（也就是使用 VPA）时，设置 readiness 探针来解决启动行为，使用 liveness 探针来确定运行状况。这种情况下，标记 Pod 不健康意味着停机时间。

• readiness 检查可以用各种方式来发出系统故障的信号。例如，当应用程序失去与数据库的连接时，可以使用 readiness 探针暂时阻止新请求并允许系统重新连接。它还可以将繁忙的 Pod 标记为未准备，将工作负载平衡到其他 Pod。

简而言之，定义明确的探针通常会带来更好的弹性和可用性。确保观察启动时间和系统行为，在应用程序更改时调整探针设置。

工具

最后，鉴于 Kubernetes 探针的重要性，我们可以使用 Kubernetes 资源分析工具来检测缺失的探针。这些工具可以在现有集群上运行，也可以置入 CI/CD 流程中，可以在没有正确配置资源的情况下自动拒绝工作负载。

• polaris：一个具有仪表板的资源分析工具，也可以用作验证 webhook 或 CLI 工具。

• kube-score：一个静态代码分析工具，可用于 Helm、Kustomize 和标准 YAML 文件。

• popeye：只读的实用工具，用于扫描 Kubernetes 集群并报告配置中的潜在问题。

原文链接： https://medium.com/dev-genius/understanding-kubernetes-probes-5daaff67599a