CN111142971A - 一种适应传统应用云化的云平台应用就绪检查方法 - Google Patents

Abstract

本发明提出一种适应传统应用云化的云平台应用就绪检查方法，包括如下步骤：步骤1：约定应用就绪检查输出标志，并根据该标志的含义编写shell脚本，对标志进行是或者否的判断；步骤2：通过边车模块自动注入一个边车提供就绪检查功能；步骤3：使用自定义资源CRD声明自定义就绪条件及判断规则；步骤4：通过web回调API的Webhook模块自动注入步骤3声明的条件；步骤5：控制器根据指标收集服务获取的指标不断更新自定义的Pod的就绪条件值。

Description

一种适应传统应用云化的云平台应用就绪检查方法

技术领域

本发明涉及应用云部署领域，具体的涉及一种适应传统应用云化的云平台应用就绪检查的方法。

背景技术

首先，进行以下术语的说明：

Kubernetes：Kubernetes是用于自动部署，扩展和管理容器化应用程序的开源系统。它将组成应用程序的容器组合成逻辑单元，以便于管理和服务发现，是生产级别的容器编排系统。

Kubelet：kubernetes集群的每个节点(node)上都要运行一个worker(或节点代理)对容器进行生命周期的管理，这个worker程序就是kubelet。

Pod：Pod是Kubernetes创建或部署的最小/最简单的基本单位，Pod是所有业务类型的基础，它是一个或多个容器的组合。这些容器共享存储、网络和命名空间，以及如何运行的规范。在Pod中，所有容器都被统一安排和调度，并运行在共享的上下文中。对于具体应用而言，Pod是它们的逻辑主机，Pod包含业务相关的多个应用容器(Container)。

Volume：Volume是Pod中能够被多个容器共享的磁盘目录。Kubernetes中的卷有明确的寿命，与封装它的Pod相同。卷的核心是目录，可能还包含了一些数据，可以通过pod中的容器来访问。该目录是如何形成的、支持该目录的介质以及其内容取决于所使用的特定卷类型。

emptyDir：emptyDir类型的Volume在Pod分配到Node上时被创建，Kubernetes会在Node上自动分配一个目录，因此无需指定宿主机Node上对应的目录文件。这个目录的初始内容为空，当Pod从Node上移除时，emptyDir中的数据会被永久删除。emptyDir Volume主要用于某些应用程序无需永久保存的临时目录，多个容器的共享目录等。

Sidecar:就如sidecar连接着摩托车一样，sidecar应用与主应用程序松散耦合。在Pod中用额外的容器来扩展或增强主容器，而这个额外的容器被称为sidecar容器。

CRD:自定义资源(CustomResourceDefinition)是对Kubernetes API的扩展，kubernetes中的每个资源都是一个API对象的集合，例如我们在YAML文件里定义的那些spec都是对kubernetes中的资源对象的定义，所有的自定义资源可以跟kubernetes中内建的资源一样使用kubectl操作。

Webhook：webhook是一种web回调API，在数据可用时发送到注册的地址。

Prometheus:Prometheus是一个开源监控系统，具有强大的数据采集、存储、展示和告警等功能，对Kubernetes的监控提供完善支持。

云原生:2015年Google主导成立了云原生计算基金会(CNCF)，对云原生(CloudNative)定义包含应用容器化，支持容器的编排调度并面向微服务架构。云原生技术有利于各组织在公有云、私有云和混合云等环境中，构建和运行可以弹性伸缩的应用。

自定义就绪条件:Pod内置Initialized,Ready,ContainersReady,PodScheduled四种条件，在本发明为Pod定义新条件，用来标志是否就绪的状态。自定义就绪条件形式上仅仅是一个约定的字符串，但是要由CRD来定义并声明其约束条件。

Kubelet使用readiness probe(就绪探针)来确定容器是否已经就绪可以接受流量。只有当Pod中的容器都处于就绪状态时kubelet才会认定该Pod处于就绪状态。该信号的作用是控制哪些Pod应该作为service的后端。如果Pod处于非就绪状态，那么它们将会被从service的load balancer中移除。就绪探针目前支持三种就绪检查方式：ExecAction、HTTPGetAction、TCPSocketAction。

