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

OpenShift添加应用健康检查功能

OpenShift添加应用健康检查功能

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

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

OpenShift添加应用健康检查功能

使用 HTTP GET请求 类型

OpenShift添加应用健康检查功能

使用 TCP Socket 类型

OpenShift添加应用健康检查功能

添加健康检查后

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

OpenShift添加应用健康检查功能

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

OpenShift添加应用健康检查功能

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

注意事项

使用Web界面添加健康检测探针时,TCP SocketHTTP 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

发表评论

相关文章