共计 7622 个字符，预计需要花费 20 分钟才能阅读完成。
简介：如果你对云原生畛域不太关注，可能对 KubeVela 还没有做过太深刻的理解。别着急，本文就借着 v1.0 公布之际，为你具体的梳理一次 KubeVela 我的项目的倒退脉络，解读它的核心思想和愿景，领悟这个正冉冉升起的云原生利用治理平台之星背地的“道之所在”。
作者 | KubeVela 我的项目维护者
起源 | 阿里巴巴云原生公众号
作为 OAM（Open Application Model）在 Kubernetes 上的实现，KubeVela 我的项目从 oam-kubernetes-runtime 演进至今不过半年多工夫，但发展势头十分迅猛，不仅间断登上 GitHub Go 语言趋势榜首和 HackerNews 首页，更是迅速播种了包含 MasterCard、Springer Nature、第四范式、SILOT、Upbound 等来自世界各地、不同行业的终端用户，甚至还呈现了像 Oracle Cloud、Napptive 等基于它构建的商业化产品。就在 2021 年 3 月底，KubeVela 社区发表蕴含所有稳定版 API 的 v1.0 版本公布，正式开始向企业级生产可用迈进。
不过，如果你对云原生畛域不太关注，可能对 KubeVela 还没有做过太深刻的理解。别着急，本文就借着 v1.0 公布之际，为你具体的梳理一次 KubeVela 我的项目的倒退脉络，解读它的核心思想和愿景，领悟这个正冉冉升起的云原生利用治理平台之星背地的“道之所在”。
首先，什么是 KubeVela？
一言以蔽之，KubeVela 是一个“可编程式”的云原生利用治理与交付平台。
可是，什么是“可编程”呢？它跟 Kubernetes 又是什么关系？它能帮忙咱们解决什么问题？
PaaS 零碎的“能力窘境”
PaaS 零碎（比方 Cloud Foundry、Heroku 等）自诞生以来，就以其简略、高效的利用部署体验而被所有人津津有味。然而，大家也晓得，咱们明天的“云原生”，却是一个 Kubernetes 大行其道的世界，已经的 PaaS（包含 Docker）到底遇到了什么问题呢？
其实任何一个尝试应用过 PaaS 的人，都会对这种零碎的一个实质缺点感触颇深，那就是 PaaS 零碎的“能力窘境”。
图 1 – PaaS 零碎的能力窘境
如图 1 所示，PaaS 零碎在最开始应用的时候，往往体验十分好，也总能恰到好处地解决问题。但随着应用工夫的推移，一个十分厌恶的状况就会呈现：利用的诉求，开始超过 PaaS 零碎可能提供的能力。而更可怕的是，一旦这个问题呈现，用户对 PaaS 零碎的满意度就会断崖式上涨，这是因为无论是从新开发平台减少性能，还是批改利用去适配平台，都是一项投入微小但收益很低的事件。更何况所有人这时候都会开始对平台失去信念：谁晓得下一次零碎或者利用大改，是不是很快又要产生了？
这个“命门”，能够说是 PaaS 尽管具备云原生所需的所有因素、却最终未能成为支流的次要起因。
而相比之下，Kubernetes 的特点就比较突出了。只管 Kubernetes 被人诟病“简单”，但随着利用复杂度的晋升，Kubernetes 的长处就会缓缓体现进去，尤其是当用户的诉求开始须要你去通过 CRD Controller 反对的时候，你肯定会庆幸：幸好当初选了 K8s。
这里的起因在于，Kubernetes 的实质其实是一个弱小和强壮的基础设施能力接入平台，也就是所谓的 The Platform for Platform。它的这套 API 和工作形式，人造不适宜间接跟人去进行交互，但却可能以十分统一的形式接入任何基础设施能力，为平台工程师构建 PaaS 等下层零碎提供“有限弹药”。这种“BUG 级”的基础设施能力供应形式，让再精细的 PaaS 零碎相比之下都像是一个碍手碍脚的“玩具”，这一点对于很多正挣扎于构建外部利用平台的大型企业来说（它们才是 PaaS 厂商真正想赢取的用户）无异于是久旱逢甘霖。
云原生 PaaS：新瓶装旧酒
后面提到的一点其实很重要：如果一个大型企业要决定驳回一个 PaaS 零碎还是抉择 Kubernetes，平台团队往往才是能决定拍板的那一方。但另一方面，平台团队的意见尽管重要，并不意味着最终用户的想法就能够不论了。事实上，在任何一个组织中，间接发明价值的业务团队才持有最高的话语权，只不过起作用的工夫稍晚而已。
所以在绝大多数状况下，任何一个平台团队拿到 Kubernetes 之后，并不会间接去让业务去学习 Kubernetes，而是会基于 Kubernetes 构建一个“云原生”PaaS，用它去服务业务方。
咦，于是乎大家兜兜绕绕，又回到了故事的原点。惟一的变动是，咱们明天这个 PaaS 是基于 K8s 实现的，的确轻松了不少。
但理论状况呢？
这个基于 Kubernetes 构建 PaaS 的故事，看似美妙，其实整个过程却不免有些“心酸”。说的好听点是开发 PaaS，其实 80% 的工作是在设计和开发 UI，剩下的工作则是装置和运维 K8s 插件。而更令人遗憾的是，咱们这样构建进去的 PaaS，其实跟以前的 PaaS 没有实质不同，任何时候用户诉求扭转，咱们都须要花大量工夫从新设计、批改前端、排期上线。后果就是，K8s 突飞猛进的生态和有限可扩大的个性，都被“封印”在咱们亲手构建的 PaaS 之下“不见天日”。终于有一天，业务方也切实忍不住要问了：你们平台团队上了 K8s，到底有啥价值？
下面这个“为了解决 PaaS 的固有限度，后果又引入一个新的 PaaS 和限度”的困局，是现今很多公司在落地云原生技术的过程中遇到的一个外围问题。咱们仿佛再一次把用户锁定在一层固定的形象和能力集当中。所谓云原生化的益处，仅仅体现在咱们本人开发这个平台变得简略了 —— 而对业务用户来说，这仿佛没什么太大的意义。
更为麻烦的是，云原生和 K8s 的引入，也让运维人员这个角色变得十分奥妙。原本，他们所把握的业务运维最佳实际，是整个公司中最重要的教训和资产。然而，在企业云原生化之后，这个工作的内容都必须交给 K8s 去接管。所以，很多人都说，K8s 要让“运维”就业了，这个说法尽管有点夸大，但的确反映出了这个趋势带来的焦虑。而且咱们不禁也在从另一个角度思考，云原生化的背景下，利用运维的教训和最佳实际，又该怎么落实？就拿一个简略的工作负载举例子，一个 K8s Deployment 对象，哪些字段裸露给用户、哪些不能，尽管体现在 PaaS 的 UI 上，但必定不能是靠前端开发说了算的吧。
KubeVela：下一代可编程式利用平台
阿里巴巴是整个业界在云原生技术上的先行者之一。所以上述这个围绕着利用平台的云原生技术难题，绝对也比拟早的裸露了进去。在 2019 年末，阿里根底技术团队与研发效力团队单干针对这个问题进行了大量的摸索与尝试，最终提出了“可编程式”利用平台的思维，并以 OAM 和 KubeVela 开源我的项目的形式同大家见面。这套体系，目前曾经迅速成为了阿里构建利用平台的支流形式。
简略地说，所谓“可编程”，指的是咱们在构建下层平台的过程中，不会间接在 Kubernetes 自身上叠加形象（哪怕只是一个 UI），而是通过 CUE 模板语言这种代码化（Code）的形式来形象和治理、并透出基础设施提供的能力。
举个例子，比方阿里的某个 PaaS 要对用户提供一个能力叫做 Web Service，这个能力是指任何须要从内部拜访的服务，都以 K8s Deployment + Service 的形式来部署，对用户裸露镜像、端口等配置项。
在传统办法中，咱们可能会实现一个 CRD 叫做 WebService，而后在它的 Controller 里来封装 Deployment 和 Service。但这必然会带来后面 PaaS“能力窘境”的问题：
咱们应该给用户裸露几种 Service 类型？将来用户想要其余类型怎么办？
用户 A 和用户 B 须要裸露的字段不对立该怎么办？比方咱们容许用户 B 批改 Label，但 用户 A 不能够，那这个 PaaS 该怎么设计？
……
而在 KubeVela 中，像下面这样面向用户的性能，则能够通过一段简略的 CUE 模板来形容（这里有残缺的例子）。而当你编写好这样一个 CUE 文件之后，间接通过一句 kubectl apply，用户就能够立刻应用到这个能力：
$ kubectl apply -f web-service.yaml
更重要的是，只有执行下面这条命令，KubeVela 就会主动依据 CUE 模板内容生成这个能力的帮忙文档和前端表单构造，所以用户立即就会在 PaaS 外面看到这个 WebService 性能如何应用（比方有哪些参数、字段类型），并且间接应用它，如下 图 2 所示：
图 2 – KubeVela 主动生成表单示意图
在 KubeVela 中，平台的所有能力比方金丝雀公布、Ingress，Autoscaler 等等，都是通过这种形式定义、保护和透出给用户的。这种端到端买通用户体验层与 Kubernetes 能力层的设计，使得平台团队能够以极低的老本疾速实现 PaaS 以及任何下层平台（比方 AI PaaS，大数据 PaaS），同时高效地响应用户的继续演进诉求。
- 不只是 Kubernetes 原生，是 Platform-as-Code
尤为重要的是，在实现层，KubeVela 并不是简略的在客户端去渲染 CUE 模板，而是应用 Kubernetes Controller 去渲染和保护生成的 API 对象。这里的起因有三点：
Kubernetes Controller 人造适宜保护用户层形象到底层资源之间的映射，并且通过管制循环（Reconcile）机制永远确保两者的一致性，而不会产生 IaC（Infrastructure-as-Code）零碎里常见的 Configuration Drift（配置漂移）问题（即：底层资源跟用户层的输出产生不统一）。
平台团队编写的 CUE 模板 kubectl apply 到集群之后，就变成了一个 Kubernetes 中的一个自定义资源（Custom Resource），它代表了一个抽象化、模块化的平台能力。这个能力能够被全公司的平台团队复用，也能够持续批改演进，而且它是 Namespace 化的资源，所以平台的不同租户能够调配同名但不一样的模板，互不影响。这样彻底解决了不同租户对同一个能力的应用诉求不一样的问题。
如果随着时间推移，用户对平台性能的设计提出了新的要求，那么平台保护团队只须要装置一个新的模板，新的设计就会立即失效，平台自身不须要做任何批改，也不必重启或者重新部署。而且新模板也会立即被渲染成表单呈现在用户 UI 上。
所以说，KubeVela 的上述设计，从根本上解决了传统 IaC 零碎用户体验虽好，然而生产环境上“靠不住”的老大难问题，又在绝大多数状况下让整个平台响应用户需要的工夫从原先的数周，升高到几小时，齐全买通了云原生技术与最终用户体验之间的壁垒。而它齐全基于 Kubernetes 原生形式实现，确保了整个平台严格的健壮性，并且无论任何 CI/CD 以及 GitOps 工具，只有它反对 Kubernetes，就肯定反对 KubeVela，没有任何集成老本。
这套体系，被大家形象的称为：Platform-as-Code（平台即代码）。
- 别急，KubeVela 当然反对 Helm
提到 KubeVela 以及 CUE 模板这些概念，很多小伙伴就开始问了：KubeVela 跟 Helm 又是什么关系啊？
实际上，Helm 和 CUE 一样，都是一种封装和形象 Kubernetes API 资源的工具，而且 Helm 应用的是 Go 模板语言，人造适配 KubeVela Platform-as-Code 的设计思路。
所以在 KubeVela v1.0 中，任何 Helm 包都能够作为利用组件被部署起来，并且更重要的是，无论是 Helm 组件还是 CUE 组件，KubeVela 里的所有能力对它们都实用。这就使得通过 KubeVela 交付 Helm 包能够给你带来一些十分重要然而现有工具很难提供的能力。
举个例子，Helm 包其实很多是来自第三方的，比方 Kafka Chart，可能就是 Kafka 背地的公司制作的。所以个别状况下，你只能用，但不能改它外面的模板，否则批改后的 Chart 你就得本人保护了。
而在 KubeVela 中，这个问题就很容易解决。具体来说，KubeVela 提供一个运维侧的能力叫做 Patch，它容许你以申明式的形式给待交付组件（比方 Helm 包）里封装的资源打 Patch，而不必去关怀这个字段有没有通过 Chart 模板透出来，而且 Patch 操作的机会，是在资源对象被 Helm 渲染进去之后、提交到 Kubernetes 集群解决之前的这个工夫，不会让组件实例重启。
再比方，通过 KubeVela 内置的灰度公布零碎（即：AppRollout 对象），你还能够将 Helm 包作为一个整体进行渐进式公布且无需关怀工作负载类型（即：哪怕 Chart 里是 Operator，KubeVela 也能够进行灰度公布），而不是像 Flagger 等控制器那样只能针对繁多的 Deployment 工作负载进行公布。此外，如果将 KubeVela 同 Argo Workflow 集成，你还能够轻松的指定 Helm 包的公布程序和拓扑等更简单的行为。
所以说，KubeVela v1.0 不仅反对 Helm，它的指标是成为交付、公布和运维 Helm Chart 最弱小的平台。一些社区同学曾经在本文公布之前就急不可待的试用了这部分性能，大家能够移步到这篇文章来浏览。
- 全自助式用户体验和云原生时代的运维
得益于 Platform-as-Code 的设计，基于 KubeVela 的利用平台人造对用户是自助式的应用形式，如图 3 所示。
图 3 – KubeVela 自助式能力交付流程图
具体来说，平台团队只须要极小的人力老本就能够在零碎中保护大量的、代码化的“能力模板”。而作为平台的终端用户，业务团队只须要依据本人的利用部署需要在 PaaS UI 上抉择几个能力模板，填入参数，就能够自助式的实现一次交付，无论这个利用如许简单，业务用户的学习老本都非常低，并且默认就会遵循模板中所定义的标准；而这个利用的部署和运维过程，则由 Kubernetes 以自动化的形式去治理，从而加重了业务用户大量的心智累赘。
而更为重要的是，这种机制的存在，让运维人员再次成为了平台团队中的外围角色。具体的说，他们通过 CUE 或者 Helm 设计和编写能力模板，而后把这些模版装置到 KubeVela 零碎中给业务团队应用。大家试想一下，这个过程，其实就是运维人员把业务对平台的诉求，联合整个平台的最佳实际，以代码化的形式固化成可被复用和定制的能力模块的过程。而且这个过程中，运维并不需要去进行简单的 K8s 定制和开发，只须要了解 k8s 的外围概念即可。另一方面，这些代码化的能力模块，复用性极高，变更和上线非常容易，并且大多数状况下不须要额定的研发老本，能够说是最麻利的“云原生”运维实际，可能真正让业务感触到云原生“研发、交付、运维高效一体化”的外围价值。
- 多环境多集群、多版本利用交付
KubeVela v1.0 的另一个重大更新，就是改良了零碎的部署构造，提供了 Control Plane（管制立体）模式，从而具备了面向多环境、多集群进行版本化利用交付的能力。所以当初，一个典型的生产环境 KubeVela 部署状态如下图 4 所示：
图 4 – KubeVela 管制立体部署状态示意图
在这个场景下，KubeVela 反对为多环境利用进行形容，反对为利用配置 Placement 策略以及利用多版本同时部署在线、并通过 Istio 进行灰度的公布模型。大家能够通过这个文档进行深刻理解。
在 v1.0 公布之后，KubeVela 会围绕上述架构进行继续的演进，其中的一个次要的工作项就是将 KubeVela Dashboard、CLI 和 Appfile 全副迁徙和降级到同 KubeVela 管制立体通过 gRPC 进行交互，而不是像之前的版本那样须要间接跟指标集群打交道。这部分工作目前尚在进行中，欢送对构建下一代“可编程式”开发者体验有心得的同学一起来参加。与此同时，欧洲出名科技出版商 Springer Nature 也正在一起参加这部分工作以便从 CloudFoundry 上平滑迁徙到 KubeVela。
结语
如果咱们总结一下 KubeVela 明天的设计与能力，其实不难发现它是明天云原生利用平台倒退的一条必然门路：
齐全基于 Kubernetes 构建，人造的被集成能力和普适性，人造透出 Kubernetes 及其生态的所有能力而不是叠加形象；
基于 X-as-Code 的平台能力模块化，配合 OAM 模型实现超低老本的能力封装、形象和组装机制，疾速麻利的响应用户需要，提供全自助、无锁定的利用治理与交付体验；
基于 Kubernetes 控制器模式进行组件解封装和利用部署，确保最终一致性、确保利用交付与运维流程的健壮性；
内置以利用为单位的公布策略和面向多环境、多集群交付策略，极大地补充了社区目前以繁多工作负载为核心的公布能力；
无论利用部署如许简单，只须要 1-2 个 Kubernetes YAML 文件就能做残缺的形容，人造适宜并且大大简化 GitOps 工作流，极大水平升高了终端用户应用云原生和 Kubernetes 的上手老本，并且不带来任何能力或者形象锁定。
更重要的是，KubeVela 以 Platform-as-Code 的设计思维，给将来基于云原生的利用平台团队提出了更加正当的组织形式：
平台 SRE 负责 Kubernetes 集群和组件的健壮性；
平台研发工程师负责开发 CRD Controller，同 Kubernetes 内置能力一起对应用层提供残缺的利用治理、运维和基础设施能力；
业务运维联合业务诉求，负责将最佳实际代码化为 CUE 或者 Helm 模板，将平台的能力模块化；
业务用户以齐全自助化的形式应用平台的模块化能力来进行利用治理与交付，心智累赘低，部署效率高。
而基于这套体系，KubeVela 利用平台还能够用来实现弱小的“无差别”利用交付场景，达成齐全与环境无关的云端利用交付体验：
组件提供方将利用交付所需的能力（工作负载、运维行为、云服务）定义为 Helm 包或者 CUE 包，注册到 KubeVela 零碎当中；
利用交付人员应用 KubeVela 组装上述模块化能力成为一个齐全与基础设施无关的利用部署形容，同时能够借助 KubeVela 的 Patch 等能力定制和笼罩组件提供方的配置，或者定义简单的部署拓扑；
通过多环境、多集群交付模型定义利用在不同环境中的部署状态和交付策略，配置不同版本利用实例的流量调配策略。
KubeVela v1.0 的公布是咱们基于 OAM 模型以及云原生利用交付使用场景最大化验证的后果，它不仅代表了稳固的 API，还代表了成熟的应用范式。然而这不代表完结，而是一个全新的开始，它开启了一个“可编程式”利用平台的将来，这是一个可能充沛开释云原生后劲、让最终用户和软件交付方从第一天开始就充沛享受云原生技术魅力的无效门路。咱们期待这个我的项目能达成它最奢侈的愿景：Make shipping applications more enjoyable!
原文链接
本文为阿里云原创内容，未经容许不得转载。
