作者： 殷达（晖树）
自 2020 年 OAM（Open Application Model） 开放应用模型发布以来，KubeVela 经历了数十个版本的更新和演变，朝着现代化应用交付的高级功能不断发展。今天，我们将回顾 KubeVela 项目发展至今的亮点功能和核心技术。
什么是 KubeVela？
KubeVela 是一个面向现代化应用的交付与管理平台，它使得应用在面向混合、多云环境中的交付和运维变得更简单、高效和可靠。它有以下三个主要功能：
- 基础设施无关
KubeVela 能够将你的云原生应用程序部署到各种目的地，如 Kubernetes 多集群、不同的云平台和边缘设备。
- 可编程
KubeVela 具有用于建模应用程序和交付过程的抽象层。这些抽象层允许用户使用可编程方式构建更高级别的可重用模块，用于应用程序交付，并在 KubeVela 系统中集成任意第三方项目（如 FluxCD、Crossplane、Istio、Prometheus）。
- 以应用为中心
KubeVela 面向业务应用开发专门设计，有丰富的工具生态，包括 CLI、UI、GitOps、可观测性等，为应用程序的交付和运维增加了大量开箱即用的功能。
KubeVela 关注应用程序的整个生命周期，包括 Day-1 交付和 Day-2 运维阶段。它能够连接各种持续集成工具，如 Jenkins 或 GitLab CI，并帮助用户在混合环境中交付和运维应用程序。
为什么选择 KubeVela？
困难和挑战
如今，快速增长的云原生基础设施为用户部署应用程序提供了越来越多的能力，如高可用性和安全性，但也直接向应用程序开发人员暴露了越来越多的复杂性。
例如，Kubernetes 上的 Ingress 资源使用户能够轻松地对外暴露服务，但开发人员需要处理 Ingress 升级，当底层 Kubernetes 版本发生变化时，这需要对 Ingress 资源有一定的了解。在各种云供应商之间进行混合部署可能会使这个问题变得更加困难。
Open Application Model（开放应用模型）
为了应对上述挑战并弥合应用程序使用和基础设施细节理解之间的差距，阿里云和微软 Azure 在 2020 年共同提出了开放应用模型（OAM）。其目的是为应用程序交付定义一个一致的应用程序模型，与平台和实现无关。
定义的应用程序模型为开发人员描述了应用程序由什么组成以及工作方式的接口。前者被称为 OAM 中的组件，通常用于对应用程序的工作负载进行建模。后者被定义为 OAM 中的特性，它为组件提供附加额外的功能。
作为 OAM 的 KubeVela
KubeVela 是（OAM）Open Application Model 的实现之一。在 KubeVela 中，抽象层由 CUE 支持，这是一种新颖的配置编程语言，可以描述复杂的渲染逻辑，它在使用层面与 JSON 一致，是 JSON 的超集。抽象层简化了 Kubernetes 中资源的配置，隐藏了实现的细节，并仅向业务开发人员暴露有限参数。使用 KubeVela 应用程序，开发人员可以轻松地专注于应用程序的中心逻辑，例如应该使用哪个容器镜像以及如何访问服务。
为了实现这一目标，使用 Kubernetes 原生资源的最佳实践被总结到 KubeVela X-Definitions 中，并使用 CUE 提供资源的渲染模板。这些模板可以从各种来源访问，包括官方存储库、社区插件甚至系统运营商的自定义实现，这些模板大多与基础设施实现无关，使用这些模板时，开发人员不需要了解底层基础设施结构。
组件和特征
应用程序模型将基础设施的抽象分为两个不同的方面。组件描述了主要的工作负载，特别是在 Kubernetes 中可以是部署、StatefulSets、Helm Release 等。另一方面，特征描述了主要工作负载的附加功能，例如指定副本数的缩放器特征，网关特征聚合用于访问的端点。组件和特征设计中的关注点分离为抽象提供了高度的可扩展性和可重用性。
例如，网关特性可以由不同的基础设施（如 Ingress 或 HTTPRoute）进行后端处理。使用该特性的应用程序开发人员只需关心公开的参数，包括路径、端口和域名。该特性可以附加到各种类型的工作负载，由不同类型的组件进行抽象，例如 Deployment、StatefulSet、CloneSet 等。
对于应用开发人员和 SRE 处于不同团队的情况下，KubeVela 为他们的责任做了明确的分工。
- 提供基础设施的平台团队负责构建 X-Definitions，以实施最佳实践和提升部署信心。
- 最终用户只需选择平台团队提供的组件和特征，并使用它们来组装应用程序。他们可以简单地享受类似 PaaS 的体验，而不是直接与基础设施进行交互。
得益于 KubeVela 的灵活、可扩展和可编程的系统，这些都可以应用在不同的环境中。
统一交付
应用程序交付可以发生在任何地方。因此，KubeVela 应用程序的另一个目标是构建统一的交付，并在各种场景下为用户提供一致的使用。
混合云和多集群
除了抽象层之外，KubeVela 还原生支持混合云或多集群架构，因为现代云原生应用不仅涉及容器，还涉及大量云资源。此外，越来越多的用户和团队开始面临将应用程序交付到各种环境或多集群以实现用于不同目的的困难，例如测试或高可用性。
KubeVela 应用程序允许用户通过策略定义交付目标和差异化配置。抽象层有助于隐藏集群如何注册和连接的详细信息，并为应用程序开发人员提供与运行时无关的用法。
插件集成
为了丰富交付能力，用户可以利用 KubeVela 插件集成来扩展他们的系统。这些插件是可发现、可重用且易于安装的功能包。它们通常包含功能提供程序，包括广泛的第三方项目，如 FluxCD、ClickHouse、Crossplane 等。插件不仅将这些项目安装到系统中，还能同时为集成创建相应的定义，从而扩展了应用程序开发人员能够使用的组件和特性类型。
目前，KubeVela 社区已经拥有 80 多个插件。平台构建者可以根据其定制需求在系统中享用这些开箱即用的集成。
通过启用系统中的插件，最终用户可以以更自定义的方式组装应用程序，例如部署云资源或使用高级工作负载。
KubeVela 工作流
虽然开放应用模型定义了应用程序的组成，但在实际情况下，组成部分的交付过程仍然可能有很大的差异。例如，一个应用程序中的不同组件可能具有相互依赖或数据传递，其交付步骤必须按特定顺序执行。此外，交付过程有时还涉及除资源交付之外的更多操作，例如升级或通知。
因此，一个可扩展的工作流被设计了出来，以满足 KubeVela 中流程定制的需求。
与组件和特征一样，KubeVela 工作流程也利用 CUE 来定义工作流程步骤，提供了灵活性、可扩展性和可编程性。它可以被视为基础设施即代码（IaC）的另一种形式。
在 KubeVela 中，已经提供了一系列内置的工作流程步骤，这些步骤提供了丰富的开箱即用的功能，例如进行多集群部署，通过 Slack 或电子邮件发送通知等。与涉及运行额外容器的其他类型引擎相比，轻量级引擎确保了步骤执行的高性能和安全性。
与 KubeVela 中的组件和特征定义不同，工作流步骤定义不会将模板渲染成资源。相反，它描述了在步骤中要执行的操作，该操作调用各种提供程序中的底层原子函数。
通过使用工作流程和插件，用户可以构建任意交付流程并进行定制集成。例如，可以让持续集成工具触发 KubeVela 应用程序的交付，并实现结合 FluxCD 和其他插件的 GitOps 解决方案。
Day-2 管理
KubeVela 不仅关注 Day-1 的交付，还提供了一个统一的 Day-2 应用程序管理能力，以满足其可扩展性的需求。Day-2 管理对于系统运维人员和应用程序开发人员来说是很有必要的，以便对交付的应用程序进行持续的运维，并确保应用程序始终处于可控状态。
资源管理
应用程序管理的基本能力是针对其资源的。KubeVela 的核心控制器不断监视交付资源的当前状态和所需状态之间的差异。它确保实时规范与交付流程记录的声明规范一致，从而有效地防止任何配置漂移。
此外，自动垃圾回收有助于回收升级或删除期间未使用的资源。有时还需要在多个应用程序之间共享资源。这些都是通过使用策略在 KubeVela 应用程序中实现的。
版本控制
KubeVela 应用程序会为交付记录保留历史记录。当新版本发布结果不符合预期时，这些快照非常有用。更改检查可以用于诊断可能的错误更改，回滚允许快速恢复到先前成功的状态。
可观测性
KubeVela 将可观测性视为一等公民。它是用户监视应用程序状态和观察异常的眼睛。KubeVela 中有多个工具和方法可以执行观察任务。其中最直接的方法之一是使用 KubeVela 的 CLI 工具。Vela CLI 能够以细粒度或聚合级别为应用程序提供及时状态信息。
对于偏爱 Web 界面的用户，VelaUX 提供了另一种查看应用程序状态的方法。
在通过第三方项目（如 Grafana、Prometheus 或 Loki）监控应用程序的情况下，KubeVela 进一步提供了用于引导可观察性基础设施的插件，并使用户能够通过抽象层将观察规则自定义应用程序中的代码。
一系列开箱即用的指标和仪表板为用户提供了自动化系统可观测的基本功能。这些可用于诊断系统级异常并帮助提高整体性能。
生态系统
除了上述工具之外，KubeVela 生态系统中还有几个其他工具来促进应用软件交付和管理。
- Vela CLI
KubeVela CLI 提供了多种命令，可帮助您操作应用程序，例如管理定义、查看资源、重新启动工作流、滚动版本等。
- VelaUX
VelaUX 是 KubeVela 的 Web UI。此外，它还将业务逻辑整合到基本的 API 中，并为非 k8s 专家用户提供开箱即用的用户体验。
- Terraform Controller
KubeVela 中的 terraform 控制器允许用户通过 Kubernetes 自定义资源使用 Terraform 管理云资源。
- Cluster Gateway
提供统一的多集群访问接口的网关。作为 Kubernetes 聚合 API 服务器，网关利用本地身份验证和授权模块，并强制执行对托管集群的安全透明访问。
- VelaD
建立在 k3s 和 k3d 之上，VelaD 将 KubeVela 与 Kubernetes 核心集成在一起，对于构建开发/测试环境非常有用。
- Vela Prism
KubeVela 扩展 API 服务器，基于 Kubernetes 聚合 API 服务构建。它将原生 API (如在 Grafana 上创建仪表板) 投射成 Kubernetes 资源 API 中，以便用户可以将第三方 API 作为 Kubernetes 原生资源进行管理。
- Vela Workflow
是一个独立的工作流引擎，它作为一个纯粹的交付工具，可以交付多个 KubeVela 应用或衔接其他系统实现统一 CI/CD。与 Tekton 相比，它更轻量，对于基本的配置交互和数据传递主要通过 CUE 引擎执行，而不是依赖 Pod 和 Job 运行。
稳定性
为了确保 KubeVela 能够在有限资源下处理一定数量的应用程序，我们在各种情况下进行了多次负载测试。实验表明，KubeVela 系统的性能能够在普通大小的集群中处理数千个应用程序。可观性基础设施进一步暴露了 KubeVela 的瓶颈，引导系统运维人员进行定制调整，以提升特定使用环境中下性能。
总结
目前，KubeVela 已经被来自不同领域的 300 多家企业应用于生产环境。有些用户主要使用 KubeVela 的抽象能力来简化应用的使用和部署。有些用户在 KubeVela 上构建以应用为中心的管理系统。有些用户使用自定义的工作流程来编排交付流程。它在互联网、金融、电商、智能制造、AI 等领域特别受欢迎，并被证明对于交付和管理大型应用非常有帮助。
KubeVela 社区已经吸引了来自全球的贡献者，并在过去两年中不断发展壮大。如今，来自不同国家的 200 多名贡献者已经参与了 KubeVela 的开发提出了数千个问题，其中 85% 已经得到解决。此外，英语和中文社区还定期举行双周社区会议。
随着越来越多的人加入社区，KubeVela 也在不断升级自己以适应更复杂、多变的使用案例和场景。
您可以通过如下材料了解更多关于 KubeVela 以及 OAM 项目的细节：
- 项目代码库：https://github.com/kubevela/kubevela欢迎 Star/Watch/Fork！
- 项目官方主页与文档：kubevela.io ，从 1.1 版本开始，已提供中文、英文文档，更多语言文档欢迎开发者进行翻译。
- 项目钉钉群：23310022；Slack：CNCF #kubevela Channel
- 加入微信群：请先添加以下 maintainer 微信号，表明进入 KubeVela 用户群：
点击此处查看 KubeVela 项目官网
