linux网络健康度检测,linux运维、架构之路-K8s健康检查Health Check
一、Health Check介绍强大的自愈能力是k8s容器编排引擎一个重要特性,自愈能力的默认实现方式为自动重启发生故障的容器,另外还可以利用Liveness和Readiness探测机制设置更精细的健康检查。零停机部署避免部署无效的镜像更加安全的滚动升级二、K8S健康检查方式1、k8s默认的健康检查每个容器启动时都会执行一个进程,此进程由Dockerfile的CMD或ENTRYPOINT指定。如果
一、Health Check介绍
强大的自愈能力是k8s容器编排引擎一个重要特性,自愈能力的默认实现方式为自动重启发生故障的容器,另外还可以利用Liveness和Readiness探测机制设置更精细的健康检查。
零停机部署
避免部署无效的镜像
更加安全的滚动升级
二、K8S健康检查方式
1、k8s默认的健康检查
每个容器启动时都会执行一个进程,此进程由Dockerfile的CMD或ENTRYPOINT指定。如果进程退出返回码为0,则认为容器发生故障,k8s会根据restartPolicy重启容器。
①创建应用测试
apiVersion: v1
kind: Pod
metadata:
name: healthcheck
labels:
test: healthcheck
spec:
restartPolicy: OnFailure
containers:-name: healthcheck
image: busybox
args:- /bin/sh- -c- sleep 10;exit 1
②Pod的restartPolicy设置为OnFailure,默认策略为Always,执行创建Pod
kubectl apply -f healthcheck.yaml
③过几分钟查看Pod状态,发现容器已经重启了3次
[root@k8s-node1 health_check]# kubectl getpods healthcheck
NAME READY STATUS RESTARTS AGE
healthcheck0/1 Error 3 2m
容器进程返回值非0,k8s则认为容器发生故障,需要重启,有不少场景下发生故障,但进程不会退出,比如访问web服务时发生500内部错误,可能是负载过高,也可能是资源死锁,此时httpd进程并没有异常
退出,在这种情况下重启容器可能是最直接、最有效的解决方案,处理此类场景那就用到了k8s的Liveness探测。
2、Liveness探测
Liveness探测让用户可以自定义判断容器是否健康的条件,如果探测失败,k8s就会重启容器。
①创建应用演示
apiVersion: v1
kind: Pod
metadata:
name: liveness
labels:
test: liveness
spec:
restartPolicy: OnFailure
containers:-name: liveness
image: busybox
args:- /bin/sh- -c- touch /tmp/healthy; sleep 30; rm -f /tmp/healthy; sleep 600livenessProbe:
exec:
command:-cat- /tmp/healthy
initialDelaySeconds:10periodSeconds:5
以上yaml文件说明:启动Pod后首先创建文件/tmp/healthy,30秒后删除,如果文件/tmp/healthy存在,则认为容器处于正常状态,反之发生故障。
探测方法:
通过cat命令检查/tmp/healthy文件是否存在,如果命令执行成功,返回值为0,k8s会认为本次Liveness探测成功;如果命令返回值非0,本次Liveness探测失败
initialDelaySeconds: 10 指容器启动10秒后开始执行Liveness探测,如果你的应用启动要花30秒,那么initialDelaySeconds的值就应该大于30。
periodSeconds: 5 指每5秒执行一次Liveness探测,k8s如果连续执行3次Liveness探测均失败,则会杀掉重启容器
②创建Pod并查看
kubectl apply -f liveness.yaml
kubectl describe pod liveness
③35秒之后,日志显示/tmp/healthy已经不存在了,Liveness连续几次探测失败,容器会被重启
④再次查看pod,发现已经重启1次
[root@k8s-node1 health_check]# kubectl getpods liveness
NAME READY STATUS RESTARTS AGE
liveness1/1 Running 1 1m
3、Readiness探测
Liveness探测可以告诉k8s什么时候通过重启容器实现自愈;Readiness探测告诉k8s什么时候可以将容器加入到service负载均衡池中,对外提供服务。
①Readiness探测配置与Liveness探测完全一样
apiVersion: v1
kind: Pod
metadata:
name: readiness
labels:
test: readiness
spec:
restartPolicy: OnFailure
containers:-name: readiness
image: busybox
args:- /bin/sh- -c- touch /tmp/healthy; sleep 30; rm -f /tmp/healthy; sleep 600
readinessProbe:
exec:
command:-cat- /tmp/healthy
initialDelaySeconds:10periodSeconds:5
②创建并查看
kubectl apply -f readiness.yaml
[root@k8s-node1 health_check]# kubectl getpod readiness
NAME READY STATUS RESTARTS AGE
readiness0/1 Running 08s
[root@k8s-node1 health_check]# kubectl getpod readiness
NAME READY STATUS RESTARTS AGE
readiness1/1 Running 018s
[root@k8s-node1 health_check]# kubectl getpod readiness
NAME READY STATUS RESTARTS AGE
readiness0/1 Running 0 49s
探测方法:
刚创建时,READY状态不可用
15秒后,第一次进行Readiness探测并成功返回,设置READY为可用
30秒后,/tmp/healthy被删除,连续3次Readiness探测失败后,READY被设置为不可用
③查看日志详情
kubectl describe pod readiness
4、Readiness探测与Liveness探测区别
Readiness探测与Liveness探测是两种Health Check机制,如果不特意配置,k8s对两种探测采取相同的默认行为,均通过判断容器启动进程的返回值是否为0判断探测是否成功。
两种探测配置方法完全一样,支持的配置参数也一样,不同在于探测失败后,Liveness探测是重启容器,Readiness探测则将容器设置为不可用,不接收service转发的请求
Readiness探测与Liveness探测是独立执行的,二者之间没有依赖,可以单独使用,也可以同时使用,用Liveness探测判断容器是否需要重启以实现自愈,用Readiness探测判断容器是否已经准备好对外提供服务
更多推荐
所有评论(0)