如何基于K8s构建下一代DevOps平台?

开发 开发工具
OAM是阿里巴巴与微软联合推出的开放应用模型,旨在解耦应用研发、应用运维与基础设施人员在应用生命周期中各自的关注点,明晰责任与界限,聚焦自身业务,同时又依然能紧密协作。当前云原生DevOps体系现状如何?

OAM是阿里巴巴与微软联合推出的开放应用模型,旨在解耦应用研发、应用运维与基础设施人员在应用生命周期中各自的关注点,明晰责任与界限,聚焦自身业务,同时又依然能紧密协作。当前云原生DevOps体系现状如何?面临哪些挑战?如何通过OAM解决云原生DevOps场景下的诸多问题?云原生开发应用模型OAM(Open Application Model)社区核心成员孙健波将为大家一一解答,并分享如何基于OAM和Kubernetes打造无限能力的下一代DevOps平台。

一 什么是DevOps?为什么基于Kubernetes构建?

2009年举办了第一届DevOpsDays大会,DevOps名字被首次提出。到2010年,DevOps的概念越来越火,出了What is DevOps的文章,讲解了DevOps的概念,方法论及配套的工具。简单来说,研发工程师需要和运维工程师深度的合作,同时通过一系列工具保证研发更加顺畅,从而更容易的接触生产环境。到2013年,Docker出现了,工程师可以第一次到软件生产环境中定义,通过Docker image完成单机软件的交付和分发。此时DevOps开始慢慢落地。2015年开始,DevOps相关的工具越来越多,资源利用率出现了一些问题,CNCF的成立使得DevOps的实践往Kubernetes上走。

 

DevOps的三个阶段

阿里在Kubernetes上的实践也取得了非常好的成果。在规模方面,阿里内部集成了数十个节点可以达到上万的集群,同时具备高性能和安全特性,秒级扩容,神龙+安全容器。具备极致的弹性,分钟级拆解公有云计算资源,无限资源池。另一方面,Kubernetes社区已经具备非常丰富的DevOps生态基础功能,包括镜像托管、CI\CD流水线、任务编排、发布策略、镜像打包、分发、丰富的应用运行时的负载支撑、丰富弹性和应用扩容能力。

为什么阿里基于Kubernetes构建DevOps平台?

1)阿里基于Kubernetes的无限资源池与基础设施能力

  • 大规模 – 单集群最高可达10000节点、百万Pod
  • 高性能 – 秒级扩容,智能伸缩,神龙 + 安全容器
  • 极致弹性 – 分钟级拆解公有云计算资源,无限资源池

2)社区围绕Kubernetes已经具备丰富的DevOps生态基础功能

  • 源码到容器镜像仓库,Kubernetes是容器平台事实标准:Github/DockerHub
  • CI/CD流水线、任务编排、发布策略:Argo/Teckton/Spinnaker/Jenkins-X/Flagger
  • 镜像打包、分发:Helm/CNAB
  • 丰富的应用运行负载支撑:Deployment(无状态)/StatefulSet(有状态)/OpenKruise(原生有状态增强)
  • 丰富的弹性和应用扩缩容能力:HPA/KEDA

二 基于Kubernetes的DevOps平台新挑战

下图展示了一个云原生下的DevOps流水线的典型流程。首先是代码的开发,代码托管到Github,再接入单元测试的工具Jenkins,此时基本研发已完成。再接着到镜像的构建,涉及到配置、编排等。云原生中可以用HELM打包应用。打包好的应用部署到各个环境中。但整个过程中会面临很多挑战。首先,在不同的环境需要不同的运维能力。

 

一个云原生 DevOps 流水线的典型流程

其次,配置的过程中要创建云上数据库,需要另外打开一个控制台来创建数据库。还需要配置负载均衡。在应用启动以后还需要配置额外的功能,包括日志、策略、安全防护等等。可以发现,云资源和DevOps平台体验是割裂的,里面充斥着借助外部平台创建的过程。这对新手来说是非常痛苦的。

挑战一:云资源与 DevOps 平台体验割裂

DevOps流程中充斥着大量需要外部平台创建的过程:

 

挑战二:研发、运维、基础设施关注点耦合

