关于k8s:k8s健康检查机制的实践和理解

一、背景
最近在公司实际DevOps(开发、运维一体化)的流程落地，并且将原先的Docker Swarm集群迁徙到K8s集群。碰到原先集群的健康检查与现有集群的健康检查存在不统一的中央，在这里做个总结。
二、原理及必要性
利用健康检查，顾名思义，是对利用现有状况（包含数据库、缓存、及Socket连贯）进行查看，以让集群调度管理器发现利用的存活状况，从而对利用进行管控（从新调度调配，可重启，调度到其余节点等）,特地针对稳定性要求高（业务不能中断），部署机制灵便（反对滚动公布，在部署过程中不中断利用，从而不影响业务应用）
三、实际
1、原先DockerSwarm集群健康检查机制是通过在Dockerfile中指定Docker的health check地址，如下：
健康检查
HEALTHCHECK --interval=120s --timeout=5s CMD curl --fail http://localhost:8080/api/pub... || exit 1
2、利用/api/public/health/check的逻辑（示例）：
（1）控制器

如果检测不通过，须要在httpServletResponse返回非200的错误码，以让集群判断http调用异样
（2）服务解决

2、当初新的K8s集群健康检查配置

(1）删除原先的Dockerfile中健康检查的调用代码，此形式在新的k8s集群不失效
(2) 如上图配置就绪状态查看策略
该策略可用于判断利用是否已启动，并且能失常受理业务，依据利用启动状况进行配置，以秒为单位

(3) 如上图配置存活状态查看策略
该策略配置可用于集群判断利用是否存活，并且能失常受理业务，依据利用理论状况进行配置，以秒为单位