一种声明式的通用Kubernetes调谐方法

本发明涉及云计算领域应用的自动化运维，具体是一种声明式的通用kubernetes调谐方法，属于自动化运维技术领域。

背景技术：

随着云应用和平台的复杂性增加，需要同时支持数百甚至数千的应用程序，传统的自动化方法，如使用特制的、指令式的脚本，被证明是难以管理和扩展的。相反，最近越来越流行的自动化工具旨在遵循基础设施即代码（infrastructureascode，iac）原则。根据这一原则，基础设施和核心服务的整体配置和状态要用（典型的声明性）代码来定义。然后，借助相关工具，这个刻画了期望状态定义的代码，可以自动转换为正确的指令和api调用，从而产生完全符合期望状态的配置资源。这种将期望状态的定义与实际状态同步的过程被称为状态调谐，一些现代的基础设施和云计算自动化工具都采用了这种方法，其中最受欢迎的是terraform和基于容器的平台kubernetes。

kubernetes已经开始被广泛应用于基础设施自动化和状态调谐的使用场景。它是目前最受欢迎的管理基于容器的应用程序的平台，它从一开始就围绕着状态调谐的概念设计。整个架构可以被认为是一个各个模块通过共享状态存储协作的调谐循环系统。此外，可扩展性是kubernetes设计中的一个核心方面。通过结合这两个特点，kubernetes也被用作一个通用的状态调谐引擎，能够调谐定制的、特定于应用程序的资源和状态。为了利用这些功能，应用程序需要正确有效地处理与kubernetesapi的通信和集成，这些并不是简单的工作。

开发人员可以通过operator来拓展kubernetes的声明式api，这也是最常用的方式。operator是对kubernetes的软件拓展，帮助实现应用程序的自动化部署、升级、管理以及运维。一个operator是自定义资源定义（customresourcedefinition）和自定义控制器的组合，自定义控制器实现了自定义调谐。然而，编写一个operator并不容易，具有相当高的门槛，并且需要付出大量的精力和时间。operator开发人员需要具备一定程度的kubernetes和分布式系统知识，需要写大量的模版代码或者使用代码生成工具。编写出的operator帮助我们实现了应用程序的自动化运维，但是维护这个operator却还是要给开发人员带来很大的负担。因此诞生了很多工具，它们都希望帮助开发人员更简单的实现自己的operator，但它们都带来了新的问题或者有很大的局限性。

技术实现要素：

发明目的：现有的基于自定义调谐的自动化运维方法需要开发运维人员把大量的精力放在编写一些模版代码或者使用代码生成工具上，需要学习kubernetesapi相关的知识，而且operator的成熟开发工具都是用go编写的，也是为go项目服务的，对其他编程语言的使用者极不友好。本发明针对现有的自动化运维方法的不足和的operator调谐具备固定范式的特点，提出一种声明式的通用kubernetes调谐方法，通过实现一个通用控制器，负责所有自定义控制器必须做的一般操作，管理所有与kubernetesapi的交互，开发者只需要提供一个包含特定调谐逻辑的函数，大幅度简化了自定义控制器的开发、部署和管理。

技术方案：一种声明式的通用kubernetes调谐方法，包括以下内容：

（1）声明式的监视：

用户在配置文件中简单地列出想监视的资源的声明，为所述资源自动创建相应的的监视流；监视流被所有通过配置文件创建的自定义控制器共享，可以创建任意多的自定义控制器来观察同一种资源，而kubernetes的api服务器只需要发送一个资源监视流。

（2）声明式的调谐

用户提交新的配置文件后，根据所述配置文件启动新的自定义控制器，自定义控制器执行调谐循环，在每次调谐过程中调用用户在配置文件中指定的调谐接口，在kubernetes系统中应用返回的调谐结果，每次调谐使用以下步骤对kubernetes系统进行调谐以向期望状态收敛：

步骤1，收集当前系统中与正在处理的资源对象相关的信息；

