K8S使用就绪和存活探针配置健康检查

健康检查

健康检查（Health Check）可用于服务运行的状态监控，好比腾讯旗下的DNSPOD的D监控，要求配置一个访问路径以判断网站是否能够正常访问实际上就是一个健康检查，当发现健康检查失败时会发送一个邮件通知或者短信来告知网站管理员进行维修。

K8S流量转发

而在现代一些分布式系统中，用户访问再也不是单台主机，而是一个由成百上千台实例组成的集群，用户请求经过负载均衡器分发到不一样的实例，负载均衡帮助解决单台服务器的访问压力，同时提升了系统的高可用性，而健康检查经常做为当前实例是否“可用”的判断标准。即：当系统发现某台实例健康检查不经过，负载均衡器将不会把流量导向该实例。

如今的云服务厂商好比AWS通常都为负载均衡配备了健康检查，而Kubernetes提供了两种探针来检查容器的状态，Liveliness和Readiness，根据官方文档，Liveliness探针是为了查看容器是否正在运行，翻译为存活探针（livenessProbe），Readiness探针是为了查看容器是否准备好接受HTTP请求，翻译为就绪探针（readinessProbe）。
在Kubernetes中，Pod是Kubernetes建立及管理的最小的可部署的计算单元，一个Pod由一个或者多个容器（Docker，rocket等等）组成，这些容器共享内存，网络以及运行容器的方式。

在Kubernetes上下文中存活探针和就绪探针被称做健康检查。这些容器探针是一些周期性运行的小进程，这些探针返回的结果（成功，失败或者未知）反映了容器在Kubernetes的状态。基于这些结果，Kubernetes会判断如何处理每一个容器，以保证弹性，高可用性和更长的正常运行时间。

就绪探针

就绪探针旨在让Kubernetes知道你的应用是否准备好为请求提供服务。Kubernetes只有在就绪探针经过才会把流量转发到Pod。若是就绪探针检测失败，Kubernetes将中止向该容器发送流量，直到它经过。

存活探针

Liveness探测器是让Kubernetes知道你的应用是否活着。若是你的应用还活着，那么Kubernetes就让它继续存在。若是你的应用程序已经死了，Kubernetes将移除Pod并从新启动一个来替换它。

工做过程

让咱们看看两个场景，来看看就绪探针和存活探针怎样帮助咱们构建更高可用的的系统。

就绪探针

一个应用每每须要一段时间来预热和启动，好比一个后端项目的启动须要链接数据库执行数据库迁移等等，一个Spring项目的启动也须要依赖Java虚拟机。即便该过程已启动，您的服务在启动并运行以前也没法运行。应用在彻底就绪以前不该接收流量，但默认状况下，Kubernetes会在容器内的进程启动后当即开始发送流量。经过就绪探针探测，直到应用程序彻底启动，而后才容许将流量发送到新副本。

 

就绪探针的工做过程

存活探针

让咱们想象另外一种状况，当咱们的应用在成功启动之后由于一些缘由“宕机”，或者遇到死锁状况，致使它没法响应用户请求。
在默认状况下，Kubernetes会继续向Pod发送请求，经过使用存活探针来检测，当发现服务不能在限定时间内处理请求（请求错误或者超时），就会从新启动有问题的pod。

存活探针的工做过程

探针类型

探针类型是指经过何种方式来进行健康检查，K8S有三种类型的探测：HTTP，Command和TCP。
HTTP
HTTP探测多是最多见的探针类型。即便应用不是HTTP服务，也能够建立一个轻量级HTTP服务器来响应探测。好比让Kubernetes经过HTTP访问一个URL，若是返回码在200到300范围内，就将应用程序标记为健康状态，不然它被标记为不健康。
更多关于HTTP探测可参考这里。

命令
对于命令探测，是指Kubernetes在容器内运行命令。若是命令以退出代码0返回，则容器将标记为正常。不然，它被标记为不健康。
更多关于命令探测可参考这里。

TCP
最后一种类型的探测是TCP探测，Kubernetes尝试在指定端口上创建TCP链接。若是它能够创建链接，容器被认为是健康的; 若是它不能被认为是不健康的。这经常使用于对gRPC或FTP服务的探测。

更多关于TCP探测可参考这里。

初始探测延迟

咱们能够配置K8S健康检查运行的频率，检查成功或失败的条件，以及响应的超时时间。可参考有关配置探针的文档。

存活探针探测失败会致使pod从新启动，因此配置初始探测延迟initialDelaySeconds十分重要，要确保在应用准备以后探针才启动。不然，应用将无限重启！

我建议使用p99启动时间做为initialDelaySeconds，或者取平均启动时间外加一个buffer。同时根据应用程序的启动时间更新这个值。

举例

如下面的一个K8S的配置代码为例，

• K8S将在Pod开始启动后120s(initialDelaySeconds)后利用HTTP访问8080端口的/actuator/health，若是超过10s或者返回码不在200~300内，就绪检查就失败
• 相似的，在Pod运行过程当中，K8S仍然会每隔5s(periodSeconds检测8080端口的/actuator/health

apiVersion: apps/v1beta1
kind: Deployment
...
...
        readinessProbe:
          httpGet:
            path: /actuator/health
            port: 8080
          initialDelaySeconds: 120
          timeoutSeconds: 10
        livenessProbe:
          httpGet:
            path: /actuator/health
            port: 8080
          initialDelaySeconds: 60
          timeoutSeconds: 10
          periodSeconds: 5

参考资料

• 【Kubernetes best practices: Setting up health checks with readiness and liveness probes】
• 【Kubernetes存活探针和就绪探针的最佳实践】