共计 4680 个字符，预计需要花费 12 分钟才能阅读完成。
简介： 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 侧，用户只须要装上插件，就能够很不便的嵌入很多丰盛的能力。