步骤2，将这些信息整理后发送到用户指定的调谐接口，等待调谐结果；

步骤3，将调谐结果描述的期望存在的资源与当前集群中已经存在的资源做比对，将二者合并得到目标状态；

步骤4，对目标状态中还不存在的资源，创建它，对于已经存在但与目标状态不一致的资源，用配置文件中指定的更新策略更新它；等待一段调谐间隔时间后，重复步骤1-4。

步骤1中收集的相关信息包括3种：

①该资源本身，即父资源，通过触发本次调谐的消息中的信息向kubernetes的api服务器发送请求检索得到该资源；

②子资源们，通过标签选择器筛选出配置文件中指定类型的子资源；

③相关资源们，根据用户在自定义接口中指定的筛选条件和类型找到的资源。

所述步骤2中的调谐接口，由用户自己定义，可以用任意一种编程语言实现，完成两个翻译过程：

①根据用户配置文件中描述的期望状态对集群进行操作，编排一些kubernetes原生资源，来完成某个应用的部署、管理与维护；

②根据集群的当前状态中用户关心的部分，设置用户自定义资源的状态字段，供客户端查看。

（3）声明式的更新策略

内置很多更新策略供用户选择，用户在配置文件中指定资源选用的更新策略，自动按照所述更新策略完成更新相关操作，支持滚动更新。

有益效果：与现有技术相比，本发明具有以下优点：

（1）实现所有自定义控制器的一般操作，负责所有与kubernetesapi的交互，大量减少了operator开发者编写模版代码或者使用代码生成工具的负担，帮助开发者将精力集中在核心的调谐逻辑上；

（2）通过对kubernetes声明式api的扩展，提供了声明式接口，封装了编写自定义控制器的常见部分，让用户不需要编写任何与kubernetes交互的代码，只需要在配置文件中描述需要监听的资源、使用的更新策略以及在调谐代码段中描述期望的状态即可；

（3）本发明的方法在实现时充分考虑kubernetes中自定义控制器可能的需求和行为，提供了获取额外系统状态信息的接口，多种更新策略以便适用于多种多样的情况；

（4）本发明的方法通过网络请求的方式调用用户提供的自定义调谐接口。这个接口只需要提供一个包含控制器特定调谐逻辑函数，并被部署成一个网络服务，信息的传递都采用json的形式，所以这个接口可以使用任意主流的编程语言开发实现。用户编写的调谐逻辑也只需要简单的描述期望的状态，不需要去做任何实际的操作，极大的简化了代码的编写。

附图说明

图1为通用调谐系统整体示意图，包括配置文件、通用控制器、用户自定义调谐逻辑等模块；

图2为本发明方法通用控制器中每一轮调谐的示意图；

图3为本发明方法的一个简单调谐逻辑实例。

具体实施方式

下面结合具体实施例，进一步阐明本发明，应理解这些实施例仅用于说明本发明而不用于限制本发明的范围，在阅读了本发明之后，本领域技术人员对本发明的各种等价形式的修改均落于本申请所附权利要求所限定的范围。

一种声明式的通用kubernetes调谐方法，包括以下内容：

（1）声明式的监视：

用户在配置文件中简单地列出想监视的资源的声明，为所述资源自动创建相应的监视流；

（2）声明式的调谐

调用用户提供并在配置文件中指定的调谐接口，所述调谐接口只需要提供期望存在的资源，所述调谐接口返回的调谐结果会被自动应用在系统中；

（3）声明式的更新策略

提供多种更新策略供用户选择，用户在配置文件中指定资源选用的更新策略，自动按照所述更新策略完成更新相关操作，支持滚动更新。

所谓声明式的监视，具体包括：

（1）在配置文件中指定父资源资源类型，父资源类型只能有一个，是用户通过配置文件定义的自定义控制器需要管理的资源，也是用于描述期望状态的资源，通用控制器会自动对该资源启动监视流；

