Kubernetes 探测

功能描述

Pod 生命周期 与服务调度密切相关。通过实现官方 Kubernetes 探针，Dubbo3 甚至整个应用程序可以 Pod 的生命周期和 Pod 的生命周期。在 Pod 的整个生命周期中，只有 Pod 的健康检查部分受到影响。我们可以配置 liveness probe（存活探针）和 readiness probe（就绪探针）来 影响容器的生命周期。

通过 Dubbo3 的 SPI 机制，内部实现了各种“探针”，基于 Dubbo3 QOS 运维模块的 HTTP 服务，使容器探针能够获取应用程序中对应探针的状态。此外，SPI 的实现机制也有利于用户自行扩展内部“探针”，使整个应用程序生命周期能够得到更有效的控制。

对应三个探针的 SPI 接口

• livenessProbe: org.apache.dubbo.qos.probe.LivenessProbe
• readinessProbe: org.apache.dubbo.qos.probe.ReadinessProbe
• startupProbe: org.apache.dubbo.qos.probe.StartupProbe

该接口会自动获取当前应用程序所有 SPI 的实现，如果对应接口的 SPI 实现成功就绪，则接口会返回成功。

有关 Dubbo3 SPI 更多扩展的介绍，请参见 Dubbo SPI 扩展

使用场景

• kubelet 使用 liveness probe 来确定您的应用程序是否正在运行，以查看它是否还活着。一般来说，如果您的程序崩溃，Kubernetes 会立即知道程序已终止，然后重新启动程序。我们 liveness probe 的目的是捕获当前应用程序没有终止或崩溃。如果出现这些情况，请在该状态下重新启动容器，以便应用程序在出现错误的情况下仍然可以继续 运行下来。
• kubelet 使用 readiness probe 来确定容器是否已准备好接收流量。它现在是否已准备好并可以工作。只有当 Pod 中的容器都处于就绪状态时，kubelet 才会认为 Pod 处于就绪状态，因为一个 Pod 下面可能有多个容器。如果 Pod 未准备好，我们将从 Service 的 Endpoints 列表中将其删除，这样我们的流量就不会被路由到该 Pod。

如何使用

存活检测

对于 livenessProbe 存活检测，由于 Dubbo3 框架本身无法获取应用程序的存活状态，因此该接口没有默认实现，默认返回成功。开发者可以根据 SPI 定义扩展该 SPI 接口，并从应用程序级别判断是否存活。

关于 liveness 存活探针 扩展示例

就绪检查

对于 readinessProbe 就绪检测，Dubbo3 目前默认提供两个检测维度。一个是判断 Dubbo3 服务本身是否启动或停止，另一个是检查所有服务是否都已注册接口。如果所有服务都已从注册中心下线（您可以 通过 QOS 操作）将返回 Not Ready。

关于 readiness 就绪探针 扩展示例

启动检测

对于 startupProbe 启动检测，Dubbo3 目前默认提供一个检测维度，即所有启动流程（接口暴露、注册中心写入等）完成后返回就绪状态。

关于 startup 启动探针 扩展示例

参考示例

livenessProbe:
  httpGet:
    path: /live
    port: 22222
  initialDelaySeconds: 5
  periodSeconds: 5
readinessProbe:
  httpGet:
    path: /ready
    port: 22222
  initialDelaySeconds: 5
  periodSeconds: 5
startupProbe:
  httpGet:
    path: /startup
    port: 22222
  failureThreshold: 30
  periodSeconds: 10

QOS 当计算节点检测到内存压力时，kuberentes 会按顺序将 Pods 从 BestEffort -> Burstable -> Guaranteed 中逐个驱逐。

目前，所有三个探针都有对应的接口，路径是 QOS 中的命令。请根据 QOS 配置修改端口信息（默认端口为 22222）。其他参数请参考 Kubernetes 官方文档。