下图是常用的K8s的YAML配置文件,大家经常吐槽这个配置文件很复杂。简单来说YAML配置文件可以分为三大块,一块是运维比较关心的配置,包括实例数,策略和发布。第二块是研发关心的,涉及到镜像、端口号等。第三块是基础设施工程师看得懂的,如调度策略等。K8s的配置文件中将方方面面的信息都耦合在一起,这对K8s工程师来说是非常适合的,但是对应用侧的终端工程师而言,有很多不需要关心的配置指标。

 

  • DevOps流程中缺乏对“应用”这个概念的描述
  • K8s 的 YAML文件的定位并不是终端用户

挑战三:平台的自定义封装,简单却能力不足

DevOps平台对K8s能力封装抽象,只剩下5个Deployment的字段需要研发填写。从用户角度而言,这种设置非常好用简单。但是针对稍微复杂的应用,涉及到应用状态管理,健康检查等等一系列的操作,此时这5个字段是不够的。

 

挑战四:CRD 扩展能力强大,DevOps 平台无法直接复用

CRD(Customize Resource Definition)扩展能力强大,几乎所有软件都可以通过CRD的方式进行扩展,包括数据库、存储、安全、编排、依赖管理、发布等。但是对DevOps平台来说,上面接口并没有向用户暴露,导致无法直接复用。

 

挑战五:DevOps 平台开发的新能力使用门槛高

如果平台想要扩展一些能力,而原生的自动扩缩容能力不太合适,希望开发定时的扩缩容YAML文件,随着业务情况而设置。但此时用户使用YAML的门槛非常高,不清楚如何使用YAML。随着新能力开发越来越多,能力之间会出现冲突,这也非常难以管理。

 

CronHPA

  • 运维同学怎么知道这个扩展能力怎么用?
  • 看 CRD?看配置文件?看 …… 文档?
  • 扩展能力间出现冲突,导致线上故障
  • 比如:CronHPA 和 默认 HPA 被同时安装给了同一个应用
  • K8s 扩展能力之间的冲突关系,如何有效管理?如何有效的对运维透出?

挑战六:不同 DevOps 平台需要完全重新对接

很多云原生实践中会遇到的问题,即需要定义非常复杂的YAML,这种方式可以解决企业内部所有问题,但是挑战在于很难与生态进行对接。如RDS,SLB的能力都嵌到YAML文件中,无法复用,几乎不具备原子化能力。同时无法协作,无法提供给兄弟部门或生态使用,只能给内部封闭生态使用。上层系统不同应用对接DevOps平台时,需要写不同格式的YAML,这也是非常痛苦的。

 

  • 难以理解,必须通过界面可视化透出
  • 无法复用,几乎不具备原子化能力
  • 无法协作,只能内部封闭生态使用

三 OAM应用模型的技术原理

Component组件

OAM中常见的概念是Component组件,完全从研发角度定义的待部署单元。下图右侧是YAML中Component的例子,其中黄色部分可以灵活自定义。OAM中会定义标准的架构ContaineriseWorkload,表示工作负载部分,里面是待部署单元的具体描述。这时就可以解决关注点分离的问题,帮助应用侧工程师去掉很多细节,只需要关心开发需要关注的端口号,镜像等等。

 

应对挑战一,在OAM中可以定义数据库表达资源需要使用云资源,Workload中可以根据自己的需要定义不同的组件,包括基于虚拟机的应用、或者老的Function应用。组件是应用开发者关心的。

 

Trait

如果只是组件,组合起来就可以构建简单的应用。如果关心应用运维的问题,OAM中有Trait的概念,指的是在原来组件的基础上附加一些特征。特征指的是运维的能力,如手动扩缩容能力、外部访问能力、发布、负载均衡。弹性扩缩容、基于流量的管理等等。通过OAM的Trait可以很灵活的得到插件化扩充能力。不同的component绑定不同的特征。

 

Scope

Component,Trait以及所有组装起来的Application Configuration就是OAM中的三种主要的概念。但当多个组件共同协作时应该如何处理?OAM中有个边界Scope的概念,是一种特殊的Trait,将多个Component组合在一起,共享一组资源组,CPU等特征用Scope表示,拓展多个组件的共同特征。

 

四 OAM加持下的下一代DevOps技术

OAM:以应用为中心的分层模型

