配置 readiness、liveness 和 startup 探针可以处理不健康的 Pod，小编介绍了三种类型的探针、最佳实践和有关工具，以检测可能存在的配置问题。

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

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

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

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

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

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

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

       

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

• 对于较旧的（≤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 集群并报告配置中的潜在问题。