运维开发网

Docker系列(五):.Net Core实现k8s健康探测机制

运维开发网 https://www.qedev.com 2020-06-03 09:52 出处:网络 作者:运维开发网整理
k8s通过liveness来探测微服务的存活性,判断什么时候该重启容器实现自愈。比如访问 Web 服务器时显示 500 内部错误,可能是系统超载,也可能是资源死锁,此时 httpd 进程并没有异常退出,在这种情况下重启容器可能是最直接最有效的解决方案。         k8s通过liveness来探测微服务的存活性,判断什么时候该重启容器实现自愈。比如访问 Web 服务器时显示 5

        k8s通过liveness来探测微服务的存活性,判断什么时候该重启容器实现自愈。比如访问 Web 服务器时显示 500 内部错误,可能是系统超载,也可能是资源死锁,此时 httpd 进程并没有异常退出,在这种情况下重启容器可能是最直接最有效的解决方案。

        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 ActionResult<IEnumerable<string>> Test()
        {
            return new string[] { "value1", "value2" };
        }

        [HttpGet]
        [ProducesResponseType((int)HttpStatusCode.OK)]
        [ProducesResponseType((int)HttpStatusCode.ServiceUnavailable)]
        [Route("liveness")]
        public async Task<IActionResult> Liveness()
        {
            return await Task.Run<IActionResult>(() =>
            {
                if(DateTime.UtcNow.Subtract(_beginUtc).TotalSeconds>60*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 Task<IActionResult> Readiness()
        {
            return await Task.Run<IActionResult>(() =>
            {
                if(DateTime.UtcNow.Subtract(_beginUtc).TotalSeconds<30)
                {
                    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-apps
  name: k8s-healthcheck
  labels:
    app: k8s-healthcheck
spec:
  replicas: 3
  selector:
    matchLabels:
      app: k8s-healthcheck
  template:
    metadata:
      namespace: k8s-ecoysystem-apps
      labels:
        app: k8s-healthcheck
    spec:
      containers:
      - name: k8s-healthcheck
        imagePullPolicy: Always
        image: 1151322093/k8s-healthcheck
        ports:
        - containerPort: 80
        readinessProbe:
          httpGet:
            path: /api/v1/heathchecks/readiness
            port: 80
            scheme: HTTP 
          initialDelaySeconds: 30
          periodSeconds: 60 
        livenessProbe:
          httpGet:
            path: /api/v1/heathchecks/liveness
            port: 80
            scheme: HTTP 
          initialDelaySeconds: 120
          periodSeconds: 60

运行:kubectl apply -f deploy.yaml,然后通过 kubectl get pod -n k8s-ecoysystem-apps查看当前运行的pod,可以看到创建开始是不可以的,Ready状态数量是0。

 

Docker系列(五):.Net Core实现k8s健康探测机制

稍等等待一会发现都可以用了:

Docker系列(五):.Net Core实现k8s健康探测机制

然后我们通过 kubectl describe pod k8s-healthcheck-5c85bdcb69-f9zk9 -n k8s-ecoysystem-apps 命令可以查看更具体的信息:

Docker系列(五):.Net Core实现k8s健康探测机制

刚开始readiness返回404不可用状态,不过我们设置的是30秒检查一次,所以很快状态就消除了,通过dashboard界面我们也可以看到更直观的信息:

 

Docker系列(五):.Net Core实现k8s健康探测机制

 

等待10分钟过后,Liveness检测将会返回失败,pod处于不可用状态:

 

Docker系列(五):.Net Core实现k8s健康探测机制

 

 

Docker系列(五):.Net Core实现k8s健康探测机制

继续等待一会,集群就会自愈完成,前面说过,Liveness检测3次失败就会删除pod,并重启,重启之后就一轮新的检测:

Docker系列(五):.Net Core实现k8s健康探测机制

Docker系列(五):.Net Core实现k8s健康探测机制

Docker系列(五):.Net Core实现k8s健康探测机制

从上面图中可以看到集群已经重启过1次,继续等待一段时间,如图:

Docker系列(五):.Net Core实现k8s健康探测机制

 

 Liveness 探测和 Readiness 探测是独立执行的,二者之间没有依赖,可以单独使用,也可以同时使用。用 Liveness 探测判断容器是否需要重启以实现自愈;用 Readiness 探测判断容器是否已经准备好对外提供服务

 

OK,大功告成!!

0

精彩评论

暂无评论...
验证码 换一张
取 消