Application Healthchecks

背景：Readiness 和 Liveness 探针

正如我们之前在 UI 中通过警告看到的那样，OpenShift 中有一个应用程序健康检查的概念。这些有两种方式：

从文档的 Application Health 应用程序运行状况一节中, 我们可以看到定义：

Liveness Probe: 活性探针检查配置它的容器是否仍在运行。如果活性探测失败，kubelet 会杀死容器，容器将受到其重启策略的约束。通过配置template.spec.containers.livenessprobepod 配置的节来设置活性检查。
Readiness Probe: 就绪探针确定容器是否已准备好为请求提供服务。如果就绪探针使容器失败，端点控制器将确保容器的 IP 地址从所有服务的端点中删除。准备就绪探测器可用于向端点控制器发出信号，即使容器正在运行，它也不应该从代理接收任何流量。通过配置template.spec.containers.readinessprobepod 配置的节来设置就绪检查。

听起来很复杂，但是实际上操作比较简单。我们将使用 Web 控制台将这些探测器添加到我们的nationalparks应用程序中。

存活度健康检查

存活度探测（liveness probe）决定容器是否仍然在运行。如果存活度探测因为死锁等情况而失败，kubelet 会终止容器。pod 会根据其重启策略响应。

例如，在一个 restartPolicy 为 Always 或 OnFailure 的 pod 上的存活度探测会终止并重启容器。

就绪度探测（readiness probe）决定容器是否准备好接受服务请求。如果容器就绪度探测失败，kubelet 会从可用服务端点列表中移除 pod。

失败后，这个探测将继续检查 pod。如果 pod 可用，kubelet 会将 pod 添加到可用服务端点列表中。

启动探测（startup probe）指示容器内的应用程序是否启动。其它所有探测在启动成功前被禁用。如果启动探测无法在指定时间内成功，kubelet 会终止容器，容器受 pod restartPolicy 影响。

听起来很复杂，但是实际上操作比较简单。我们将使用 Web 控制台将这些探测器添加到我们的nationalparks应用程序中。

由于我们将要实现一个真实的 CI/CD 管道，我们将对应用程序的“开发”版本进行一些测试。但是，为了测试应用程序，它必须准备好。这就是 OpenShift 的应用程序运行状况功能非常有用的地方。

我们将向现有nationalparks部署添加就绪和活跃度探测。这将确保 OpenShift 在通过就绪检查之前不会向服务添加任何实例，并将确保不健康的实例重新启动（如果它们未通过活动检查）。

在拓扑视图中，单击nationalparks。在侧面板上，单击Actions下拉菜单并选择Add Health Checks。

单击以添加就绪探针Readiness Probe并在路径字段中添加：

/ws/healthz/

保留所有默认设置，如端口8080 和类型HTTP GET。点击右下角的灰色小勾进行确认：

对 Liveness Probe 重复相同的过程，单击Add Liveness Probe并在Path字段中添加：

/ws/healthz/

保留所有默认设置，如端口8080 和类型HTTP GET。单击右下角的灰色确认小勾进行确认。

最后确认所有新更改点击添加：

您会注意到这些更改导致了新的部署——它们被视为配置更改。