aspnetcore.webapi实战k8s健康探测机制 - kubernetes

一、浅析k8s两种健康检查机制

• Liveness 

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

• Readiness 

      k8s经过readiness来探测微服务的何时准备就绪（例如初始化时，链接数据库，加载缓存数据等等，可能须要一段时间），而后将容器加入到server的负载均衡池中，对外提供服务。

    1.一、k8s默认的健康检查机制

      每一个容器启动时都会执行一个进程，此进程由 Dockerfile 的 CMD 或 ENTRYPOINT 指定。若是进程退出时返回码非零，则认为容器发生故障，Kubernetes 就会根据 restartPolicy 重启容器。若是不特地配置，Kubernetes 将对两种探测采起相同的默认行为。

二、经过微服务自定义两种机制

存活10分钟：若是当前时间超过服务启动时间10分钟，则探测失败，不然探测成功。Kubernetes 若是连续执行 3 次 Liveness 探测均失败，就会杀掉并重启容器。

准备就绪30秒，30秒后，若是连续 3 次 Readiness 探测均失败后，容器将被重置为不可用，不接收 service 转发的请求。

从上面能够看到，咱们能够根据自身的需求来实现这两种机制，而后，提供给k8s进行探测。

三、编写k8s资源配置文件(yml)

k8s默认是根据命令进行探测的，因为咱们须要与微服务结合，因此须要在yml文件中指定为http方式（备注：k8s提供了三种container probes方式：command、TCP check、HTTP Get，其余的方式但愿你们下去本身实践），k8s对于http方式探测成功的判断条件是请求的返回代码在 200-400 之间。

health-checks-deployment.yml 以下：

apiVersion: apps/v1
kind: Deployment
metadata:
  namespace: k8s-ecoysystem-apps
  name: healthchecks-api
  labels:
    app: healthchecks-api
spec:
  replicas: 3
  selector:
    matchLabels:
      app: healthchecks-api
  template:
    metadata:
      namespace: k8s-ecoysystem-apps
      labels:
        app: healthchecks-api
    spec:
      containers:
      - name: healthchecks-api
        imagePullPolicy: Always
        image: justmine/healthchecksapi:v1.5
        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

从上面能够看到，一共部署了3个pod副本，而每一个pod副本里面部署一个容器，即为同一个微服务部署了3个实例进行集群。

四、在k8s集群的master机器上，建立部署对象

从上面能够看到，刚开始建立时，READY 状态为不可用，等待一段时间

如今所有可用了

五、经过dashboard查看集群概况

 

六、剖析k8s集群自愈(self-healing)过程

从上面能够看到，大约1分钟(dashboard统计信息有必定的延迟)左右，第一次进行 Readiness 探测并成功返回，此时准备就绪，能够对外提供服务了。在10分钟内，探测Liveness也成功返回。

继续等待一段时间，查询其中一个pod详细信息：

从上面能够看到，超过10分钟存活期后，liveness探测失败，容器被 killed and recreated。探测Readiness未成功返回时，整个容器处于不健康的状态，并不会被负载均衡请求。

此时经过dashboard查看集群概况：

 

继续等待一段时间：

如今，整个集群已经自愈完成了！！！

七、总结

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

若是你以为本篇文章对您有帮助的话，感谢您的【推荐】。
若是你对 kubernets 感兴趣的话能够关注我，我会按期的在博客分享个人学习心得。

源码参考：https://github.com/justmine66/k8s.ecoysystem.apps

下一篇，咱们将实践微服务中的环境变量和配置信息，如何与k8s进行结合。