OpenShift添加应用健康检查功能
什么是健康检查？
对于部署成功的应用来说，通过访问接口、执行特定命令等方式判断应用是否存活、正常的方式称为健康检查。
在 OpenShift 或 Kubernetes 中，健康检查都有两个探针，分别是 就绪探针(Readiness Probe) 与 存活探针(Liveness Probe)：
- 就绪探针(Readiness Probe)，即指收集应用已经准备好接收流量状态的探针。通过就绪状态判断Pod是否可以纳入到Service的负载均衡列表中。当Pod处于未就绪状态时，会被自动移出Service负载均衡列表。
- 存活探针(Liveness Probe)，即指收集应用存活状态，确保应用在某种特定状态时重启Pod的探针。通过捕获特定状态，重启Pod以提高可用性。
以上两种探针可独立使用，亦可配合使用。
本文以OpenShift 3.9版本举例，新版本类似，Kubernetes 1.16以后新增的Startup Probe复用了Liveness Probe功能类似，其先于Liveness Probe执行，以防止慢启动服务误杀，此处不做细说（因为OpenShift低版本里还没有）
使用健康检测场景举例
以下示例均为未设置健康检测探针时的场景
- 场景一：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类型的自由度更高些。
注：经过实践及线上出现的问题，发现容器命令方式如果是curl访问的内部服务，可能会出现探针报错，而不是不健康状态。此时Service处匹配的Pod列表不会下线并更新！
这个问题源于k8s对这个情况的判断，所以这里推荐使用HTTP GET 与 TCP Socket 类型探针，如果端口号不同时，可在添加探针后同步修改Deployment yaml探针定义即可。
参考文档
https://docs.openshift.com/container-platform/3.9/dev_guide/application_health.html
https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#container-probes
