[](
)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），同时高效地响应用户的持续演进诉求。
[](
)1. 不只是 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（平台即代码）。
[](
)2. 别急，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 最强大的平台。一些社区同学已经在本文发布之前就迫不及待的试用了这部分功能，大家可以移步到[这篇文章](
)来阅读。
[](
)3. 全自助式用户体验和云原生时代的运维
得益于 Platform-as-Code 的设计，基于 KubeVela 的应用平台天然对用户是自助式的使用方式，如图 3 所示。
图 3 - KubeVela 自助式能力交付流程图
具体来说，平台团队只需要极小的人力成本就可以在系统中维护大量的、代码化的“能力模板”。而作为平台的终端用户，业务团队只需要根据自己的应用部署需求在 PaaS UI 上选择几个能力模板，填入参数，就可以自助式的完成一次交付，无论这个应用多么复杂，业务用户的学习成本都非常低，并且默认就会遵循模板中所定义的规范；而这个应用的部署和运维过程，则由 Kubernetes 以自动化的方式去管理，从而减轻了业务用户大量的心智负担。
而更为重要的是，这种机制的存在，让运维人员再次成为了平台团队中的核心角色。具体的说，他们通过 CUE 或者 Helm 设计和编写能力模板，然后把这些模版安装到 KubeVela 系统中给业务团队使用。大家试想一下，这个过程，其实就是运维人员把业务对平台的诉求，结合整个平台的最佳实践，以代码化的方式固化成可被复用和定制的能力模块的过程。而且这个过程中，运维并不需要去进行复杂的 K8s 定制和开发，只需要理解 k8s 的核心概念即可。另一方面，这些代码化的能力模块，复用性极高，变更和上线非常容易，并且大多数情况下不需要额外的研发成本，可以说是最敏捷的“云原生”运维实践，能够真正让业务感受到云原生“研发、交付、运维高效一体化”的核心价值。
[](
)4. 多环境多集群、多版本应用交付
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。
[](
)结语
总结
对于面试还是要好好准备的，尤其是有些问题还是很容易挖坑的，例如你为什么离开现在的公司（你当然不应该抱怨现在的公司有哪些不好的地方，更多的应该表明自己想要寻找更好的发展机会，自己的一些现实因素，比如对于我而言是现在应聘的公司离自己的家更近，又或者是自己工作到达了迷茫期，想跳出迷茫期等等）
CodeChina开源项目：【一线大厂Java面试题解析+核心总结学习笔记+最新讲解视频】
Java面试精选题、架构实战文档
整理不易，觉得有帮助的朋友可以帮忙点赞分享支持一下小编~
你的支持，我的动力；祝各位前程似锦，offer不断！