视频回顾链接：https://www.bilibili.com/video/BV1Dv411v7P4/

本文整顿自 2020 年 7 月 22 日《基于 Kubernetes 与 OAM 构建对立、标准化的利用治理平台》主题线上网络研讨会。

关注公众号，回复“0722”即可下载 PPT

文章共分为高低两篇。上篇文章《 灵魂拷问，上 Kubernetes 有什么业务价值？》，次要和大家介绍了上 Kubernetes 有什么业务价值，以及什么是“以利用为核心”的 Kubernetes。本文为下篇，将跟大家具体分享如何构建“以利用为核心”的 Kubernetes。

如何构建“以利用为核心”的 Kubernetes？

构建这么一个以用户为核心的 Kubernetes，须要做几个层级的事件。

应用层驱动

首先来看最外围的局部，上图中蓝色局部，也就是 Kubernetes。能够在 Kubernetes 之上定义一组 CRD 和 Controller。能够在 CRD 来做用户这一侧的 API，比如说 pipeline 就是一个 API，利用也是一个 API。像运维侧的扩容策略这些都是能够通过 CRD 的形式装置起来。

应用层形象

所以咱们的须要解决第一个问题是利用形象。如果在 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，这都是能够的。

用户体验层怎么做，齐全取决于用户承受什么样的形式。关键点在于以利用为核心的 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 是一个对立、规范、高可扩大的利用治理平台，可能以利用为核心的全新的 Kubernetes，这是明天探讨的一个重点。OAM 这个我的项目就是撑持这种理念的外围依赖和机制。简略地来说 OAM 可能让你以对立的，标准化的形式去做这件事件。比方标准化定义应用层形象，标准化编写底层利用驱动，标准化治理 K8s 插件能力。

对于平台工程师来说，日常的工作能不能以一个标准化的框架或者依赖让平台工程师更简略更快的做这件事件。这就是 OAM 给平台工程师带来的价值。当然它也有些额定的益处，基于 OAM 裸露进去的新的 API 之后，你下层的 UI 构建起来会非常简单。

你的 OAM 人造分为两类，一类叫做工作负载，一类叫做运维特色。所以你的 UI 这层能够间接去对接了，会缩小很多前端的工作。如果基于 CI/CD 做 GitOps / 继续集成发现也会变得非常简单。因为它把一个利用通过自蕴含的形式给定义进去了，而不是说写很多个 yaml 文件。并且这个文件不仅自蕴含了工作负载，也包含了运维特色。所以创立好了这个文件往 Kubernetes 中提交，这个利用要做金丝雀公布或者是蓝绿公布，流量管制，全副是清清楚楚的定义在这个利用配置文件外面的。因为 GitOps 也好，继续集成也好，是不想管你的 pod 或者是 Deployment 怎么生成的，这个利用怎么运维，怎么 run 起来，还是要靠 Kubernetes 插件或者内置能力去做的。这些能力都被定义到一个自蕴含的文件，实用于所有集群。所以这就会使得你的 GitOps 和继续集成变得简略。

以上就是 OAM 给平台工程师带来的一些特有的价值。简略来说是对立、规范的 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 等技术畛域、聚焦云原生风行技术趋势、云原生大规模的落地实际，做最懂云原生开发者的公众号。”