Kubernetes之健康检查与服务依赖处理-低调大师

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

2017-10-10 599

本文讲的是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-serviceA
    image: registry.docker.dev.fwmrm.net/busybox:latest
    command: ['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之健康检查与服务依赖处理

微信关注我们

原文链接：https://yq.aliyun.com/articles/224581

转载内容版权归作者及来源网站所有！

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。

Jenkins与Docker的持续集成实践

本文讲的是Jenkins与Docker的持续集成实践【编者的话】持续集成（CI/CD）是一种软件开发实践。用于帮助团队成员频繁、快速的集成，测试他们的工作成果，以尽快发现集成错误。更频繁、更早的集成意味着更早的发现问题。通过持续集成，及时发现和解决代码故障，提高代码质量，减少故障处理成本等等。【3 天烧脑式基于Docker的CI/CD实战训练营 | 北京站】本次培训围绕基于Docker的CI/CD实战展开，具体内容包括：持续集成与持续交付（CI/CD）概览；持续集成系统介绍；客户端与服务端的 CI/CD 实践；开发流程中引入 CI、CD；Gitlab 和 CI、CD 工具；Gitlab CI、Drone 的使用以及实践经验分享等。常见持续集成工具目前持续集成的生态越来越完善，工具也有很多，开源的或商业的。如：最最流行的，也是使用最多的Jenkins 有着持续集成DNA的ThoughtWorks GO。理念："Deployment as pipeline" （华为容器平台应该是基于GO做的二次开发实现） Atlassian工具链之一的Bamboo 与Gitlab紧密集成的Git...

2017-10-11

602

本文讲的是在Windows 10上运行Linux及Windows容器【编者的话】DockerCon 2016上Docker官方发布了Docker for Windows的公开测试版本，在这一版本里，添加了对在Windows 10上运行Windows容器（包括nanoserver和servercore）、Linux容器以及两者并存的支持，本文作者就这一话题为我们展示了一些具体的实例操作并进一步分析了背后的运行机制。在西雅图举办的DockerCon 2016上，Docker官方发布了Docker Windows的公开测试版本。在这一版本里，你能够以一种非常简便的方式在安装了Hyper-V的Windows 10专业版上通过Docker运行Linux容器。在一段时间内这里会同时存在一个稳定版本以及一个测试版本渠道以获取新的版本。并且，微软已经将容器功能添加到了Windows 10的年度更新补丁里。通过一些安装步骤，你便能在你的Windows 10机器上运行 Windows Hyper-V容器。但是这里面可能存在点小疑问，那便是这两种安装方式对应启动的是哪类容器。而且，在不做...

2017-10-11

550

资源下载

更多资源

腾讯云软件源

为解决软件依赖安装时官方源访问速度慢的问题，腾讯云为一些软件搭建了缓存服务。您可以通过使用腾讯云软件源站来提升依赖包的安装速度。为了方便用户自由搭建服务架构，目前腾讯云软件源站支持公网访问和内网访问。

Nacos

Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service 的首字母简称，一个易于构建 AI Agent 应用的动态服务发现、配置管理和AI智能体管理平台。Nacos 致力于帮助您发现、配置和管理微服务及AI智能体应用。Nacos 提供了一组简单易用的特性集，帮助您快速实现动态服务发现、服务配置、服务元数据、流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。

Spring

Spring框架（Spring Framework）是由Rod Johnson于2002年提出的开源Java企业级应用框架，旨在通过使用JavaBean替代传统EJB实现方式降低企业级编程开发的复杂性。该框架基于简单性、可测试性和松耦合性设计理念，提供核心容器、应用上下文、数据访问集成等模块，支持整合Hibernate、Struts等第三方框架，其适用范围不仅限于服务器端开发，绝大多数Java应用均可从中受益。

Rocky Linux

Rocky Linux（中文名：洛基）是由Gregory Kurtzer于2020年12月发起的企业级Linux发行版，作为CentOS稳定版停止维护后与RHEL（Red Hat Enterprise Linux）完全兼容的开源替代方案，由社区拥有并管理，支持x86_64、aarch64等架构。其通过重新编译RHEL源代码提供长期稳定性，采用模块化包装和SELinux安全架构，默认包含GNOME桌面环境及XFS文件系统，支持十年生命周期更新。