玩转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 来控制副本替换的数量。
玩转k8s（六）—— Health Check健康检查相关推荐
- 17、Health Check 健康检查
强大的自愈能力是kubernetes容器编排引擎的重要特性. 自愈的默认实现方式是自动重启发生故障的容器.除此之外,还可通过 Liveness和Readiness探测机制设置更精细的健康检查,进而实现 ...
- k8s探针检测php,k8s探针实现grpc健康检查
这篇文章教大家如何利用k8s实现grpc健康检查 一. 配置Liveness和Readiness探针 kubelet 使用 liveness probe(存活探针)来确定何时重启容器.例如,当应用程序 ...
- K8s之Pod的健康检查
前言 Pod的探测用于检测容器中的应用实例是否可以正常的工作.如果不能正常工作应该去重启,或者不将流量引入该实例.K8s给我们提供了三种探测方式. LivenessProbe,ReadinessPro ...
- k8s 重启策略、健康检查、环境变量、初始化容器
深入理解Pod对象:基本管理 Pod基本概念 Pod存在意义 Pod资源共享实现机制 Pod管理命令 重启策略 健康检查 环境变量 init Container(初始化容器) 先简单的做出两个运行ht ...
- k8s探针检测php,K8S教程（7）使用探针对容器进行健康检查
应用在运行过程不可避免会出现各种问题导致服务不可用的情况发生,K8S的Health Check健康检查机制可以对这些异常服务进行重启.剔除等操作,保障高可用. 一.K8S的健康检查探针 K8S的探针主 ...
- ASP.NET Core on K8S深入学习（6）Health Check
本篇已加入<.NET Core on K8S学习实践系列文章索引>,可以点击查看更多容器化技术相关系列文章.预计阅读时间为10分钟. 01 - 关于K8S中的健康监测 所谓Health C ...
- k8s集群下的健康检查
k8s支持两种健康检查模式:readiness.liveness 简单的来说,readiness检查是否可以暴露该应用(availabel),liveness检查是否需要重启. 三种检查方式:http ...
- linux网络健康度检测,linux运维、架构之路-K8s健康检查Health Check
一.Health Check介绍 强大的自愈能力是k8s容器编排引擎一个重要特性,自愈能力的默认实现方式为自动重启发生故障的容器,另外还可以利用Liveness和Readiness探测机制设置更精细的 ...
- k8s的健康性检查-Health Check
1.k8s健康性检查的默认方式 k8s默认的健康检查机制:基于Dockerfile文件中的CMD或者ENTRYPOINT,如果进程退出时返回码为非零,则认为容器发生故障,k8s就会根据restartP ...
最新文章
- java不抛出方法异常,java – 重写方法不会抛出异常
- clickhouse物化视图优缺点_ClickHouse 适用场景
- .text 0.958之间居的中文汉化下载
- JDK 9.0.4 报错：程序包 com.sun.xml.internal.fastinfoset.stax.events 不存在/不可见
- mysql 优化 修复原理_mysql下表的修复与优化
- 服务器显示转速负数,Moldflow使用常见问题及解决方案
- docker 源码分析 三（基于1.8.2版本），NewDaemon启动
- linux查看有哪些用户连接到本机
- Java实现FastDFS文件上传、查询、下载和删除
- 怎么对linux系统的硬盘检测,详解Linux系统中hdparm硬盘检测工具的使用
- 计算机管理及维护培训考试题,计算机考试题库和答案_浅析高校公共计算机机房管理与维护...
- 钉钉 服务器 消息推送,钉钉消息推送配置
- 3大类6种排序 插入排序 选择排序 冒泡排序 希尔排序 堆排序 快速排序 —————— 开开开山怪
- 网络安全课程用C++实现简单的替代密码和置换密码
- axis2 jax-ws_Axis2 WS-Security基础知识
- LeetCode刷题之1436. 旅行终点站
- java编程水仙花数_Java 编程找出所有的水仙花数（水仙花数）。
- 计算机实验进程管理与虚拟机,虚拟机VMware进程控制实验.docx
- c位边上还有什么位_λ(c位旁边二个位置叫什么)
- 最全的身份证校验规则