1、浅析k8s两种健康检查机制

---

• Liveness 

     k8s通过liveness来探测微服务的存活性，判断什么时候该重启容器实现自愈。比如访问 Web 服务器时显示 500 内部错误，可能是系统超载，也可能是资源死锁，此时 httpd 进程并没有异常退出，在这种情况下重启容器可能是最直接最有效的解决方案。

• Readiness 

      k8s通过readiness来探测微服务的什么时候准备就绪（例如初始化时，连接数据库，加载缓存数据等等，可能需要一段时间），然后将容器加入到server的负载均衡池中，对外提供服务。

    1.1、k8s默认的健康检查机制

      每个容器启动时都会执行一个进程，此进程由 Dockerfile 的 CMD 或 ENTRYPOINT 指定。如果进程退出时返回码非零，则认为容器发生故障，Kubernetes 就会根据 restartPolicy 重启容器。如果不特意配置，Kubernetes 将对两种探测采取相同的默认行为。

2、通过微服务自定义两种机制

---

存活10分钟：如果当前时间超过服务启动时间10分钟，则探测失败，否则探测成功。Kubernetes 如果连续执行 3 次 Liveness 探测均失败，就会杀掉并重启容器。

准备就绪30秒，30秒后，如果连续 3 次 Readiness 探测均失败后，容器将被重置为不可用，不接收 Service 转发的请求。

从上面可以看到，我们可以根据自身的需求来实现这两种机制，然后，提供给k8s进行探测。

3、编写k8s资源配置文件(yml)

---

k8s默认是根据命令进行探测的，由于我们需要与微服务结合，所以需要在yml文件中指定为http方式，k8s对于http方式探测成功的判断条件是请求的返回代码在 200-400 之间。

health-checks-deployment.yml 如下：

从上面可以看到，一共部署了3个pod副本，而每个pod副本里面部署一个容器，即为同一个微服务部署了3个实例进行集群。

4、在k8s集群的master机器上，创建部署对象

---

从上面可以看到，刚开始创建时，READY 状态为不可用，等待一段时间

现在全部可用了

5、通过dashboard查看集群概况

---

 

6、剖析k8s集群自愈(self-healing)过程

---

 

从上面可以看到，大约1分钟(dashboard统计信息有一定的延迟)左右，第一次进行 Readiness 探测并成功返回，此时准备就绪，可以对外提供服务了。在10分钟内，探测Liveness也成功返回。

继续等待一段时间，查询其中一个pod详细信息：

从上面可以看到，超过10分钟存活期后，liveness探测失败，容器被 killed and recreated。探测Readiness未成功返回时，整个容器处于不健康的状态，并不会被负载均衡请求。

此时通过dashboard查看集群概况：

 

继续等待一段时间：

现在，整个集群已经自愈完成了！！！

7、总结

---

Liveness 探测和 Readiness 探测是独立执行的，二者之间没有依赖，可以单独使用，也可以同时使用。用 Liveness 探测判断容器是否需要重启以实现自愈；用 Readiness 探测判断容器是否已经准备好对外提供服务。

 

源码参考：https://github.com/justmine66/k8s.ecoysystem.apps

相关文章：

• kubernetes实践之运行aspnetcore webapi微服务

• 请注意，容器技术圈已迈入后Kubernetes时代！

• 利用VSTS跟Kubernetes整合进行CI/CD

• Asp.net core应用在 Kubernetes上内存使用率过高问题分析

• Kubernetes应用部署模型解析（原理篇）

•  Kubernetes应用部署模型解析（部署篇）

原文：https://www.cnblogs.com/justmine/p/8620311.html

---

.NET社区新闻，深度好文，欢迎访问公众号文章汇总 http://www.csharpkit.com