公司网站设计主页部分怎么做,无锡快速建设网站方法,成都私人定制旅游公司排名,企业门户网站开发平台的设计本篇已加入《.NET Core on K8S学习实践系列文章索引》#xff0c;可以点击查看更多容器化技术相关系列文章。预计阅读时间为10分钟。01—关于K8S中的健康监测所谓Health Check#xff0c;就是健康检查#xff0c;即防微杜渐。K8S是一个编排引擎可以帮助我们快捷地部署容器集… 本篇已加入《.NET Core on K8S学习实践系列文章索引》可以点击查看更多容器化技术相关系列文章。预计阅读时间为10分钟。01—关于K8S中的健康监测 所谓Health Check就是健康检查即防微杜渐。K8S是一个编排引擎可以帮助我们快捷地部署容器集群如果部署上错误的容器导致服务崩溃通常情况下我们都会通过一些高可用机制进行故障转移。但是前提条件是有健康检查。 K8S自然帮我们考虑到了这个问题健康检查是K8S的重要特性之一默认有健康检查机制此外还可以主动设置一些自定义的健康检查。 默认情况下每个容器启动时都会执行一个进程由Dockerfile中的CMD或ENTRYPOINT指定。如果进程退出时的返回码不为0则认为容器发生了故障K8S会根据重启策略restartPolicy重启容器。 例如下面这个例子它模拟了容器发生故障的场景注意下面配置文件中的args选项的定义apiVersion: v1kind: Podmetadata: name: edc-healthcheck-demo labels: test: healthcheckspec: restartPolicy: OnFailure containers: - name: healthcheck image: busybox imagePullPolicy: IfNotPresent args: - /bin/sh - -c - sleep 10; exit 1 其中 sleep 10; exit 1代表启动10秒之后就非正常退出返回码不为0然后通过kubectl创建Podkubectl apply -f health-check.yaml 过一段时间后查看Pod的状态如下图所示 可以看到该容器已经重启了2次。也可以看出restartPolicy简单直接暴力有效不由感叹重启大法好 但是也要正视一个问题必须等到进程退出后的返回值是非零才会触发重启策略不能直接监测容器是否是健康。 那么K8S中有没有更好的机制能够实现智能一点的健康检查呢答案就是使用Liveness与Readinesss。02—Liveness探测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: v1kind: Podmetadata: labels: test: liveness name: liveness-demospec: 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/healthy30秒后删除在我们的设置中如果 /tmp/healthy 存在则认为容器处于正常状态否则认为发生故障。 需要注意的就是livenessProbe部分的定义了 1探测方法通过cat命令查看/tmp/healthy是否存在如果返回值为0则探测成功否则探测失败 2initialDelaySeconds: 10 容器启动10秒之后开始执行liveness探测 3periodSeconds: 5 每5秒执行一次liveness探测如果连续执行3次探测都失败那么就会杀掉并重启容器 下面快速地验证一下 1kubectl创建demokubectl apply -f liveness-demo.yaml 2查看pod日志kubectl describe pod liveness-demo 结果如下图所示 30秒之后/tmp/healthy 被删除了liveness探测失败又过了几十秒重复探测均失败后开启了重启容器。 Liveness探针 上面的例子使用的是Liveness的exec探针此外K8S还有几种其他类型的探针exec在容器中执行一个命令如果命令退出码返回0则表示探测成功否则表示失败tcpSocket对指定的容IP及端口执行一个TCP检查如果端口是开放的则表示探测成功否则表示失败httpGet对指定的容器IP、端口及路径执行一个HTTP Get请求如果返回的状态码在 [200,400)之间则表示探测成功否则表示失败 针对tcpSocket的例子这里会检测80端口是否可以正常访问#检测80端口是否联通apiVersion: v1kind: Podmetadata: labels: test: readiness name: readiness-tcpspec: 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: v1kind: Podmetadata: labels: test: readiness name: readiness-httpgetspec: containers: - name: readiness image: nginx readinessProbe: failureThreshold: 3 httpGet: path: /index.html port: 80 scheme: HTTP initialDelaySeconds: 10 periodSeconds: 10 successThreshold: 1 timeoutSeconds: 1003—Readiness探测Readiness初体验一句话Readiness如果检查失败K8S会将该Pod从服务代理的分发后端去除不再让其接客分发请求给该Pod。如果检测成功那么K8S就会将容器加入到分发后端重新对外接客对外提供服务。 下面继续以上面Liveness的例子来实践一下apiVersion: v1kind: Podmetadata: labels: test: readiness name: readiness-demospec: 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状态为不可用 215秒initialDelaySeconds periodSeconds 10 5 15之后第一次进行Readiness探测成功其READY状态变为可用。 330秒之后/tmp/healthy被删除连续3次Readiness探测均失败后其READY状态又变为了不可用。 此外我们也可以通过 kubectl describe pod readiness-demo 查看到更想起的日志信息。与Liveness的对比 Liveness与Readiness都是K8S的Health Check机制Liveness探测是重启容器而Readiness探测则是将容器设置为不可用不让其再接受Service转发的请求。 Liveness与Readiness是独立执行的二者无依赖可以单独使用也可以同时使用。04—Health Check在K8S中的应用在Scale Up中的应用 对于多副本应用当执行Scale Up操作时新的副本会作为后端服务加入到Service的负载均衡列表中。但是很多时候应用的启动都需要一定的时间做准备比如加载缓存、连接数据库等等这时我们可以通过Readiness探测判断容器是否真正就绪从而避免将请求发送到还未真正就绪的后端服务。 下面一个示例YAML配置文件定义了Readiness探测重点关注readinessProbe部分apiVersion: apps/v1kind: Deploymentmetadata: name: edc-webapi-deployment namespace: aspnetcorespec: 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: v1kind: Servicemetadata: name: edc-webapi-service namespace: aspnetcorespec: type: NodePort ports: - nodePort: 31000 port: 8080 targetPort: 80 selector: name: edc-webapi 对于readinessProbe部分 1schema指定了协议这里是HTTP协议也可以是HTTPS协议 2path指定访问路径这里是我们自定义的一个Controller中的接口简单地返回一个状态码为200的响应 [Produces(application/json)] [Route(api/Health)] public class HealthController : Controller { [HttpGet] public IActionResult Get() Ok(ok); } 3port指定端口这里是容器的端口80 4initialDelaySeconds和periodSeconds指定了容器启动10秒之后开始探测然后每隔5秒执行探测如果发生3次以上探测失败则该容器会从Service的负载均衡中移除直到下次探测成功后才会重新加入。在Rolling Update中的应用 假设现在有一个正常运行的多副本应用我们要对其进行滚动更新即Rolling UpdateK8S会逐步用新Pod替换旧Pod结果就有可能发生这样的一个场景当所有旧副本被替换之后而新的Pod由于人为配置错误一直无法启动因此整个应用将无法处理请求无法对外提供服务后果很严重 因此Readiness探测还提供了用于避免滚动更新中出现这种情况的一些解决办法比如maxSurge和maxUnavailable两个参数用来控制副本替换的数量。 继续以上面的YAML配置文件为例重点关注strategy部分apiVersion: apps/v1kind: Deploymentmetadata: name: edc-webapi-deployment namespace: aspnetcorespec: 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: v1kind: Servicemetadata: name: edc-webapi-service namespace: aspnetcorespec: type: NodePort ports: - nodePort: 31000 port: 8080 targetPort: 80 selector: name: edc-webapi 1maxSurge : 25% 控制滚动更新过程中副本总数超过预期这里预期是10个副本 replicas: 10的上限可以是数值也可以是百分比然后向上取整。这里写的百分比默认值是25% 如果预期副本数为10那么副本总数的最大值为RoundUp(10 10 * 25%)13个。 2maxUnavailable : 25% 控制滚动更新过程中不可用的副本这里预期是10个副本 replicas: 10占预期的最大比例可以是数值也可以是百分比然后向下取整同样地默认值也是25% 如果预期副本总数为10那么可用的副本数至少要为10-roundDown(10 * 25%)10-28个。 综上看来maxSurge的值越大初始创建的新副本数量就越多maxUnavaliable值越大初始销毁的旧副本数量就越多05—小结本文探索了K8S中的默认健康检查机制以及Liveness和Readiness两种各有特点的探测机制并通过一些小例子进行了说明。不过由于笔者也是初学对于这一块没有过多实践经验因此也是讲的比较粗浅也希望以后能够有更多的实际经验分享与各位。参考资料1CloudMan《每天5分钟玩转Kubernetes》2李振良《一天入门Kubernets教程》3马哥马永亮《Kubernetes快速入门》4华仔《[译]Kubernetes最佳实践使用Readiness和Liveness探测做Health Check》5benjanmin杨《K8S中的Health Check》6条子在洗澡《K8S健康性检查-探测》恰童鞋骚年风华不再正茂仍想挥斥方遒点个在看少个bug ?
