linux端口健康检查,linux运维、架构之路-K8s健康检查Health Check

一、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探测判断容器是否已经准备好对外提供服务