ExecAction即使用命令的方式是执行某个进程，根据它的退出码来判断容器是否健康，如果命令执行成功，将返回0，否则返回非0值。

HTTPGetAction是使用HTTP访问预定义的端点，探针向容器中的server的指定端口例如8080发送HTTP GET请求，如果sever的路径通常是/healthz的handler返回一个成功的返回码，kubelet就会认定该容器是健康，如果返回失败的返回码，这个server不会被service调度。任何大于等于200小于400的返回码都会认定是成功的返回码。其他返回码都会被认为是失败的返回码。

TCPSocketAction是kubelet将尝试在指定端口上打开容器的套接字。如果可以建立连接，容器被认为是健康的，如果不能就认为是失败的。

如果应用程序本身不具备就绪检查机制，改造时需要选择实现上述三种就绪检查方式的至少一种。传统应用往往缺少就绪检查手段，例如以war包形式部署在Tomcat中的Javaweb应用，如果Tomcat监听8080端口，无法通过对Tomcat的请求判断web应用是否就绪。如果是基于Springboot的应用，可通过集成Actuator组件可以比较方便的支持就绪检查。Actuator提供health端点，例如：向http://localhost:8080/actuator/health URL发送HttpGet请求，得到status等于UP或者DOWN的响应内容。实际业务中，通过实现HealthIndicators接口来完成对当前应用是否健康的判断，Springboot自动收集上述实现的检查结果。流行的微服务框架SpringCloud就是采用的这种实现。

然而在实际使用中，特别是针对大型应用，情况往往比较复杂。由于K8s中大量采用的异步机制、以及多种对象关系设计上的解耦，当应用实例数增加/删除、或者应用版本发生变化触发滚动升级时，系统并不能保证应用相关的Service、负载均衡器配置总是及时完成刷新。在一些情况下，往往只是新的Pod完成自身初始化，系统尚未完成Endpoint、负载均衡器等外部可达的访问信息刷新，老的Pod就立即被删除，最终造成服务不可用。这对用户来说是不可接受的。

Pod Ready++的引入正是为了修正Pod就绪状态的判断机制——用户可以通过ReadinessGates自定义Pod就绪的条件，当用户自定义的条件以及容器状态都就绪时，kubelet才会标记Pod准备就绪。因此用户可以注入自定义Pod状态，默认为false，然后通过外部控制器配合更新Pod状态，如果外部依赖满足，更新为true，ReadinessGates检测到对应条件类型为true时，Pod变成就绪状态。基于ReadinessGates的依赖检测尚无典型方案。

传统应用框架多种多样，包含一列C、C++、Python等多种语言开发的应用程序。对于应用自身的就绪检查增加HTTP端点和TCP Socket的方式都需要在原有工程上进行开发，涉及到新功能审批，安全性审计，版本变更，开发，测试等一系列流程，成本较高，如果是交付很久的项目可能修改成本会更高。Springboot的Actuator方案是一个基本可用的方案，但是这种实现方式局限于Java环境，依赖Springboot技术。对于依赖的就绪检测一般通过子线程形式不断轮询依赖项，耦合度高。

发明内容

本发明要解决的技术问题是：应用程序(包含传统应用、云原生)部署在云上时，需要应用程序自身提供就绪检查机制，供云平台来确定这个应用程序实例是否可以接受流量。例如，应用程序可能需要在启动期间加载大量数据或配置文件，这种情况下，应用程序可以通过集群就绪探针报告自己还没有准备好，不能处理平台发送过来的流量。标准云原生应用一般可以提供这种就绪检查机制，但是传统应该迁移到Kubernetes集群时，如果应用程序本身不具备就绪检查机制，需要进行相应改造。

本发明提出一种适应传统应用云化的云平台应用就绪检查方法，包括如下步骤：

步骤1：约定应用就绪检查输出标志，并根据该标志的含义编写shell脚本，对标志进行是或者否的判断；

步骤2：通过边车模块自动注入一个边车提供就绪检查功能；

步骤3：使用自定义资源CRD声明自定义就绪条件及判断规则；

步骤4：通过web回调API的Webhook模块自动注入步骤3声明的条件；

步骤5：控制器根据指标收集服务获取的指标不断更新自定义的Pod的就绪条件值。

进一步的，所述的步骤1具体包括：

