OpenShift添加应用健康检查功能

什么是健康检查？

对于部署成功的应用来说，通过访问接口、执行特定命令等方式判断应用是否存活、正常的方式称为健康检查。

在 OpenShift 或 Kubernetes 中，健康检查都有两个探针，分别是 就绪探针(Readiness Probe) 与 存活探针(Liveness Probe)：

• 就绪探针(Readiness Probe)，即指收集应用已经准备好接收流量状态的探针。通过就绪状态判断Pod是否可以纳入到Service的负载均衡列表中。当Pod处于未就绪状态时，会被自动移出Service负载均衡列表。
• 存活探针(Liveness Probe)，即指收集应用存活状态，确保应用在某种特定状态时重启Pod的探针。通过捕获特定状态，重启Pod以提高可用性。

以上两种探针可独立使用，亦可配合使用。

本文以OpenShift 3.9版本举例，新版本类似，暂不考虑新版本Kubernetes的Startup Probe

使用健康检测场景举例

以下示例均为未设置健康检测探针时的场景

• 场景一：Pod内应用未就绪，Pod处于Running状态，Pod纳入到Service负载均衡列表中，当有流量进入时，返回服务不可用状态，如Connection Refuse。
• 场景二：Pod内应用在某次请求中，出现异常，暂时无法提供服务，处于未就绪状态，但其仍在负载均衡列表中，当流量负载到此节点时，应用返回超时、网关异常或Connection Refuse等，Service无法感知此Pod异常，无法故障转移。
• 场景三：Pod内应用出现死锁、假死状态，重启Pod可临时解决的场景。

针对场景一、二，使用就绪探针即可解决；针对场景三，使用存活探针即可解决。

为OpenShift上的应用添加健康检查

以下使用目前公司生产环境OpenShift 3.9环境举例，只是简单列出方法

进入Deployments进入待添加健康检查的应用，Actions-> Edit Health Checks

就绪探针与存活探针设置方式一致，都有三种探针实现类型，以就绪探针配置举例，存活探针可参考配置。

使用 容器内命令(Container Command) 类型

使用 HTTP GET请求 类型

使用 TCP Socket 类型

最终效果

添加完成后，在应用具体部署版本模板中会有健康检查探针的体现，只有健康检查通过的Pod才会提示Ready状态

OpenShift中对Kubernetes的健康检查进行了简单封闭，通过oc命令行工具查看pod，如图

period为健康检测间隔时间，OpenShift注掉了成功与失败数

注意事项

使用Web界面添加健康检测探针时，TCP Socket 与 HTTP GET 类型的探针只能使用模板的端口号，相对而言 Container Command类型的自由度更高些。

参考文档

https://docs.openshift.com/container-platform/3.9/dev_guide/application_health.html

https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#container-probes