玩转k8s（六）—— Health Check健康检查
用户可以利用Liveness和Readiness探测机制设置更精细的健康检查，进而实现如下需求：
（1）零停机部署
（2）避免部署无效的镜像
（3）更加安全的滚动升级
1. 默认的健康检查
k8s默认健康检查机制：每个容器启动时都会执行一个进程，此进程由Dockerfile的CMD或ENTRYPOINT指定。如果进程退出时返回码非0，则认为容器发生故障，k8s就会根据restartPolicy重启容器。
（1）模拟一个容器发生故障的场景，pod的配置文件如下：
Pod 的restartPolicy设置为OnFailure，默认为Always
sleep 10; exit 1模拟容器启动10秒后发生故障
apiVersion: v1
kind: Pod
metadata:labels:test: healthcheckname: healthcheck
spec:restartPolicy: OnFailurecontainers:- name: healthcheckimage: busyboxargs:- /bin/sh- -c- -sleep 10; exit 1
（2）apply
zy@k8s-master:~$ kubectl apply -f healthcheck.yml
pod/healthcheck created
（3）查看pod状态
可以看到容器当前已经重启了3此
zy@k8s-master:~$ kubectl get pod healthcheck
NAME READY STATUS RESTARTS AGE
healthcheck 0/1 CrashLoopBackOff 3 2m5s
可以看到容器返回值非0，k8s认为容器发生故障，需要重启。
2. Liveness 探测
Liveness探测让用户可以自定义判断容器是否健康的条件。如果探测失败，k8s就会重启容器。
举例：
（1）创建Pod
启动进程首先创建 /tmp/healthy，30秒后删除，在我们的设定中，如果 /tmp/healthy文件存在，则认为容器处于正常状态，反之则发生故障。
apiVersion: v1
kind: Pod
metadata:labels:test: livenessname: liveness
spec:restartPolicy: OnFailurecontainers:- name: livenessimage: busyboxargs:- /bin/sh- -c- touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleeplivenessProbe:exec:command:- cat- /tmp/healthyinitialDelaySeconds: 10periodSeconds: 5
（2）livenessProbe 部分定义如何执行Liveness探测：
通过cat命令检查 /tmp/healthy 文件是否存在。如果命令执行成功，返回值为0，k8s则认为本次Liveness探测成功；如果返回值不是0，本次探测失败。
initialDelaySeconds：10秒之后开始执行Liveness探测
periodSeconds：指定每5秒执行一次Liveness探测。k8s如果连续执行3此Liveness探测均失败，则会杀掉并重启容器。
（3）创建Pod liveness
zy@k8s-master:~$ kubectl apply -f liveness.yml
pod/liveness created
（3）查看pod的信息
zy@k8s-master:~$ kubectl describe pod liveness
Events:Type Reason Age From Message---- ------ ---- ---- -------Normal Scheduled 63s default-scheduler Successfully assigned default/liveness to k8s-node2Normal Pulled 44s kubelet Successfully pulled image "busybox" in 16.156062429sNormal Created 44s kubelet Created container livenessNormal Started 43s kubelet Started container livenessNormal Pulling 13s (x2 over 60s) kubelet Pulling image "busybox"
过一会儿再查看：
Events:Type Reason Age From Message---- ------ ---- ---- -------Normal Scheduled 116s default-scheduler Successfully assigned default/liveness to k8s-node2Normal Pulled 98s kubelet Successfully pulled image "busybox" in 16.156062429sNormal Created 51s (x2 over 98s) kubelet Created container livenessNormal Pulled 51s kubelet Successfully pulled image "busybox" in 15.906275273sNormal Started 50s (x2 over 97s) kubelet Started container livenessWarning BackOff 16s (x2 over 20s) kubelet Back-off restarting failed containerNormal Pulling 5s (x3 over 114s) kubelet Pulling image "busybox"
查看pod:
zy@k8s-master:~$ kubectl get pod liveness
NAME READY STATUS RESTARTS AGE
liveness 1/1 Running 3 3m27s
3. Readiness 探测
除了Liveness探测，k8s Health Check机制还包括Readiness探测：
用户通过Liveness探测可以告诉k8s什么时候通过重启容器实现自愈；Readiness探测则是告诉k8s什么时候可以将容器加入Service负载均衡池中，对外提供服务。
（1）把前面那个配置文件中的liveness替换为readiness
apiVersion: v1
kind: Pod
metadata:labels:test: livenessname: liveness
spec:restartPolicy: OnFailurecontainers:- name: livenessimage: busyboxargs:- /bin/sh- -c- touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleepreadinessProbe:exec:command:- cat- /tmp/healthyinitialDelaySeconds: 10periodSeconds: 5
（2）apply一下
zy@k8s-master:~$ kubectl apply -f liveness.yml
pod/liveness created
zy@k8s-master:~$ kubectl get pod liveness
NAME READY STATUS RESTARTS AGE
liveness 1/1 Running 0 24s
zy@k8s-master:~$ kubectl get pod liveness
NAME READY STATUS RESTARTS AGE
liveness 0/1 Running 1 59s
3. Liveness探测和Readiness探测比较
（1）Liveness探测和Readiness探测是两种Health Check机制，如果不特意配置，k8s将对两种探测采取相同的默认行为，即通过判断容器启动进程的返回值是否为0，来判断探测是否成功。
（2）两种探测的配置方法完全一样，支持的配置参数也一样，不同之处在于探测失败后的行为：
Liveness探测是重启容器；Readiness探测则是将容器设置为不可用，不接受service转发的请求。
（3）Liveness探测和Readiness探测是独立执行的，二者之间没有依赖，所以可以单独使用，也可以同时使用：用Liveness探测判断容器是否需要重启以实现自愈，用Readiness探测判断容器是否已经准备好对外提供服务。
4. Health Check 在 Scale Up 中的应用
对于多副本应用，当执行 Scale Up操作时，新副本会作为backend被添加到Service的负载均衡中，与已有副本一起处理客户的请求。考虑到应用启动通常都需要一个时间段，比如加载缓存数据，连接数据库等，从容器启动到可以真正提供服务是需要一段时间的，我们可以同通过Readiness探测判断容器是否就绪，避免将请求发送到还没准备好的backend。
5. Health Check在滚动更新中的应用
考虑现有一个正常运行的多副本应用，接下来对应用进行更新（比如使用更高版本的image），k8s会启动新副本，然后发生了如下事件：
（1）正常情况下新副本需要10秒钟完成准备工作，在此之前无法响应业务请求。
（2）由于人为配置错误，副本始终无法完成准备工作（比如无法连接后端数据库）
因为新副本本身没有异常退出（一直没准备好），默认的Heath Check机制会认为容器已经就绪，进而会逐步用新副本替换现有副本，其结果就是：当所有的旧副本被替换后，整个应用将无法处理请求，无法对外提供服务。
如果正确配置了Health Check ，新副本只有通过了Readiness探测才会被添加到Service，如果没有通过探测，现有副本不会被全部替换，业务仍然正常进行。
（1）使用如下配置文件app.v1.yml模拟一个10副本的应用
apiVersion: apps/v1
kind: Deployment
metadata:name: app
spec:replicas: 10selector: # 新增 selector 字段matchLabels:app: apptemplate:metadata:labels:app: appspec:containers:- name: appimage: busyboxargs:- /bin/sh- -c- sleep 10; touch /tmp/healthy; sleep 30000readinessProbe:exec:command:- cat- /tmp/healthyinitialDelaySeconds: 10periodSeconds: 5
（2）apply
zy@k8s-master:~$ kubectl apply -f app.v1.yml --record
deployment.apps/app createdzy@k8s-master:~$ kubectl get pod
NAME READY STATUS RESTARTS AGE
app-64d4c9fcc-4l4fx 1/1 Running 0 105s
app-64d4c9fcc-6mv77 1/1 Running 0 105s
app-64d4c9fcc-6x64n 1/1 Running 0 105s
app-64d4c9fcc-7pxm8 1/1 Running 0 105s
app-64d4c9fcc-jtztp 1/1 Running 0 105s
app-64d4c9fcc-kztsf 1/1 Running 0 105s
app-64d4c9fcc-lk7pp 1/1 Running 0 105s
app-64d4c9fcc-pm758 1/1 Running 0 105s
app-64d4c9fcc-t29tr 1/1 Running 0 105s
app-64d4c9fcc-tqwrd 1/1 Running 0 105s（3）滚动更新应用，配置文件 app.v2.yml
apiVersion: apps/v1
kind: Deployment
metadata:name: app
spec:replicas: 10selector: # 新增 selector 字段matchLabels:app: apptemplate:metadata:labels:app: appspec:containers:- name: appimage: busyboxargs:- /bin/sh- -c- sleep sleep 3000readinessProbe:exec:command:- cat- /tmp/healthyinitialDelaySeconds: 10periodSeconds: 5（4）重新apply
新的副本中不存在 /tmp/healthy，所以不能通过探测
zy@k8s-master:~$ kubectl apply -f app.v2.yml --record
deployment.apps/app configured
zy@k8s-master:~$ kubectl get deployments.apps app
NAME READY UP-TO-DATE AVAILABLE AGE
app 8/10 5 8 4m59szy@k8s-master:~$ kubectl get pod
NAME READY STATUS RESTARTS AGE
app-64d4c9fcc-4l4fx 1/1 Running 0 6m17s
app-64d4c9fcc-6mv77 1/1 Running 0 6m17s
app-64d4c9fcc-6x64n 1/1 Running 0 6m17s
app-64d4c9fcc-7pxm8 1/1 Running 0 6m17s
app-64d4c9fcc-jtztp 1/1 Running 0 6m17s
app-64d4c9fcc-kztsf 1/1 Running 0 6m17s
app-64d4c9fcc-pm758 1/1 Running 0 6m17s
app-64d4c9fcc-t29tr 1/1 Running 0 6m17s
app-7cfd6989df-2fh9t 0/1 CrashLoopBackOff 1 90s
app-7cfd6989df-4qr6g 0/1 CrashLoopBackOff 1 90s
app-7cfd6989df-h6j5d 0/1 Error 2 90s
app-7cfd6989df-vh4vt 0/1 Error 2 89s
app-7cfd6989df-zjt2q 0/1 Error 1 89s
从pod的age栏可以判断，最后五个是新副本，目前处于Not Ready的状态。旧副本从最初10个减少到8个。
在我们的设定中，新副本始终都无法通过Readiness探测，所以这个状态会一直保持下去，上面模拟了一个滚动更新失败的场景。幸运的是：Health Check帮我们屏蔽了有缺陷的副本，同时保留了大部分旧副本，业务没有因为更新失败而受到影响。
为什么创建了5个新副本？同时只销毁了2个旧副本？
原因是：滚动更新通过参数 maxSurge 和 maxUnavailable 来控制副本替换的数量。