约定应用就绪检查输出标志，将输出标志true或者false写到日志文件，然后编写一个简单的bash脚本，实现对这个值的判断；边车程序将这个bash脚本执行结果作为一个http端点返回值。

进一步的，所述的步骤2具体包括容器边车程序也以容器的形式注入Pod中，并挂载约定的共享目录，通过这个目录可以读取应用程序日志输出内容做判断，判断结果输出到HTTP端点，以支持HTTPGetAction方式的就绪检查。

进一步的，所述的步骤3具体包括按CRD格式声明自定义就绪条件，包括就绪条件名称，和外部依赖就绪的判断规则。

进一步的，所述的步骤4具体包括应用部署时，触发Webhook模块回调函数，为应用所在Pod注入CRD中声明的就绪检查条件，默认状态为False，控制器模块定时根据从Prometheus收集的指标按约定的规则即判断，ture或者false，并更新这个状态。

进一步的，本发明方案使用从应用的输出例如日志文件中提取标志字符的方式来做应用程序就绪检查，

对于不支持web服务的应用程序，通过在Pod中注入sidecar容器的方式，读取应用程序日志内容做判断，判断结果输出到HTTP端点，默认路径/healthz,低成本实现就绪检查。

判断方法可以传入shell脚本内容实现，端口和路径也支持参数配置。此外，使用ExecAction调用就绪检查子程序，以及使用TcpSocketAction做就绪检查的方式的本发明方案仍然予以完整支持。

进一步的，对于依赖的就绪检测，可在部署文件中声明自定义依赖就绪的条件，然后通过外部控制器，更新部署对象的状态。这种机制相对复杂，但是对业务没有侵入性，在部署对象外部完成对依赖条件的判断，对于微服务架构意义重大。

有益效果：

本发明提供多种手段的就绪检查方式，同时提供外部依赖就绪的检查方案。应用自身的就绪检查改动小，成本低，对于无法提供Http接口的应用，通过部署环节注入一个sidecar容器的形式实现；对外部依赖的就绪检测充分利用Kubernetes的特性例如CRD，Webhook模式和Controller模式对集群进行扩展实现，对业务侵入低。

附图说明

图1：本发明的系统框架图；

图2：本发明的Pod内容器及Volume的逻辑分布图；

图3：本发明中外部依赖就绪检测设计。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整的描述，显然，所描述的实施例仅为本发明的一部分实施例，而不是全部的实施例，基于本发明中的实施例，本领域的普通技术人员在不付出创造性劳动的前提下所获得的所有其他实施例，都属于本发明的保护范围。

下面结合附图1，对本发明的一个实施方式进行说明。

根据本发明的一个实施实例，在本发明中云平台是基础设施资源，可以是公有云，私有云，但需要集成Kubernets容器服务。此外基于Prometheus的指标收集服务也作为依赖服务在云平台上集成。参考附图1，虚线框中就是本发明的就绪检测组件，包括控制器，Webhook模块和边车模块三个模块，边车模块负责为应用配置自身就绪检查条件，并把边车自动注入到部署对象中。Webhook模块负责为部署对象注入自定义的外部就绪检查条件。控制器模块负责实时更新部署对象中自定义就绪检查条件值，这个值由通用的基于Prometheus的指标收集服务来提供。

边车模块本质是通过注入一个边车容器的方法增加一个支持HTTPGetAction方式的就绪检查。实现步骤如下：

步骤1，约定就绪检查规范：在指定的共享路径下输入标志，如果判断健康就输出true，不健康就输出false，并不断循环执行。共享路径采用emptyDir的方案，部署时，声明一个名为healthz的磁盘目录，在应用容器和sidecar容器中分别进行挂载，其中，应用容器挂载点/var/log/app/healthlog就是就绪检查的日志输出位置，在sidecar容器中挂载点/health/status,Pod内的逻辑分布如图2所示。

步骤2,在sidecar容器中运行一个web服务即边车程序，这个服务执行对主程序的健康检查，把结果输出到自定义的HTTP端点/healthz,由于Pod内部网络是共享的，探针可以通过对这个端点发送HTTP GET请求判断Pod是否健康。判断可以由shell脚本来实现，这个脚本内容作为参数传入web服务器。脚本非常灵活，如"find/health/-type f-mmin-0.5-name status|xargs fgrep true"含义是不断在文件/health/status查找标志true，如果查到就通过容器的/healthz端点返回健康，如果文件/health/status超过30s没有更新，文件不会被读取，也认为是不健康的。

