一、健康检查方式
在OpenShift的Deployment Config中，用户可以定义两种健康检查方式：
- Readiness Probe：检查应用是否已经就绪（原因是当应用刚刚开始启动的时候，应用需要进行其所依赖资源的准备工作，列如 加载class、获得数据库连接 等等），OpenShift通过检查Readiness Probe接口，只有在确认服务就绪后，才会将外界的流量转发至服务。如果检测失败之后，RC不会进行容器的恢复，并且不会转发流量到此容器上，这是和Liveness Probe最大的区别点。
当为正在运行的容器添加Readiness Probe时，如果新容器在启动时，健康检查失败的次数超过了配置的次数（通过 failureThreshold 设置，默认为3次）时，则将新容器标记为启动失败。当容器启动失败10分钟（通过 timeoutSeconds 设置，默认为10分钟）之后，OpenShift将会把这个新容器删除了，并且将配置回退到添加Readines Probe之后的旧配置，并使用旧配置再重新启动一个容器。回退的触发还可以通过 oc rollback app-cli 来完成。
- Liveness Probe：检查容器是否在正常运行，如果一个服务的Liveness Probe探测结果返回失败，OpenShift就会判定这个容器出现了问题，相应的容器会被停止。并由RC进行容器数量恢复。通过 kubelet 服务完成检查过程。
二、健康检查类型
OpenShift默认支持三种类型的健康检查接口：HTTP GET请求、执行容器命令 以及 TCP Socker。
- HTTP GET请求
HTTP GET请求类型的检查通过调用用户指定的URL差别容器应用的状态。如果返回值为200或399，则表示成功，否则认为失败。
- 执行容器命令
用户可以通过执行容器中的某个命令来确认容器的状态。如果程序的返回值为0则表示成功，否则认定为失败。
- TCP Socket
TCP Socket 检查访问容器的某一个TCP端口，如果成功建立连接，则认为检查成功，否则认为是失败。
三、例子：
方式一，命令方式：
|
oc set probe dc/app-cli \
--rediness \
--initial-delay-seconds=5
|
方式二，图形界面y方式：
1、进入Deployment 的某个应用管理界面，如下图：
在这个界面上，就已经显示出现添加健康检查功能了。
2、选择健康检查方式，这里选择Liveness，如下图：
3、配置Liveness信息，如下图：
4、保存之后，回到Overview界面上看到，OpenShift新重启动了一个容器来应用刚刚的修改，此时，所有的流量还是转发到旧的容器；当新的容器准备就绪之后，旧的容器自动下线，所有的流量转发到新的容器上。
容器详细面上的说明：