（2）在配置文件中指定子资源类型，子资源类型可以有一个或多个，是自定义控制器期望存在的资源的类型，子资源们协作以达到期望状态，通用控制器会对每个类型的子资源启动监视流。

对于图3所展示的调谐，父资源类型是foo、子资源类型只有一个，是deployment，当在通用控制器中实现这样的调谐时，用户只需要在配置文件中列出foo和deployment的类型信息即可，不需要自己去写启动监视流的代码。

对于声明式的调谐，具体解释如下：

用户提交新的配置文件后，得到了新的自定义控制器，通用控制器启动新的自定义控制器，处理所有与kubernetesapi的交互，运行调谐循环，在每次调谐过程中调用用户在配置文件中指定的接口，发送描述期望状态和当前状态的资源，返回的调谐结果中定义了期望存在的资源，在服务端应用调谐结果。

在本实施例中，一次调谐的简单模型如图2所示，包括如下步骤：

步骤1，收集当前状态中与正在处理的资源对象相关的信息；

步骤2，将这些信息整理成调谐请求和调谐上下文，发送到用户指定的调谐接口，等待调谐结果，调谐结果是一组期望存在的资源；

步骤3，将调谐结果描述的期望状态与当前集群实际状态做比对，将二者合并得到目标状态；

步骤4，对目标状态中还不存在的资源，创建它，对于已经存在但与目标状态不一致的资源，用配置文件中指定的更新策略更新它后；等待一段调谐间隔时间后，重复步骤1-4。

在本实例中，调谐接口中的调谐逻辑如图3所示，包括两个翻译过程：

（1）根据用户配置文件中描述的期望状态对集群进行操作，编排一些kubernetes原生资源，来完成某个应用（例如数据库）的部署、管理与维护；

（2）根据集群的当前状态中用户关心的部分，设置用户自定义资源的状态字段，供客户端查看。

负责管理的自定义资源是foo，它的spec中只有两个字段deploymentname和replicas，代表期望生成的deployment资源的名称和指定的副本数量，它的status中只有一个字段availablereplicas，代表集群中实际可用的副本数量。根据当前集群中实际的deployment的status中的availablereplicas字段可以得知可用的副本数量此刻为0，所以foo的status的availablereplicas字段的值也要设置为0，这就是第一个翻译过程。而根据这个foo的deploymentname和replicas会去生成一个名称为example-foo，副本数量为1的deployment，这就是第二个翻译过程。

对于声明式的更新策略，具体解释如下：

通用控制器内置了很多更新策略，通过声明式接口供用户使用，用户在配置文件中指定即可选择。

更新资源的策略包括5种：

（1）待删除后更新，不更新现有的子资源，直到子资源被其他的客户端删除；

（2）立刻重建，立即删除任何不符合期望状态的子资源，并根据状态中的信息重新创建；

（3）就地更新，立刻就地更新任何不符合期望状态的子资源；

（4）滚动重建，每次调谐删除一个与期望状态不同的子资源，并在处理下一个子资源之前根据期望状态中的信息重新创建子资源；在任意时刻，如果已经更新的子资源中有一个或多个状态检查失败，则暂停滚动更新；

（5）滚动就地更新，每次更新一个不符合期望状态的子资源。如果已经更新的子资源中有一个或多个状态检查失败，则暂停滚动更新。

不同的资源适合不同的更新策略，例如pod一般会用重新创建，因为当一个pod已经在kubernetes中存在，它能修改的只有metadata中的标签和附加说明，spec中的字段都不能修改，如果需要修改，就只能删除重建。而deployment除了名字和命名空间都可以修改，直接更新原资源即可。

综上所述，使用本发明提供的方法，能够有效简化kubernetesoperator的开发实现，帮助解决kubernetes的自动化应用部署、管理与维护问题。本发明针对kubernetes中的自定义调谐，封装了编写自定义控制器的常见部分，相比现有方法能够极大提升自定义调谐的开发速度并降低运维难度。因此，本方法有较高的应用价值。