本发明的方案仍然支持以命令形式(ExecAction)调用就绪检查子程序，只需要在应用部署文件spec.container部分声明配置的探针的就绪检查子程序名称，参数，间隔和初始延迟等待时间。TCPSocketAction形式类似，只需要在应用部署文件中声明来监听探针的tcp连接请求的端口号，间隔和初始延迟等待时间。

Webhook模块实现把自定义的就绪检查值自动注入到容器内，自定义的就绪检查使用CRD声明自定义的就绪条件。

步骤1，按CRD格式声明自定义就绪条件，CRD一般由两部分组成，一是就绪检查条件名称，二是外部依赖就绪的判断规则。在集成kubernetes的云平台上，Prometheus是通用的指标收集服务组件，Prometheus可以采集外部依赖就绪的指标数据，根据配置的判断规则来进行判断。这里配置一个基于Prometheus规则的判断条件。例如，“www.example.com/feature-1”作为的一个自定义的就绪条件名称；“up{job＝"feature-1"}＝＝1”作为判断条件。

步骤2，部署应用时，Webhook模块为应用所在Pod注入CRD中声明的就绪检查条件名。

步骤3，控制器模块根据CRD中判断规则的结果调用kubernetsPatchAPI更新Pod对应条件的status。逻辑设计如图3所示。

如果判断规则结果值为true，此时Pod的状态将是就绪状态，如果外部依赖异常了，这个值立刻变成false，Pod的状态相应的变为非就绪状态。通过这个方案实现了从应用外部对依赖的就绪检测,并解耦了主程序的外部依赖项。

例如，“www.example.com/feature-1”,status默认为False。控制器模块定时根据从Prometheus收集的指标按约定的规则即“up{job＝"feature-1"}＝＝1”判断，ture或者false，并更新这个status。

尽管上面对本发明说明性的具体实施方式进行了描述，以便于本技术领域的技术人员理解本发明，且应该清楚，本发明不限于具体实施方式的范围，对本技术领域的普通技术人员来讲，只要各种变化在所附的权利要求限定和确定的本发明的精神和范围内，这些变化是显而易见的，一切利用本发明构思的发明创造均在保护之列。

Claims (5)

1.一种适应传统应用云化的云平台应用就绪检查方法，其特征在于，包括如下步骤：

步骤1：约定应用就绪检查输出标志，并根据该标志的含义编写shell脚本，对标志进行是或者否的判断；

步骤2：通过边车模块自动注入一个边车提供就绪检查功能；

步骤3：使用自定义资源CRD声明自定义就绪条件及判断规则；

步骤4：通过web回调API的Webhook模块自动注入步骤3声明的条件；

步骤5：控制器根据指标收集服务获取的指标不断更新自定义的Pod的就绪条件值。

2.根据权利要求1所述的一种适应传统应用云化的云平台应用就绪检查方法，其特征在于，所述的步骤1具体包括：

约定应用就绪检查输出标志，将输出标志true或者false写到日志文件，然后编写一个简单的bash脚本，实现对这个值的判断；边车程序将这个bash脚本执行结果作为一个http端点返回值。

3.根据权利要求1所述的一种适应传统应用云化的云平台应用就绪检查方法，其特征在于：

所述的步骤2具体包括容器边车程序也以容器的形式注入Pod中，并挂载约定的共享目录，通过这个目录可以读取应用程序日志输出内容做判断，判断结果输出到HTTP端点，以支持HTTPGetAction方式的就绪检查。

4.根据权利要求1所述的一种适应传统应用云化的云平台应用就绪检查方法，其特征在于：

所述的步骤3具体包括按CRD格式声明自定义就绪条件，包括就绪条件名称，和外部依赖就绪的判断规则。

5.根据权利要求1所述的一种适应传统应用云化的云平台应用就绪检查方法，其特征在于，

所述的步骤4具体包括应用部署时，触发Webhook模块回调函数，为应用所在Pod注入CRD中声明的就绪检查条件，默认状态为False，控制器模块定时根据从Prometheus收集的指标按约定的规则即判断，ture或者false，并更新这个状态。

Images