视频回顾连接：https://www.bilibili.com/video/BV1Dv411v7P4/前端
本文整理自 2020 年 7 月 22 日《基于 Kubernetes 与 OAM 构建统1、标准化的应用管理平台》主题线上网络研讨会。python
关注公众号，回复 “0722” 便可下载 PPTredis
文章共分为上下两篇。上篇文章《灵魂拷问，上 Kubernetes 有什么业务价值？》，主要和你们介绍了上 Kubernetes 有什么业务价值，以及什么是“以应用为中心”的 Kubernetes。本文为下篇，将跟你们具体分享如何构建“以应用为中心”的 Kubernetes。docker
如何构建“以应用为中心”的 Kubernetes？
构建这么一个以用户为中心的 Kubernetes，须要作几个层级的事情。json
应用层驱动
首先来看最核心的部分，上图中蓝色部分，也就是 Kubernetes。能够在 Kubernetes 之上定义一组 CRD 和 Controller。能够在 CRD 来作用户这一侧的 API，好比说 pipeline 就是一个 API，应用也是一个 API。像运维侧的扩容策略这些都是能够经过 CRD 的方式安装起来。 api
##应用层抽象
因此咱们的须要解决第一个问题是应用抽象。若是在 Kubernetes 去作应用层抽象，就等同于定义 CRD 和 Controller，因此 Controller 能够叫作应用层的抽象。自己能够是社区里的，好比 Tekton，istio 这些，能够做为你的应用驱动层。这是第一个问题，解决的是抽象的问题。不是特别难。网络
插件能力管理
不少功能不是 K8s 提供的，内置的 Controller 仍是有限的，大部分能力来自于社区或者是本身开发的 Controller。这时个人集群里面就会安装好多好多插件。若是要构建以应用为中心的 Kubernetes，那我必须可以管理起来这些能力，不然整个集群就会脱管了。用户想要这么一个能力，我须要告诉他有或者是没有。须要暴露出一个 API 来告诉他，集群是否有他须要的能力。假设须要 istio 的流量切分，须要有个接口告诉用户这个能力存不存在。不能期望用户去 get 一下 crd 合不合适，检查 Controller 是否运行。这不叫以应用为中心的 K8s，这叫裸 K8s。架构
因此必须有个能力，叫作插件能力管理。若是我装了 Tekton，kEDA，istio 这些组件，我必须将这些组件注册到能力注册中心，让用户可以发现这些能力，查询这些能力。这叫作：插件能力管理。 框架
用户体验层
有了应用层驱动，应用层抽象，插件能力管理，咱们才能更好地去考虑，如何给用户暴露一个友好的 API 或者是界面出来。 有这么几种方式，好比CLI客户端命令行工具，或者是一个 Dashboard，又或者是研发侧的 Docker Compose。或者可让用户写代码，用 python 或者 go 等实现 DSL，这都是能够的。less
用户体验层怎么作，彻底取决于用户接受什么样的方式。关键点在于以应用为中心的 Kubernetes，UI 层就能够很是方便的基于应用层抽象去作。好比 CLI 就能够直接建立一个流水线和应用，而不是兜兜转转去建立 Deployment 和 Pod，这两个的衔接方式是彻底不同的。pipeline 只须要生成一下就结束了。而后去把 Pod 和 Deployment 组成一个 Pipeline，那这个工做就很是繁琐了。这是很是重要的一点，当你有了应用层驱动，应用层抽象，插件能力管理，再去构建用户体验层就会很是很是简单。
Open Application Model(OAM)
若是想构建一个应用为中心的 Kubernetes，有没有一个标准化的、简单的方案呢？
下面就要为你们介绍：Open Application Model(OAM)。
OAM 的本质是帮助你构建一个“以应用为中心“的 Kubernetes 标准规范和框架，相比较前面的方案，OAM 专一于作这三个层次。
应用组件 Components
第一个叫作应用层抽象，OAM 对用户暴露出本身定义的应用层抽象，第一个抽象叫作 Components。Components 其实是帮助咱们定义 Deployment、StatefulSet 这样的 Workload 的。暴露给用户，让他去定义这些应用的语义。
应用特征 Traits
第二个叫作应用特征，叫作 Traits。运维侧的概念，好比扩容策略，发布策略，这些策略经过一个叫作 Traits 的 API 暴露给用户。首先 OAM 给你作了一个应用层定义抽象的方式，分别叫作 Components 和 Traits。因为你须要将 Traits 应用特征关联给应用组件 Components，例如 Deployment 须要某种扩容策略或者是发布策略，怎么把他们关联在一块儿呢？
应用配置 Application Configuration
这个就须要第三种配置叫作 Application Configuration 应用配置。最终这些概念和配置都会变成 CRD，若是你的 K8s 里面安装了 OAM 的 Kubernetes Runtime 组件，那么那就能解析你 CRD 定义的策略和 Workload，最终去交给 K8s 去执行运行起来。就这么一个组件帮助你更好地去定义抽象应用层，提供了几个标准化的方法。
能力定义对象 Definitions
这些抽象和能力交给 K8s 去处理以后，我这些能力须要的 Controller 插件在哪？有没有 Ready？这些版本是否是已经有了，能不能自动去安装。这是第四个能力了：能力定义对象。这是 OAM 提供的最后一个 API，经过这个 API 能够本身去注册 K8s 全部插件，好比 Tekton、KEDA、istio 等。
把它注册为组件的一个能力，或者是某一个特征。好比说 Flager，能够把它注册为金丝雀发布的能力，用户只要发现这个发布策略存在，说明这个集群支持 Flager，那么他就能够去使用。这就是一个以应用为中心的一个玩法。以用户侧为出发点，而不是以集群侧为出发点，用户侧经过一个上层的 api，特征和组件来去了解他的系统，去操做他的系统。以上就是 OAM 提供的策略和方法。
总结下来就是 OAM 能够经过标准化的方式帮助平台构建者或者开发者去定义用户侧，应用侧的抽象。第二点是提供了插件化能力注册于管理机制。而且有了这些抽象和机制以后，能够很是方便的构建可扩展的 UI 层。这就是 OAM 最核心的功能和价值。
OAM会怎样给用户提供一个API呢？
Components
Component 是工做负载的版本化定义，例如上图中建立一个 Component，实际上就是建立一个 Deployment。这样一个 Component 交给 K8s 以后，首先会建立一个 Component 来管理这个 Workload，当你修改 Component 以后就会生成一个对应版本的 deployment。这个 Component 其实是 Deployment 的一个模板。好比我把 image 的版本修改一下，这个操做就会触发 OAM 插件，生成一个新的版本的 Deployment，这是第一个点。其实就版本化管理机制去管理 Component。
第二点是 Workload 部分彻底是自定义的，或者是是可插拔的。
今天能够定义为 Deployment，明天能够定义为一个很是简单的版本。也就是说我 Components 的抽象程度彻底取决于用户本身决定的。后期也能够改为 Knative Service，甚至改为一个 Open PaaS。因此说在 Components 的 Workload 部分你能够自由的去定义本身的抽象。只要你提早安装了对应 CRD 便可，这是一个很是高级的玩法。
此外在 OAM 中，”云服务“也是一种 Workload， 只要你能用 CRD 定义你的云服务，就能够直接在 OAM 中定义为一个应用所依赖的组件。好比上图中的redis其实是阿里云的 Redis 服务，大概是这么一个玩法。
Trait 和 Application Configuration
首先 Trait 是声明式运维能力的描述，其实就是 Kubernetes API 对象。任何管理和运维 Workload 的组件和能力，均可以以这种 CER 的方式定义为一个 Trait。因此像 HPA，API gateway，istio 里面的 Virtual Services 都是 Trait。
Application Configuration 就像是一个信封，将 Traits 绑定给 Component，这个是显式绑定的。OAM 里面不建议去使用 Label 这样的松耦合的方式去关联你的工做负载。建议经过这种结构化的方式，经过 CRD 去显式的绑定你的特征和工做负载。这样的好处是个人绑定关系是可管理的。能够经过 kubectl get 看到这个绑定关系。做为管理员或者用户，就很是容易的看到某一个组件绑定的全部运维能力有哪些，这是能够直接展现出来的，若是经过 label 是很难作到的。同时 Label 自己有个问题是，自己不是版本化的，不是结构体，很难去升级，很难去扩展。经过这么结构化定义，后面的升级扩展将会变得很是简单。
在一个用户配置里面，能够关联多个 Components。它认为一个应用运行所须要的全部组件和所依赖的运维能力，都应该定义为一个文件叫作 ApplicationConfiguration。因此在任何环境，只要拥有这个文件，提交以后，这个应用就会生效了。OAM 是但愿可以提供一个自包含的应用声明方式。
Definition Object
除此以外，还提到了对应管理员提供了 Definition Object，这是用来注册和发现插件化能力的 API 对象。
好比我想讲 Knative Service 定义为平台支持的一种工做负载，如上图只须要简单的写一个文件便可。其中在 definitionRef 中引用 service.serving.knative.dev 便可。这样的好处就是能够直接用 kubectl get Workload 查看 Knative Service 的 Workload。因此这是一个用来注册和发现插件化能力的机制，使得用户很是简单的看到系统中当前有没有一个工做负载叫作 Knative Service。而不是让用户去看 CRD，看插件是否安装，看 Controller 是否 running，这是很是麻烦的一件事情。因此必须有这么一个插件注册和发现机制。
这一部分还有其余额外的能力，能够注册 Trait，而且容许注册的 Trait-A 和 Trait-B 是冲突的。这个信息也能带进去，这样部署的时候检查到 A 和 B 是冲突的，会产生报错信息。不然部署下去结果什么都不知道，两个能力是冲突的，赶忙删了回滚从新建立。OAM 在注册的时候就会暴露出来运维能力的冲突，这也是靠 Definition 去作的。
除此以外，OAM 的 model 这层其余的一些附加能力，可以让你定义更为复杂的应用。
总结
前面咱们提到不少企业等等都在基于 Kubernetes 去构建一个上层应用管理平台。Kubernetes 其实是面向平台开发者，而不是面向研发和应用运维的这么一个项目。它天生就是这么设计的，因此说须要基于 Kubernetes 去构建应用管理平台。去更好的服务研发和运维，这也是一个很是天然的选择。不是说必须使用 K8s 去服务你的用户。若是你的用户都是 K8s 专家，这是没问题的。若是不是的话，你去作这样一个应用平台是很是天然的事情。
可是咱们不想在 K8s 以前架一个像 Cloud Foundry 传统的 PaaS。由于它会把 K8s 的能力彻底遮住。它有本身的一套 API，本身的理念，本身的模型，本身的使用方式。跟 Kubernetes 都是不太同样的，很难把 Kubernetes 的能力给暴露出去。这是经典 PaaS 的一个用法，可是咱们不想要这么一个理念。咱们的目标是既能给用户提供一个使用体验，同时又能把 Kubernetes 的能力所有发挥出来。而且使用体验跟 Kubernetes 是彻底一致的。OAM 本质上要作的是面向开发和运维的，或者说是面向以应用为中心的 Kubernetes。
因此今天所介绍的 OAM 是一个统1、标准、高可扩展的应用管理平台，可以以应用为中心的全新的 Kubernetes，这是今天讨论的一个重点。OAM 这个项目就是支撑这种理念的核心依赖和机制。简单地来讲 OAM 可以让你以统一的，标准化的方式去作这件事情。好比标准化定义应用层抽象，标准化编写底层应用驱动，标准化管理 K8s 插件能力。
对于平台工程师来讲，平常的工做能不能以一个标准化的框架或者依赖让平台工程师更简单更快的作这件事情。这就是 OAM 给平台工程师带来的价值。固然它也有些额外的好处，基于 OAM 暴露出来的新的 API 以后，你上层的UI构建起来会很是简单。
你的 OAM 自然分为两类，一类叫作工做负载，一类叫作运维特征。因此你的 UI 这层能够直接去对接了，会减小不少前端的工做。若是基于 CI/CD 作 GitOps / 持续集成发现也会变得很是简单。由于它把一个应用经过自包含的方式给定义出来了，而不是说写不少个 yaml 文件。而且这个文件不只自包含了工做负载，也包括了运维特征。因此建立好了这个文件往 Kubernetes 中提交，这个应用要作金丝雀发布或者是蓝绿发布，流量控制，所有是清清楚楚的定义在这个应用配置文件里面的。由于 GitOps 也好，持续集成也好，是不想管你的 pod 或者是 Deployment 怎么生成的，这个应用怎么运维，怎么 run 起来，仍是要靠 Kubernetes 插件或者内置能力去作的。这些能力都被定义到一个自包含的文件，适用于全部集群。因此这就会使得你的 GitOps 和持续集成变得简单。
以上就是 OAM 给平台工程师带来的一些特有的价值。简单来讲是统1、标准的 API，区分研发和运维策略，让你的 UI 和 GitOps 特别容易去构建。另外一点是向下提供了高可扩展的管理 K8s 插件能力。这样的系统真正作到了标准，自运维，一个以应用为中心和用户为中心的 Kubernetes 平台。
OAM 社区
上面最后但愿你们踊跃加入 OAM 社区，参与讨论。上图中有钉钉群二维码，目前人数有几千人，讨论很是激烈，咱们会在里面讨论 GitOps，CI/CD，构建 OAM 平台等等。OAM 也有亚太地区的周会，你们能够去参加。上面的连接是开源项目地址，将这个安装到 Kubernetes 中就可使用上面咱们说的这些能力了。
QA环节
Q1：例子中提问到了 Function 的例子，是否能够理解为 Serverless 或者是 PaaS？
A1：这样理解是没错的，能够理解为阿里云的一个 Function，或者是 Knative Service。
Q2：有没有可让我自由定义出相应的规则这种规范？
A2：有的，在 OAM 里面有个规范，叫作 spec。spec 里面有提交容器化的规范。后面会增长更多抽象的规范。固然也分类别，有一些是很是标准化的，须要严格遵照。有一些是比较松的，能够不用严格遵照。
Q3：docker-compose 的例子能否再谈谈？
A3：本次 ppt 中没有 docker-compose 的例子，可是这个其实很容易去理解，由于 OAM 将 Kubernetes API 分为两类，一个叫作 Components，一个叫T raits。有这么一个 Componets 文件，就能够直接映射 OAM 的概念，docker-compose 中有个概念叫作 Service，其实就是对应了 OAM 中的 Component。这彻底是一对一对应关系。Service 下面有个 Deployment，有个部署策略，其实对应的就是 OAM 的 Trait。
Q4：定义阿里云的 redis 是否已经实现了？
A4：已经实现了，可是功能有限。内部已经实现了一个更强大的功能，经过 OAM 将阿里云的全部资源给建立起来。目前这个是在 Crossplane 去作的。可是内部更完整的实现尚未彻底的放出去。咱们还在规划中，但愿经过一个叫作 Alibaba Opreator 的方式暴露出去。
Q5：是否能够理解 OAM 经过管理元数据经过编写 CRD 来打包 Components 和 Traits。
A5：能够说是对的。你把本身的 CRD 也好，社区里面的 CRD 也好，稍微作个分类或者封装，暴露给用户。因此对于用户来讲只要理解两个概念——Components 和 Traits。Components 里面的内容是靠你的 CRD 来决定的，因此说这是一个比较轻量级的抽象。
Q6：假设 Components 有四个，Traits 有五个，是否能够理解为可封装能力有 20 项。
A6：这个不是这么算的，无论有多少 Components 和 Trait，最终有几个能力取决于你注册的实际 CRD。Components 和 Traits 与背后的能力是解耦开的。
Q7：OAM 能使用 Kustomize 生成么？
A7：固然能够了，Kustomize 使一个 yaml 文件操做工具。你能够用这个工具生成任何你想要的 yaml 文件，你也能够用其余的，好比 google 的另外一个项目叫 kpt，好比你用 DSL，json。全部能够操做 yaml 文件的工具均可以操做 OAM 文件，OAM 的 yaml 文件跟正常的 K8s 中的 yaml 没有任何区别。在 K8s 看来 OAM 无非就是一个 CRD。
Q8：OAM 是否能够生产可用？
A8：这里面分几个点，OAM 自己分两个部分。第一部分是规范，是处于 alpha 版本，计划在 2020 年内发布 beta 版本。beta 就是一个稳定版本，这是一个比较明确的计划。如今的 spec 是有可能会变的，可是有另一个版本叫作 oam-kubernetes-runtime 插件，这是做为独立项目去运营的，计划在 Q3 发布稳定版本。即便个人 spec 发生的改变，可是插件会作向下兼容，保证 spec 变化不会影响你的系统，咱们的 runtime 会提早发布稳定版本，应该是比较快的。若是构建平台化建议优先使用 runtime。
Q9：OAM 有没有稳定性考虑？好比说高可用。
A9：这个是有的，目前 runtime 这个项目就在作不少稳定性的东西，这是阿里内部和微软内部的一个诉求。这块都是在作，确定是有这方面考虑的，包括边界条件的一个覆盖。
Q10：可不可介绍下双十一的状态下，有多少个 Pod 在支持？
A10：这个数量会比较大，大概在十几万这样一个规模，应用容器数也是不少的。这个对你们的参考价值不是很大，由于阿里的架构和应用跟大多数同窗看到的是不太同样的，大多数是个单元化的框架，每一个应用拆分的微服务很是很是细。pod 数和容器数都是很是多的。
Q11：目前 OAM 只有阿里和微软，之后像 google 这些大厂会加入么？
A11：必定会的，接下来的计划会引入新的合做方。目前 google 和 aws 都对 OAM 有一些社区的支持。自己做为云原生的一个规范，也是有一些想法的。在初期的时候，大厂加入的速度会比较慢，更但愿的是用户使用起来。大厂并不必定是 OAM 的主要用户，他们更多的是商业考虑。
Q12：OAM 是否会关联 Mesh？
A12：必定会的，可是并非说直接 Mesh 一个核心能力，更多的说做为 OAM trait 使用,好比描述一个流量的拓扑关系。
Q13：OAM 的高可用方案？
A13：OAM 自己就是个无状态服务，自己的高可用方案不是很复杂。
Q14：OAM 考虑是单集群仍是多集群？
A14：目前是单集群，可是咱们立刻也会发布多集群的模型，在阿里内部已是多集群模型。简单来讲多集群是两层模型。多集群的概念是定义在 Scope 里面的，经过 Scope 来决定 Workload 或者是 Components 放到哪一个集群里面。咱们会在社区尽快放出来。
若是有其余问题，建议你们加入咱们的钉钉群进行讨论。（钉钉搜索群号：23310022，便可进群）
“阿里巴巴云原生关注微服务、Serverless、容器、Service Mesh 等技术领域、聚焦云原生流行技术趋势、云原生大规模的落地实践，作最懂云原生开发者的公众号。”