一 什么是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侧，用户只需要装上插件，就可以很方便的嵌入很多丰富的能力。