OAM是以应用为中心的分层模型,首先需要运行在服务端的OAM解释器,对于YAML的读取需要通过OAM解释器。OAM提供Trait,Component让用户填写,编成APP Config。APP Config通过OAM解释器具备Deployment,Ingress,HPA或者云资源等能力。这种方法可以将研发、运维基于基础设施进行分层,研发关心Component,运维关心Trait,基础设施通过OAM解释器提供各种能力,与K8s紧密结合,对其应用概念做了补充。

 

  • 分层
  • 模块化
  • 可复用

快速的纳入K8s生态已有Operater能力

OAM可以快速的纳入K8s生态已有的Operater能力,下图左边的Component中是一个CRD的实例,右边是Trait中的CRD的实例,中间表示Component底下的Workload和Trait分别对应了K8s自定义资源的能力。如果想要使用K8s中的某些能力,只需要在Trait中写入相应的字段即可。

 

OAM框架解决组件依赖关系和启动顺序

OAM框架解决组件依赖关系和启动顺序。OAM Runtime,OAM解释器会将组件依赖关系和启动顺序处理好,下图中Component之间有dependency关系,Trait与Component之间有preComponent或者postComponent等关系。

 

OAM Trait灵活解决资源绑定难题

启动顺序厘清之后涉及到资源绑定问题,一边是使用的数据库,另一边是Web的程序,Web的程序绑定数据库连接串资源。在OAM中只需要写一个Trait就可以解决资源绑定问题,下图右边,K8s通过Secret承载连接串信息,Service Binding Trait对应一个运行的Operator,Web Hook拿到Secret后注入进数据库中。

 

Workload与Trait交互机制

大家会考虑接入OAM会不会比较麻烦,需不需要改代码。OAM设计了Workload与Trait交互机制,OAM内部零改造,只需要扩展Workload和Trait。首先,Component中创建Workload实例,再创建Trait实例,只需要在Trait中查看Workload的Definition,从而配置Trait中需要的能力。

 

OAM内核零改造,插件式快速接入新能力

如果开发了新的能力,碰到冲突问题也是非常头痛的。在OAM框架中定义Trait时,可以检查哪些字段是冲突的,拒绝掉新的应用的创建,从而保障Trait之间的兼容性,使得运维问题可发现、可管理。

 

可发现、可管理的 Traits 系统

OAM:无限能力的DevOps平台体系

下图是DevOps平台体系,最下层是OAM Runtime,一部分是Workload,对应运行时的承载的Runtime,如Function、Container、虚拟机、Serverless Service等。另一部分是Trait,对应运维能力,如发布、弹性扩缩容、日志、安全等等。再上一层可以根据场景化组合(Application Profile)组装成不同的业务形态平台,不同平台可以使用不同组合的Workload和Trait,具备不同的能力。通过OAM标准化的模型构建无限能力的DevOps平台,满足各种场景的需要。

 

在用户侧,OAM加持下的研发DevOps流程在镜像构建完成之后使用达到统一,OAM提供了APP Config,包含不同的Component,每个Component包含不同的运维能力Trait,支持不同的环境,如测试环境、生成环境。OAM配置统一,适合不同的云,可以拿到不同的集群中直接运行。在K8s侧,用户只需要装上插件,就可以很方便的嵌入很多丰富的能力。

【本文为51CTO专栏作者“阿里巴巴官方技术”原创稿件,转载请联系原作者】

​戳这里,看该作者更多好文​

 

责任编辑:武晓燕 来源: 51CTO专栏
相关推荐

2021-08-06 09:47:43

架构开发数据集成

2018-09-27 18:47:45

AIOpsDevOps

2018-09-11 08:00:00

DevOpsAIOps机器学习

2013-07-27 21:28:44

2012-11-16 11:31:39

大数据CRM

2015-09-28 16:24:34

YARNHadoop计算

2017-03-08 10:56:03

大数据架构数据湖

2011-12-06 09:48:57

惠普Automomy

2022-07-06 11:38:40

人工智能AI

2013-06-27 11:21:17

2023-11-13 16:25:08

LinuxOS 8

2011-11-03 14:19:15

2020-09-27 17:27:58

边缘计算云计算技术

2014-08-25 09:54:14

移动办公趋势科技

2020-09-16 10:28:54

边缘计算云计算数据中心

2012-05-14 09:39:19

思杰

2013-05-21 13:04:45

云计算网络融合

2013-03-05 09:27:06

Ubuntu桌面QtQML

2009-01-08 09:51:00

IMS多媒体子系统网络融合

2013-09-09 16:28:36

点赞
收藏

51CTO技术栈公众号