Kubernetes 探针详解！

Posted 2021-10-09 豆芽太烦人

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

默认情况下，Kubernetes 会观察 Pod 生命周期，并在容器从挂起（pending）状态转移到成功（succeeded）状态时，将流量路由到 Pod。Kubelet 会监控崩溃的应用程序，并重新启动 Pod 进行恢复。许多开发人员认为这样的基本设置就足够了，尤其是当 Pod 内的应用程序还配置了守护进程管理器（例如 Node.js 的 PM2）时。但有一种意外情况，当 Kubernetes 在所有容器启动后，认为 Pod 是健康且可以接受请求时，但应用程序在实际准备就绪之前就已收到流量，比如应用程序在处理应用程序逻辑之前，初始化了一些状态，建立了数据库连接或加载了数据。当 Deployment 开始扩展时，未就绪的应用程序会接收流量并返回 500 错误，站长交易这造成了应用程序实际的准备就绪与 Kubernetes 认为的准备就绪之间的时间间隔问题。

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

K8sMeetup

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，这意味着应用程序在失败之前会有 10x5=75s 的启动时间。

K8sMeetup

配置探针

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

HTTPkubelet 将 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 ：访问服务器的端口名称或端口号。