aspnetcore.webapi实战k8s健康探测机制 - kubernetes

时间:2021-06-04 15:32:03

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 探测均失败,就会杀掉并重启容器。

aspnetcore.webapi实战k8s健康探测机制 - kubernetes

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

aspnetcore.webapi实战k8s健康探测机制 - kubernetes

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

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

k8s默认是根据命令进行探测的,由于我们需要与微服务结合,所以需要在yml文件中指定为http方式(备注:k8s提供了三种container probes方式:command、TCP check、HTTP Get,其他的方式希望大家下去自己实践),k8s对于http方式探测成功的判断条件是请求的返回代码在 200-400 之间。

health-checks-deployment.yml 如下:

apiVersion: apps/v1
kind: Deployment
metadata:
namespace: k8s-ecoysystem-apps
name: healthchecks-api
labels:
app: healthchecks-api
spec:
replicas:
selector:
matchLabels:
app: healthchecks-api
template:
metadata:
namespace: k8s-ecoysystem-apps
labels:
app: healthchecks-api
spec:
containers:
- name: healthchecks-api
imagePullPolicy: Always
image: justmine/healthchecksapi:v1.
ports:
- containerPort:
readinessProbe:
httpGet:
path: /api/v1/heathchecks/readiness
port:
scheme: HTTP
initialDelaySeconds:
periodSeconds:
livenessProbe:
httpGet:
path: /api/v1/heathchecks/liveness
port:
scheme: HTTP
initialDelaySeconds:
periodSeconds:

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

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

aspnetcore.webapi实战k8s健康探测机制 - kubernetes

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

aspnetcore.webapi实战k8s健康探测机制 - kubernetes

现在全部可用了

5、通过dashboard查看集群概况

aspnetcore.webapi实战k8s健康探测机制 - kubernetes

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

aspnetcore.webapi实战k8s健康探测机制 - kubernetes

aspnetcore.webapi实战k8s健康探测机制 - kubernetes

aspnetcore.webapi实战k8s健康探测机制 - kubernetes

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

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

aspnetcore.webapi实战k8s健康探测机制 - kubernetes

aspnetcore.webapi实战k8s健康探测机制 - kubernetes

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

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

aspnetcore.webapi实战k8s健康探测机制 - kubernetes

继续等待一段时间:

aspnetcore.webapi实战k8s健康探测机制 - kubernetes

现在,整个集群已经自愈完成了!!!

7、总结

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

如果你觉得本篇文章对您有帮助的话,感谢您的【推荐】。
如果你对 kubernets 感兴趣的话可以关注我,我会定期的在博客分享我的学习心得。

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

下一篇,我们将实践微服务中的环境变量和配置信息,如何与k8s进行结合