湘潭网站推广,大兴区营销网络推广行业,网站开发系统绿色版,百度推广登陆平台k8s通过liveness来探测微服务的存活性#xff0c;判断什么时候该重启容器实现自愈。比如访问 Web 服务器时显示 500 内部错误#xff0c;可能是系统超载#xff0c;也可能是资源死锁#xff0c;此时 httpd 进程并没有异常退出#xff0c;在这种情况下重启容器可能是最直接… k8s通过liveness来探测微服务的存活性判断什么时候该重启容器实现自愈。比如访问 Web 服务器时显示 500 内部错误可能是系统超载也可能是资源死锁此时 httpd 进程并没有异常退出在这种情况下重启容器可能是最直接最有效的解决方案。 k8s通过readiness来探测微服务的什么时候准备就绪例如初始化时连接数据库加载缓存数据等等可能需要一段时间然后将容器加入到server的负载均衡池中对外提供服务。 k8s默认健康检查机制 每个容器启动时都会执行一个进程此进程由 Dockerfile 的 CMD 或 ENTRYPOINT 指定。如果进程退出时返回码非零则认为容器发生故障Kubernetes 就会根据 restartPolicy 重启容器。如果不特意配置Kubernetes 将对两种探测采取相同的默认行为。 OK那我们就来实现一下新建.Net Core Api项目 k8s-healthcheck新增Heathchecks控制器 [Route(/api/v1/heathchecks)]public class HeathchecksController : Controller{private readonly static DateTime _beginUtc DateTime.Now;[HttpGet][Route(test)]public ActionResultIEnumerablestring Test(){return new string[] { value1, value2 };}[HttpGet][ProducesResponseType((int)HttpStatusCode.OK)][ProducesResponseType((int)HttpStatusCode.ServiceUnavailable)][Route(liveness)]public async TaskIActionResult Liveness(){return await Task.RunIActionResult(() {if(DateTime.UtcNow.Subtract(_beginUtc).TotalSeconds60*10){Console.WriteLine({0} HealthChecks.Api is dead start restarting...,DateTime.Now);return this.NotFound();}else{Console.WriteLine({0} HealthChecks.Api is alive.,DateTime.Now);return this.Ok();}});}[HttpGet][ProducesResponseType((int)HttpStatusCode.OK)][ProducesResponseType((int)HttpStatusCode.ServiceUnavailable)][Route(readiness)]public async TaskIActionResult Readiness(){return await Task.RunIActionResult(() {if(DateTime.UtcNow.Subtract(_beginUtc).TotalSeconds30){Console.WriteLine({0} HealthChecks.Api is not ready...,DateTime.Now);return this.NotFound();}else{Console.WriteLine({0} HealthChecks is ready,start accepting traffic..., DateTime.Now);return this.Ok();}});}} 解释一下我们这里自定义的 liveness 和 readiness检查机制 liveness存活10分钟如果当前时间超过服务启动时间10分钟则探测失败否则探测成功。Kubernetes 如果连续执行 3 次 Liveness 探测均失败就会杀掉并重启容器。 readiness准备就绪30秒30秒后如果连续 3 次 Readiness 探测均失败后容器将被重置为不可用不接收 service 转发的请求。 从上面可以看到我们可以根据自身的需求来实现这两种机制然后提供给k8s进行探测。 k8s默认是根据命令进行探测的由于我们需要与微服务结合所以需要在yml文件中指定为http方式备注k8s提供了三种container probes方式command、TCP check、HTTP Get其他的方式希望大家下去自己实践k8s对于http方式探测成功的判断条件是请求的返回代码在 200-400 之间。 该项目的 deploy.yaml 内容如下 apiVersion: apps/v1
kind: Deployment
metadata:namespace: k8s-ecoysystem-appsname: k8s-healthchecklabels:app: k8s-healthcheck
spec:replicas: 3selector:matchLabels:app: k8s-healthchecktemplate:metadata:namespace: k8s-ecoysystem-appslabels:app: k8s-healthcheckspec:containers:- name: k8s-healthcheckimagePullPolicy: Alwaysimage: 1151322093/k8s-healthcheckports:- containerPort: 80readinessProbe:httpGet:path: /api/v1/heathchecks/readinessport: 80scheme: HTTP initialDelaySeconds: 30periodSeconds: 60 livenessProbe:httpGet:path: /api/v1/heathchecks/livenessport: 80scheme: HTTP initialDelaySeconds: 120periodSeconds: 60 运行kubectl apply -f deploy.yaml然后通过 kubectl get pod -n k8s-ecoysystem-apps查看当前运行的pod可以看到创建开始是不可以的Ready状态数量是0。 稍等等待一会发现都可以用了 然后我们通过 kubectl describe pod k8s-healthcheck-5c85bdcb69-f9zk9 -n k8s-ecoysystem-apps 命令可以查看更具体的信息 刚开始readiness返回404不可用状态不过我们设置的是30秒检查一次所以很快状态就消除了通过dashboard界面我们也可以看到更直观的信息 等待10分钟过后Liveness检测将会返回失败pod处于不可用状态 继续等待一会集群就会自愈完成前面说过Liveness检测3次失败就会删除pod并重启重启之后就一轮新的检测 从上面图中可以看到集群已经重启过1次继续等待一段时间如图 Liveness 探测和 Readiness 探测是独立执行的二者之间没有依赖可以单独使用也可以同时使用。用 Liveness 探测判断容器是否需要重启以实现自愈用 Readiness 探测判断容器是否已经准备好对外提供服务。 OK大功告成转载于:https://www.cnblogs.com/weiBlog/p/10056281.html
