简介： 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上走。

阿里在Kubernetes上的实际也获得了十分好的成绩。在规模方面，阿里外部集成了数十个节点能够达到上万的集群，同时具备高性能和平安个性，秒级扩容，神龙+平安容器。具备极致的弹性，分钟级拆解私有云计算资源，有限资源池。另一方面，Kubernetes社区曾经具备十分丰盛的DevOps生态根底性能，包含镜像托管、CICD流水线、工作编排、公布策略、镜像打包、散发、丰盛的利用运行时的负载撑持、丰盛弹性和利用扩容能力。

为什么阿里基于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流程中充斥着大量须要内部平台创立的过程：

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

下图是罕用的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。随着新能力开发越来越多，能力之间会呈现抵触，这也十分难以治理。

  • 运维同学怎么晓得这个扩大能力怎么用？

看 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框架中定义Trait时，能够查看哪些字段是抵触的，回绝掉新的利用的创立，从而保障Trait之间的兼容性，使得运维问题可发现、可治理。

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侧，用户只须要装上插件，就能够很不便的嵌入很多丰盛的能力。