Kubernetes之健康检查与服务依赖处理

本文讲的是Kubernetes之健康检查与服务依赖处理【编者的话】对线上业务来说，保证服务的正常稳定是重中之重，对故障服务的及时处理避免影响业务以及快速恢复一直是开发运维的难点。Kubernetes提供了健康检查服务，对于检测到故障服务会被及时自动下线，以及通过重启服务的方式使服务自动恢复。而对于服务依赖，无论资源描述文件是pod, rc或deployment, 对应yaml文件中描述仅是container启动顺序而非Container中服务启动顺序，Kubernetes提供了的Init Container，可处理服务之间依赖。

【3 天烧脑式基于Docker的CI/CD实战训练营 | 北京站】本次培训围绕基于Docker的CI/CD实战展开，具体内容包括：持续集成与持续交付（CI/CD）概览；持续集成系统介绍；客户端与服务端的 CI/CD 实践；开发流程中引入 CI、CD；Gitlab 和 CI、CD 工具；Gitlab CI、Drone 的使用以及实践经验分享等。

简单例子说明什么是健康检查以及服务依赖，比如一个应用分别有A、B、 C 3个服务，健康检查就是如何确定A、B与C所在的Container处于运行状态且服务工作正常；而对于服务依赖，假设服务A必须在服务B成功启动之前启动，而服务B必须在服务C成功启动之前启动，即启动顺序为A->B->C。

健康检查

使用Liveness及Readness探针

Liveness探针：主要用于判断Container是否处于运行状态，比如当服务crash或者死锁等情况发生时，kubelet会kill掉Container, 然后根据其设置的restart policy进行相应操作（可能会在本机重新启动Container，或者因为设置Kubernetes QoS，本机没有资源情况下会被分发的其他机器上重新启动）。
Readness探针：主要用于判断服务是否已经正常工作，如果服务没有加载完成或工作异常，服务所在的Pod的IP地址会从服务的endpoints中被移除，也就是说，当服务没有ready时，会将其从服务的load balancer中移除，不会再接受或响应任何请求。

探针处理Handler类型

无论对于Readness或Liveness探针，Handler均支持以下3种类型：ExecAction, TCPSocketAction, HTTPGetAction。每种类型说明与举例如下：

ExecAction：Container内部执行某个具体的命令，例子。
TCPSocketAction：通过container的IP、port执行tcp进行检查，例子。
HTTPGetAction: 通过container的IP、port、path，用HTTP Get请求进行检查，例子。

探针检查结果

探针检查结果分为3种情况：

成功（Success）：通过检查。
失败（Failure）：检查失败。
未知（Unknown）：检查未知，需要人工干预。

健康检查总结

探针类型          说明                                 通过健康检查标准
ExecAction       container内部执行shell命令            shell命令返回0
TCPSocketAction  通过container的IP、port执行tcp进行检查  port是否打开
HTTPGetAction    通过container的IP、port、path，       200<=返回值<400用HTTP Get请求进行检查

服务可用性与自动恢复

1. 如果服务的健康检查（readiness）失败，故障的服务实例从service endpoint中下线，外部请求将不会再转发到该服务上，一定程度上保证正在提供的服务的正确性，如果服务自我恢复了（比如网络问题），会自动重新加入service endpoint对外提供服务。
2. 另外，如果设置了Container（liveness）的探针，对故障服务的Container（liveness）的探针同样会失败，container会被kill掉，并根据原设置的container重启策略，系统倾向于在其原所在的机器上重启该container、或其他机器重新创建一个pod。
3. 由于上面的机制，整个服务实现了自身可用与自动恢复。

使用建议：

1. 建议对全部服务同时设置服务（readiness）和Container（liveness）的健康检查
2. 通过TCP对端口检查形式（TCPSocketAction），仅适用于端口已关闭或进程停止情况。因为即使服务异常，只要端口是打开状态，健康检查仍然是通过的。
3. 基于第二点，一般建议用ExecAction自定义健康检查逻辑，或采用HTTP Get请求进行检查（HTTPGetAction）。
4. 无论采用哪种类型的探针，一般建议设置检查服务（readiness）的时间短于检查Container（liveness）的时间，也可以将检查服务（readiness）的探针与Container（liveness）的探针设置为一致。目的是故障服务先下线，如果过一段时间还无法自动恢复，那么根据重启策略，重启该container、或其他机器重新创建一个pod恢复故障服务。

服务依赖

理解Init Container

一个pod中可以有一或多个Init Container。Pod的中多个Init Container启动顺序为yaml文件中的描述顺序，且串行方式启动，下一个Init/app Container必须等待上一个Init Container完成后方可启动。例如，Init Container1-> ... -> Init Containern -> app Container[1-n]。Init Container1成功启动并且完成后，后续的Init Container和app Container才可以启动，如Init Container启动或执行相关检查失败，后续的init Container和应用Container将不会被执行启动命令。

因此可利用Init Container来判断app Container中被依赖的服务是否成功启动。如被依赖的app Container服务启动失败，那么利用Init Container启动失败可以阻止后续app Container服务的启动。

由于Init Container必须要在pod状态变为Ready之前完成，所以其不需要readiness探针。另外在资源的requests与limits上与普通Container有细微差别，详见 Resources ，除以上2点外，Init Container与普通Container并无明显区别。

Init Containers用途

