ASP.NET Core on K8S深入学习(6)Health Check
本篇已加入《.NET Core on K8S学习实践系列文章索引》,可以点击查看更多容器化技术相关系列文章。
一、关于K8S中的Health Check
所谓Health Check,就是健康检查,即防微杜渐。K8S是一个编排引擎可以帮助我们快捷地部署容器集群,如果部署上错误的容器导致服务崩溃,通常情况下我们都会通过一些高可用机制进行故障转移。但是,前提条件是有健康检查。
K8S自然帮我们考虑到了这个问题,健康检查是K8S的重要特性之一,默认有健康检查机制,此外还可以主动设置一些自定义的健康检查。
默认情况下,每个容器启动时都会执行一个进程,由Dockerfile中的CMD或ENTRYPOINT指定。如果进程退出时的返回码不为0,则认为容器发生了故障,K8S会根据重启策略(restartPolicy)重启容器。
例如下面这个例子,它模拟了容器发生故障的场景,注意下面配置文件中的args选项的定义:
apiVersion: v1 kind: Pod metadata: name: edc-healthcheck-demo labels: test: healthcheck spec: restartPolicy: OnFailure containers: - name: healthcheck image: busybox imagePullPolicy: IfNotPresent args: - /bin/sh - -c - sleep 10; exit 1
其中 sleep 10; exit 1代表启动10秒之后就非正常退出(返回码不为0),然后通过kubectl创建Pod:
kubectl apply -f health-check.yaml
过一段时间后查看Pod的状态,如下图所示:
可以看到,该容器已经重启了2次。也可以看出,restartPolicy简单直接暴力有效,不由感叹重启大法好!
但是,也要正视一个问题:必须等到进程退出后的返回值是非零才会触发重启策略,不能直接监测容器是否是健康。
那么,K8S中有没有更好的机制能够实现智能一点的健康检查呢?答案就是使用Liveness与Readinesss。
二、Liveness探测
2.1 Liveness初体验
一句话Liveness:如果检测有问题(如果健康检查失败),重启pod!至于怎么检测,你说了算(自定义判断容器是否健康的条件)!
Liveness提供了一些重要的参数:
initialDelaySeconds:容器启动后第一次执行探测是需要等待多少秒,看运行的服务而定。 periodSeconds:执行探测的频率,默认是10秒,最小1秒。 timeoutSeconds:探测超时时间,默认1秒,最小1秒。 successThreshold:探测失败后,最少连续探测成功多少次才被认定为成功,默认是1,对于liveness必须是1,最小值是1。 failureThreshold:探测成功后,最少连续探测失败多少次才被认定为失败。默认是3。最小值是1.
下面实践一个小例子创建一个Pod:
#command自己定义,例子为 /tmp/healthy 不存在则认为pod有问题,大家根据实际业务来自定义。 apiVersion: v1 kind: Pod metadata: labels: test: liveness name: liveness-demo spec: containers: - name: liveness image: busybox args: - /bin/sh - -c - touch /tmp/healthy; sleep 30; rm -rf/tmp/healthy; sleep 10 livenessProbe: exec: command: - cat - /tmp/healthy initialDelaySeconds: 10 periodSeconds: 5
这里启动pod后会创建文件夹 /tmp/healthy,30秒后删除,在我们的设置中,如果 /tmp/healthy 存在,则认为容器处于正常状态,否则认为发生故障。
需要注意的就是livenessProbe部分的定义了:
(1)探测方法:通过cat命令查看/tmp/healthy是否存在;如果返回值为0,则探测成功;否则,探测失败;
(2)initialDelaySeconds: 10 => 容器启动10秒之后开始执行liveness探测;
(3)periodSeconds: 5 => 每5秒执行一次liveness探测;如果连续执行3次探测都失败,那么就会杀掉并重启容器;
下面快速地验证一下:
(1)kubectl创建demo
kubectl apply -f liveness-demo.yaml
(2)查看pod日志
kubectl describe pod liveness-demo
结果如下图所示:
30秒之后,/tmp/healthy 被删除了,liveness探测失败,又过了几十秒,重复探测均失败后,开启了重启容器。
2.2 Liveness探针
上面的例子使用的是Liveness的exec探针,此外K8S还有几种其他类型的探针:
- exec:在容器中执行一个命令,如果命令退出码返回0则表示探测成功,否则表示失败
- tcpSocket:对指定的容IP及端口执行一个TCP检查,如果端口是开放的则表示探测成功,否则表示失败
- httpGet:对指定的容器IP、端口及路径执行一个HTTP Get请求,如果返回的状态码在 [200,400)之间则表示探测成功,否则表示失败
针对tcpSocket的例子:这里会检测80端口是否可以正常访问;
#检测80端口是否联通 apiVersion: v1 kind: Pod metadata: labels: test: readiness name: readiness-tcp spec: containers: - name: readiness image: nginx readinessProbe: failureThreshold: 3 tcpSocket: port: 80 initialDelaySeconds: 10 periodSeconds: 10 successThreshold: 1 timeoutSeconds: 10
针对httpGet的例子:这里会检测index.html文件是否可以正常访问;
#访问80端口的index.html文件是否存在 apiVersion: v1 kind: Pod metadata: labels: test: readiness name: readiness-httpget spec: containers: - name: readiness image: nginx readinessProbe: failureThreshold: 3 httpGet: path: /index.html port: 80 scheme: HTTP initialDelaySeconds: 10 periodSeconds: 10 successThreshold: 1 timeoutSeconds: 10
三、Readiness探测
3.1 Readiness初体验
一句话Readiness:如果检查失败,K8S会将该Pod从服务代理的分发后端去除,不再让其接客(分发请求给该Pod)。如果检测成功,那么K8S就会将容器加入到分发后端,重新对外接客(对外提供服务)。
下面继续以上面Liveness的例子来实践一下:
apiVersion: v1 kind: Pod metadata: labels: test: readiness name: readiness-demo spec: containers: - name: readiness image: busybox args: - /bin/sh - -c - touch /tmp/healthy; sleep 30; rm -rf/tmp/healthy; sleep 10 readinessProbe: exec: command: - cat - /tmp/healthy initialDelaySeconds: 10 periodSeconds: 5
readinessProbe的配置语法与livenessProbe完全一致,但执行后的效果却不一样,见下图所示:
可以看出:
(1)刚被创建时,其READY状态为不可用;
(2)15秒(initialDelaySeconds + periodSeconds = 10 + 5 = 15)之后,第一次进行Readiness探测成功,其READY状态变为可用。
(3)30秒之后,/tmp/healthy被删除,连续3次Readiness探测均失败后,其READY状态又变为了不可用。
此外,我们也可以通过 kubectl describe pod readiness-demo 查看到更想起的日志信息。
3.2 与Liveness的对比
Liveness与Readiness都是K8S的Health Check机制,Liveness探测是重启容器,而Readiness探测则是将容器设置为不可用,不让其再接受Service转发的请求。
Liveness与Readiness是独立执行的,二者无依赖,可以单独使用也可以同时使用。
四、Health Check在K8S中的应用
4.1 在Scale Up中的应用
对于多副本应用,当执行Scale Up操作时,新的副本会作为后端服务加入到Service的负载均衡列表中。但是,很多时候应用的启动都需要一定的时间做准备(比如加载缓存、连接数据库等等),这时我们可以通过Readiness探测判断容器是否真正就绪,从而避免将请求发送到还未真正就绪的后端服务。
下面一个示例YAML配置文件定义了Readiness探测,重点关注readinessProbe部分:
apiVersion: apps/v1 kind: Deployment metadata: name: edc-webapi-deployment namespace: aspnetcore spec: replicas: 2 selector: matchLabels: name: edc-webapi template: metadata: labels: name: edc-webapi spec: containers: - name: edc-webapi-container image: edisonsaonian/k8s-demo:1.2 ports: - containerPort: 80 imagePullPolicy: IfNotPresent readinessProbe: httpGet: scheme: HTTP path: /api/health port: 80 initialDelaySeconds: 10 periodSeconds: 5 --- apiVersion: v1 kind: Service metadata: name: edc-webapi-service namespace: aspnetcore spec: type: NodePort ports: - nodePort: 31000 port: 8080 targetPort: 80 selector: name: edc-webapi
对于readinessProbe部分:
(1)schema指定了协议,这里是HTTP协议,也可以是HTTPS协议;
(2)path指定访问路径,这里是我们自定义的一个Controller中的接口:简单地返回一个状态码为200的响应;
[Produces("application/json")] [Route("api/Health")] public class HealthController : Controller { [HttpGet] public IActionResult Get() => Ok("ok"); }
(3)port指定端口,这里是容器的端口80;
(4)initialDelaySeconds和periodSeconds指定了容器启动10秒之后开始探测,然后每隔5秒执行探测,如果发生3次以上探测失败,则该容器会从Service的负载均衡中移除,直到下次探测成功后才会重新加入。
4.2 在Rolling Update中的应用
假设现在有一个正常运行的多副本应用,我们要对其进行滚动更新即Rolling Update,K8S会逐步用新Pod替换旧Pod,结果就有可能发生这样的一个场景:当所有旧副本被替换之后,而新的Pod由于人为配置错误一直无法启动,因此整个应用将无法处理请求,无法对外提供服务,后果很严重!
因此,Readiness探测还提供了用于避免滚动更新中出现这种情况的一些解决办法,比如maxSurge和maxUnavailable两个参数,用来控制副本替换的数量。
继续以上面的YAML配置文件为例,重点关注strategy部分:
apiVersion: apps/v1 kind: Deployment metadata: name: edc-webapi-deployment namespace: aspnetcore spec: strategy: rollingupdate: maxSurge: 25% maxUnavailable: 25% replicas: 10 selector: matchLabels: name: edc-webapi template: metadata: labels: name: edc-webapi spec: containers: - name: edc-webapi-container image: edisonsaonian/k8s-demo:1.2 ports: - containerPort: 80 imagePullPolicy: IfNotPresent readinessProbe: httpGet: scheme: HTTP path: /api/health port: 80 initialDelaySeconds: 10 periodSeconds: 5 --- apiVersion: v1 kind: Service metadata: name: edc-webapi-service namespace: aspnetcore spec: type: NodePort ports: - nodePort: 31000 port: 8080 targetPort: 80 selector: name: edc-webapi
(1)maxSurge : 25% => 控制滚动更新过程中副本总数超过预期(这里预期是10个副本 replicas: 10)的上限,可以是数值也可以是百分比,然后向上取整。这里写的百分比,默认值是25%;
如果预期副本数为10,那么副本总数的最大值为RoundUp(10 + 10 * 25%)=13个。
(2)maxUnavailable : 25% => 控制滚动更新过程中不可用的副本(这里预期是10个副本 replicas: 10)占预期的最大比例,可以是数值也可以是百分比,然后向下取整,同样地默认值也是25%;
如果预期副本总数为10,那么可用的副本数至少要为10-roundDown(10 * 25%)=10-2=8个。
综上看来,maxSurge的值越大,初始创建的新副本数量就越多;maxUnavaliable值越大,初始销毁的旧副本数量就越多;
五、小结
本文探索了K8S中的默认健康检查机制以及Liveness和Readiness两种各有特点的探测机制,并通过一些小例子进行了说明。不过由于笔者也是初学,对于这一块没有过多实践经验,因此也是讲的比较粗浅,也希望以后能够有更多的实际经验分享与各位。
参考资料
(1)CloudMan,《每天5分钟玩转Kubernetes》
(2)李振良,《一天入门Kubernets教程》
(3)马哥(马永亮),《Kubernetes快速入门》
(4)华仔,《[[译]Kubernetes最佳实践:使用Readiness和Liveness探测做Health Check](https://blog.csdn.net/cainiaofly/article/details/84324321)》
(5)benjanmin杨,《K8S中的Health Check》
(6)条子在洗澡,《K8S健康性检查-探测》
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
运维编排系列场景-----将实例的固定公网IP转换为其它新EIP
场景介绍 如果您在购买服务器时选择的固定带宽,并且已经购买了新的EIP,需要实例的公网IP转换为已购买的EIP。通常情况需要您先将固定带宽转换为按量带宽,然后把固定公网IP转换为EIP并解绑,最后绑定已购买的EIP。运维编排提供的公共模板实现了一键转换。不需要准备新的EIP,一键自动解绑公共IP并绑定其它新EIP。 解决方案 我们准备一台ECS实例。查看实例详情,如下图所示已分配公网IP。登录OOS控制台。如果您之前从未开通过OOS服务,请点击“立即开通”按钮,即可一键开通。OOS运维编排是安全免费的服务,请放心开通。开通后在公共模板中搜索'ACS-ECS-ConvertsPublicIPToNewEIPByInstanceId'。点击“创建执行”的按钮,选择“客户了解风险,无需确认”的按钮,点击“下一步:设置参数”。在参数设置页,需要输入实例ID:接下来,进入OOS控制台的执行管理页,查看执行,可以看到图形化的执行过程。在执行详情中执行状态显示成功。实例详情页面查看修改结果,如下图所示,实例公网IP已转换为EIP。 欢迎使用OOS OOS客户支持钉钉群:23330931OOS管理控制...
- 下一篇
云服务器相比传统IDC有哪些优势?这里讲得很清楚了
传统IDC是指互联网数据中心(Internet Data Center,简称IDC),IDC是一种拥有完善的设备(包括高速互联网接入带宽、高性能局域网络、安全可靠的机房环境等)、专业化的管理、完善的应用的服务平台。在这个平台基础上,IDC服务商为客户提供互联网基础平台服务(服务器托管、虚拟主机、邮件缓存、虚拟邮件等)以及各种增值服务(场地的租用服务、域名系统服务、负载均衡系统、数据库系统、数据备份服务等)。在云服务器出现以前,企业建站或者个人站长,都是租用传统IDC服务器空间来放置网站或应用。 云服务器(Elastic Compute Service,简称ECS),云服务器是一种性能卓越、稳定可靠、弹性扩展的IaaS(Infrastructure as a Service)级别云计算服务。云服务器ECS免去了您采购IT硬件的前期准备,让您像使用水、电、天然气等公共资源一样便捷、高效地使用服务器,实现计算资源的即开即用和弹性伸缩。那么云服务器跟传统IDC对比,到底具有哪些优势呢? 为什么选择云服务器ECS 选择云服务器ECS,您可以轻松构建具有以下优势的计算资源: 无需自建机房,无需采购...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- CentOS8编译安装MySQL8.0.19
- CentOS8,CentOS7,CentOS6编译安装Redis5.0.7
- SpringBoot2整合MyBatis,连接MySql数据库做增删改查操作
- SpringBoot2整合Redis,开启缓存,提高访问速度
- SpringBoot2配置默认Tomcat设置,开启更多高级功能
- Hadoop3单机部署,实现最简伪集群
- CentOS7,CentOS8安装Elasticsearch6.8.6
- CentOS6,7,8上安装Nginx,支持https2.0的开启
- Docker使用Oracle官方镜像安装(12C,18C,19C)
- SpringBoot2编写第一个Controller,响应你的http请求并返回结果