运维开发网

如何实现云上编排系统

运维开发网 https://www.qedev.com 2020-02-16 14:13 出处:网络 作者:CCE华为云
在此希望能与业界一起分享并推动云上编排领域的发展,使得在云的使用过程中能带来更好的用户体验,让云上自动化能真正如云这个趋势一样无处不在。

随着云计算的普及,在云上的自动化需求是必然的结果。那么作为一个优秀的云平台,如何去实现一个可靠且便捷的编排系统呢?本文就跟大家分享并探讨我们这这方面的实践经验。

一个编排系统的核心就是一个工作流引擎,负责分析各个步骤间的依赖关系,并按照DAG(有向无环图)模型来控制这些流程的执行顺序。而云上的编排,更加的具化,就是按依赖顺序创建各个云服务。算法层面,我们可以称每个云服务为元素。创建各种云服务的过程,就是按顺序创建各个元素的过程。

有向无环图DAG

有向无环图(Directed Acyclic Graph, DAG), 是有向图的一种,字面意思的理解就是图中没有环。常常被用来表示事件之间的依赖关系,用于管理任务之间的调度。

一个有向无环图的例子

其中所有节点的拓扑排序是有向无环图中经常需要使用到的算法,我们的系统原型也是按照此理论基础进行实现的。就是把所有元素按照DAG依赖关系确定好谁先谁后的顺序,具体算法大家可以在网上或者资料中搜索获得,这里就不详细介绍了。排好序后,接下里的实现就是先完成底层的元素,再完成上层元素,直到所有元素都初始化完毕。以上就是我们的编排系统模型的理论参照。

编排系统原型

在这里我们假设有一个系统的初始化流程如下:

要实现所有元素按照设定好的顺序创建,我们遵从两个要点:

•默认并行执行。

•无依赖的先执行。

具体算法实现上,我们首先将元素启动顺序分解为有向图,并遍历计算得到每个节点的依赖数。如下:

注:依赖只需要计算临近的节点就可以

遵循之前的两个原则:那么元素B和元素D的依赖数是0,所以这两个元素可以先执行初始化。同时B和D之间无关,可以并行执行。

在任意一个元素执行完之后,所有依赖这些节点的依赖数减一,重新得到所有节点的依赖数:

本次可以执行的元素就是C和F,因为它们的依赖数为0。在这两个元素执行完后,将依赖他们的元素的依赖数减一,重新得到所有节点依赖数:

按照上述的逻辑递归执行,直到所有的元素都被执行完,整个工作流就完成了。它保证整个流程是按顺序用时最短的。从工作流实现原理可知,编排的能力强弱并不强调流程控制,而是编排元素,及编排语法的丰富程度。好的编排系统,可以快速的完成新元素的驱动开发,从而提供新服务的编排能力。

元素间信息传递

如果每个元素初始化,都得记录着其他元素的信息,这种在实现上元素间就很耦合。为了保持每个元素在执行时候的独立性(即当前元素在初始化时,不用去了解其他元素的信息),主体框架需要保持一个全局信息,然后在初始化一个元素的时候,把这个元素需要的信息告诉它就行。它自己完全不知道还有哪些其他元素,反正它自己需要的信息都有了。

这里举例说明,调度框架维护一个全局信息,记录每个元素需要哪些参数才能初始化。上图绿色的需要用户提供,红色的则在被依赖对象创建后自动获得。比如创建VM需要VPC的ID,那么在VPC创建后,VPC的ID就知道了,这个字段不用用户提供。

所以在元素D初始化完成后,元素C就可以开始初始化了。这个时候,所有创建C的参数,都应该是确认的值。在调用C服务的初始化API的时候,不缺任何信息。这样在实现C的创建API和销毁API,就非常独立,只与C服务本身打交道。

在开发新服务的时候,只需要了解新服务自身就可以了,所有想要的信息(可以直接要求用户提供,或者通过依赖获得),都会通过框架管理和传递。

这就是我们的插件化框架,这个框架使得新增一种服务非常容易,因为服务的驱动开发是完全独立的。

插件设计

1、元素的生命周期

每一种云服务对象,在编排系统看来都是一个元素。新增一种元素的编排,就需要该元素提供增删改查等基础执行能力。编排系统的插件管理框架会根据用户执行动作,比如创建or销毁,来调用元素对应的API。

有了上一节的元素执行流程框架后,新增一个编排对象,只需要完成该元素的各种行为驱动就可以。例如:只要有创建和销毁VM的方法(API),那么就可以在编排元素里面增加一个EC2服务,就可以在模板里面增加这种元素的编排了。调度框架只是把它当做一个普通元素来对待。

2、用户自定义插件

基于插件框架每个元素驱动独立的优势,同时考虑到Kubernetes中的Resource对象也有自定义扩展特性(custom resource definition),可以设计一种元素插件支持用户定义自己的K8S编排对象的能力。即把用户提供的“信息”原封不动的传递给底层API。由底层系统去解释用户的“信息”。编排系统退化为只负责流程控制+信息传递通道。

3、操作的等待&进度

之前提过,有些云服务的操作非常耗时,如果不能提供整体进度的直观反馈,用户体验就会非常的差,以为整个执行流程挂死。所以在元素驱动的编写时,必须考虑进度和等待反馈,让编排框架能感知执行进度。使得用户可以知道当前在执行哪个元素,该元素的执行进度如何。从而确保整体的编排流程能够给用户最直接和友好的反映。

TOSCA模型

有了调度框架&插件框架,剩下的就是配置文件的语法了,目前主要的可借鉴语法就是AWS的Cloudformation和TOSCA语法。其中AWS-CFN是以资源初始化为中心的,而TOSCA的定义为TOSCA is a specification that aims to standardize how we describe software applications and everything that is required for them to run in the “cloud”,可见TOSCA是更加偏向于面向App的。

鉴于容器技术的流行,越来越多的应用以独立容器出现,不再强调需要传统的VM。我们觉得模板语法使用TOSCA是个不错的选择。

实际上,在自动化的过程中,你会发现:模板的语法并不是关键点。只要能自动化,模板写出来都不会相差太大,所以关键还是看自动化能力。这个就好比编程语言的选择,Java和Go,写二叉树遍历不会在意是用for还是用while。各种编程语言的主要区别在内置函数/库上,所以在模板的语法上提供丰富的自动化便利性才是目的。这一点需要向AWS学习,它提供了很多的内置函数。

在云上,自动化其实是刚需,只有完成了自动化这个基座,才能构建出完整的云生态。而编排作为一种高级自动化能力,需要负起推动云生态走向完整的重任。是检验一个云厂商实力的硬通货。

华为PaaS团队在云上,特别是PaaS云上的自动化&编排领域,有多年的探索和积累。在此希望能与业界一起分享并推动云上编排领域的发展,使得在云的使用过程中能带来更好的用户体验,让云上自动化能真正如云这个趋势一样无处不在。

如果有好的想法&建议,留言跟我们交流。添加weiixn群助手monicka,加入容器技术实战交流群,更多群福利等着你

0

精彩评论

暂无评论...
验证码 换一张
取 消