前文已经提及，由于Init Container必须在app Containers启动之前完成，所以可利用其特性，用作服务依赖处理。比如某一个服务A，需依赖db或memcached，那么可以利用服务A pod的Init Container判断db/memcached是否正常提供服务，如果启动服务失败或工作异常，设置Init Container启动失败，那么pod中的服务A就不会被启动了。
应用镜像因安全原因等没办法安装或运行的工具，可放到Init Container中运行。另外，Init Container独立于业务服务，与业务无关的工具如sed, awk, python, dig等也可以按需放到Init Container之中。最后，Init Container也可以被授权访问应用Container无权访问的内容。

Init Container处理服务依赖应用举例

serviceA服务依赖serviceB，而serviceB采用上文提及Readness探针的HTTPGetAction Handler。

spec:initContainers:- name: init-serviceAimage: registry.docker.dev.fwmrm.net/busybox:latestcommand: ['sh', '-c', "curl --connect-timeout 3 --max-time 5 --retry 10 --retry-delay 5 --retry-max-time 60 serviceB:portB/pathB/"]containers:

如果启动serviceA Pod时，serviceB还没有ready，通过kubectl get po -o wide查看pod处于Init状态

NAME                        READY     STATUS    RESTARTS   AGE       IP          .l  NODE
serviceA-3071943788-8x27q            0/1       Init:0/1   0          20s       10.244.1.172   bjo-ep-svc-017.dev.fwmrm.net

通过kubectl describe po serviceA-3071943788-g03wt查看,可以看出app Container的启动时在init Container启动并成功完成后：

Events:
FirstSeen LastSeen    Count   From                    SubObjectPath               Type        Reason  Message
--------- --------    -----   ----                    -------------               --------    ------  -------
25s       25s     1   default-scheduler                               Normal      ScheduledSuccessfully assigned serviceA-3071943788-g03wt to bjo-ep-dep-040.dev.fwmrm.net
25s       25s     1   kubelet, bjo-ep-dep-040.dev.fwmrm.net                       Normal      SuccessfulMountVolume   MountVolume.SetUp succeeded for volume "serviceA-config-volume"
25s       25s     1   kubelet, bjo-ep-dep-040.dev.fwmrm.net                       Normal      SuccessfulMountVolume   MountVolume.SetUp succeeded for volume "default-token-2c9j1"
24s       24s     1   kubelet, bjo-ep-dep-040.dev.fwmrm.net   spec.initContainers{init-myservice} Normal      Pulling pulling image "registry.docker.dev.fwmrm.net/ui-search-solr-data:latest"
24s       24s     1   kubelet, bjo-ep-dep-040.dev.fwmrm.net   spec.initContainers{init-myservice} Normal      Pulled  Successfully pulled image "registry.docker.dev.fwmrm.net/busybox:latest"
24s       24s     1   kubelet, bjo-ep-dep-040.dev.fwmrm.net   spec.initContainers{init-myservice} Normal      Created Created container
24s       24s     1   kubelet, bjo-ep-dep-040.dev.fwmrm.net   spec.initContainers{init-myservice} Normal      Started Started container
20s       20s     1   kubelet, bjo-ep-dep-040.dev.fwmrm.net   spec.containers{is}         Normal      Pulling pulling image "registry.docker.dev.fwmrm.net/infra/is:latest"
20s       20s     1   kubelet, bjo-ep-dep-040.dev.fwmrm.net   spec.containers{is}         Normal      Pulled  Successfully pulled image "registry.docker.dev.fwmrm.net/infra/is:latest"
20s       20s     1   kubelet, bjo-ep-dep-040.dev.fwmrm.net   spec.containers{is}         Normal      Created Created container
19s       19s     1   kubelet, bjo-ep-dep-040.dev.fwmrm.net   spec.containers{is}         Normal      Started Started container

查看docker Container log，init Container正在按照预先的设定，每3秒轮询验证serviceB健康检查点serviceB:portB/pathB/

docker logs 4fd58bf54f76
waiting for serviceB service
waiting for serviceB service
... ...

等待一段时间后，再次通过kubectl get po -o wide查看pod处于Running状态

NAME                        READY     STATUS    RESTARTS   AGE       IP          .l  NODE
serviceA-3071943788-g03wt   1/1       Running   0          1m        10.244.2.68   bjo-ep-dep-040.dev.fwmrm.net

如果pod重启了，所有init Container都需重新运行。Kubernetes禁止Init Container使用readiness探针，可以使用Pod定义 activeDeadlineSeconds 和 Container的 livenessProbe 防止 init containers 一直重复失败. activeDeadlineSeconds 包含了 init container 启动的时间。

参考资料

Container Lifecycle Hooks: https://kubernetes.io/docs/con ... ooks/
Attach Handlers to Container Lifecycle Events: https://kubernetes.io/docs/tas ... vent/
Init Containers: https://kubernetes.io/docs/con ... ners/
Init Container and Probe: https://blog.giantswarm.io/wai ... etes/
Configure Pod Initialisation: https://kubernetes.io/docs/tas ... ainer
Debug Init Containers: https://kubernetes.io/docs/tas ... ners/
Delaying the deployment of our stubborn service: https://blog.giantswarm.io/wai ... etes/

欢迎转载，请注明作者出处：张夏，FreeWheel Lead Engineer，DockOne社区

原文发布时间为：2017-08-13

本文作者：张夏

本文来自云栖社区合作伙伴Dockerone.io，了解相关信息可以关注Dockerone.io。

原文标题：Kubernetes之健康检查与服务依赖处理