1 浅析 k8s 两种健康检查机制
Liveness
k8s 通过 liveness 来探测微服务的存活性, 判断什么时候该重启容器实现自愈比如访问 web 服务器时显示 500 内部错误, 可能是系统超载, 也可能是资源死锁, 此时 httpd 进程并没有异常退出, 在这种情况下重启容器可能是最直接最有效的解决方案
Readiness
k8s 通过 reddiness 来探测微服务的什么时候准备就绪(例如初始化时, 连接数据库, 加载缓存数据等等, 可能需要一段时间), 然后将容器加入到 server 的负载均衡池中, 对外提供服务
1.1k8s 默认的健康检查机制
每个容器启动时都会执行一个进程, 此进程由 Dockerfile 的 CMD 或 ENTRYPOINT 指定如果进程退出时返回码非零, 则认为容器发生故障, Kubernetes 就会根据 restartPolicy 重启容器如果不特意配置, Kubernetes 将对两种探测采取相同的默认行为
2 通过微服务自定义两种机制
存活 10 分钟: 如果当前时间超过服务启动时间 10 分钟, 则探测失败, 否则探测成功 Kubernetes 如果连续执行 3 次 Liveness 探测均失败, 就会杀掉并重启容器
准备就绪 30 秒, 30 秒后, 如果连续 3 次 Readiness 探测均失败后,
容器将被重置为不可用, 不接收 Service 转发的请求
从上面可以看到, 我们可以根据自身的需求来实现这两种机制, 然后, 提供给 k8s 进行探测
4 编写 k8s 资源配置文件(yml)
k8s 默认是根据命令进行探测的, 由于我们需要与微服务结合, 所以需要在 yml 文件中指定为 http 方式, k8s 对于 http 方式探测成功的判断条件是请求的返回代码在 200-400 之间
health-checks-deployment.yml 如下:
从上面可以看到, 一共部署了 3 个 pod 副本, 而每个 pod 副本里面部署一个容器, 即为同一个微服务部署了 3 个实例进行集群
5 在 k8s 集群的 master 机器上, 创建部署对象
从上面可以看到, 刚开始创建时, READY 状态为不可用, 等待一段时间
现在全部可用了
6 通过 dashboard 查看集群概况
7 分析整个自愈流程
从上面可以看到, 大约 1 分钟 (dashboard 统计信息有一定的延迟) 左右, 第一次进行 Readiness 探测并成功返回, 此时准备就绪, 可以对外提供服务了在 10 分钟内, 探测 Liveness 也成功返回
继续等待一段时间, 查询其中一个 pod 详细信息:
从上面可以看到, 超过 10 分钟存活期后, liveness 探测失败, 容器被 killed and recreated 探测 Readiness 未成功返回时, 整个容器处于不健康的状态, 并不会被负载均衡请求
此时通过 dashboard 查看集群概况:
继续等待一段时间:
现在, 整个集群已经自愈完成了!!!
8 总结
Liveness 探测和 Readiness 探测是独立执行的, 二者之间没有依赖, 可以单独使用, 也可以同时使用用 Liveness 探测判断容器是否需要重启以实现自愈; 用 Readiness 探测判断容器是否已经准备好对外提供服务
源码参考: https://github.com/justmine66/k8s.ecoysystem.apps
来源: https://www.cnblogs.com/justmine/p/8620311.html