在云原生理念迅速普及的今天，混合环境部署（混合云 / 多云 / 分布式云 / 边缘）已经成为了大多数企业应用、SaaS 服务、应用持续交付平台的必然选择，而云原生技术的发展趋势也正在朝着 “一致的、跨云、跨环境的的应用交付” 不断迈进。然而，无论是 Kubernetes 本身还是现有的各类应用交付系统，都没有在现今混合、分布式的部署环境之上引入一致的上层抽象来为应用交付进行建模。这种缺乏统一上层抽象的应用交付过程，往往同底层基础设施紧密耦合，导致用户心智负担很重并且严重依赖于用户个人的经验和能力。这不仅会大幅影响用户体验、降低生产效率，甚至还会导致错误和故障的发生。

而现在，这个问题终于有了一个开源、标准，又不失灵活度的解法。它就是：

KubeVela 作为一个开箱即用、面向现代微服务架构的应用交付与管理平台，今天正式发布了 1.1 版本，以更加用户友好和完善的功能集，开启了 “让混合环境应用交付更加简单高效” 的重要里程碑。

具体来说，1.1 版本的 KubeVela 与现有各类应用交付系统相比，有着显著的不同和优势：

• 完全以应用为中心 - 与各类 “搭积木” 式的 PaaS 系统或者应用平台不同，KubeVela 项目本身是构建于一套完善的应用交付模型与理论基础之上的，这就是 “开放应用模型（OAM）” 技术。OAM 模型能够通过声明式的定义来捕获面向混合环境的微服务应用交付的整个过程，甚至包括云服务的拉起与绑定、可观测性、多集群分发策略、流量调配和滚动更新等各种运维行为和特征。通过这样一个统一的、基础设施无关的上层模型，KubeVela 天然就能够做到让用户无需关心任何基础设施细节、只专注于业务价值和交付过程，真正实现了完全 Serverless 化的应用管理与交付体验。
• 可编程式交付工作流 - 在 Kubernetes 面向终态的基础上，KubeVela 还通过 “交付流水线（Workflow）“来支持面向过程的应用交付流程，同时通过 Kubernetes 终态能力来保证该流水线执行的正确性与幂等性。在内核中，KubeVela 流水线是通过 CUE 来实现的。CUE 是一种诞生自 Google Borg 系统的数据配置语言（即：borgcfg），它可以将应用交付过程的所有步骤、所需资源、关联的运维动作以可编程的方式定义成一个 DAG（有向无环图），并以此作为用户最终的交付计划。这使得 KubeVela 的交付流水线不仅使用简单、扩展性极强，也更符合现代 GitOps 应用交付的趋势与要求。
• 基础设施无关 - 在 1.1 版本中，KubeVela 完成了 100% 的 “控制平面化”。这意味着它本身成为了一个运行在管控集群中的、完全与应用运行基础设施无关的交付控制平面。这种“使用 Kubernetes 作为管控平面、面向任何基础设施进行应用交付与管理” 的新架构，使得 KubeVela 可以按照用户定义的工作流与交付策略，面向任何环境交付和管理任意类型的应用组件，包括：容器、云函数、数据库、云服务、虚拟机实例等等。

KubeVela 1.1 介绍

自 Kubevela 1.0 版本发布以来，KubeVela 社区发展非常迅速，截止目前已经有超过 100+ 名开发者参与贡献，而且就在上个月，KubeVela 和 OAM 项目也已经整体捐赠给了 CNCF 基金会进行托管。在 1.1 版本中，KubeVela 更加聚焦面向混合环境的应用交付流程，带来了多集群交付、交付流程定义、灰度发布、公有云资源接入等多个开箱即用的能力和更加友好的用户体验。这其中，有两个核心能力值得特别关注：

• **天然支持多环境、多集群应用交付：**Kubevela 将底层环境的基础设施进行了面向应用的标准化抽象，涵盖了交付制品、算力（基础计算、AI 计算、云边协同计算）、运维特征（监控、流量治理、日志收集等）等多个维度。用户能够非常方便的将应用描述跟不同的待交付环境（集群）进行匹配、定义不同环境下的配置 Patch，从而把应用差异化地交付到不同环境或者集群当中。
• **天然支持声明式交付工作流：**众所周知，Kubernetes 的资源模型是以终态来维护的，但是实际的应用交付场景，却往往是一个面向过程的系列操作（比如：声明组件 A - 部署组件 A 到测试集群 - 切 50% 流量到组件 A - 运行测试 - 发布到生成集群等等）。所以在社区中，用户希望简单、透明的控制应用交付流程的诉求非常强烈，但往往又不希望因此引入一套全新的、完整的 CI/CD 系统。为此，KubeVela 1.1 在应用模型中增加了 Workflow 语义来精细化的描述整个应用交付工作流，并且内置就提供 “人工审批”、“回滚”、“数据传递”、“Slack / 钉钉通知” 等多个工作流步骤（Step）。更重要的是，这种实现在应用模型层的声明式 Workflow 天然具备被集成能力，可以非常自然的同现有 CI/CD 系统或者 GitOps 工具通过扩展的方式做集成，而不需要用户在取舍间痛苦。

正是通过上述设计，KubeVela 可以帮助你从 “静态配置、模板、胶水代码” 的初级阶段，直接升级至 “自动化、声明式、统一模型、天然面向多环境” 的下一代以工作流为核心的交付体验当中。

基于上述能力，用户现在可以通过 KubeVela 非常轻松的处理以下场景：

多环境、多集群应用交付

面向 Kubernetes 的多环境、多集群交付已是一个标准性需求。您或许是需要环境隔离，开发、预发和生产三套集群；或许是需要交付不同的客户，每个客户独立一套集群；或许是需要交付到不同区域，在北京、广州多套集群；又或许您业务规模大，单个 Kubernetes 集群无法满足您的资源需求。从 1.1 版本开始，KubeVela 不仅实现了多集群的应用交付，并且既可以独立工作直接纳管多个集群，也可以集成 OCM、Karmada 等各类多集群管理工具来进行更复杂的交付动作。多集群应用发布 Demo(结合 Workflow) 请查看文末链接。

在上述例子中，我们就将一个应用差异化的交付到了不同的集群环境中。这种 “交付差异” 在 KubeVela 中属于交付策略（Policy）的一种，它可以是环境配置差异、组件数量差异等等。值得一提的是，KubeVela 支持 Kustomize 风格的 Patch 来定义这种差异，但又不需要用户学习任何 Kustomize 相关的知识。在多集群交付策略的基础上，用户还可以通过定义 Workflow 来控制交付到不同集群的顺序、条件等工作流步骤。

进一步尝试多集群应用交付，请参考最佳实践文档。

后续版本中，KubeVela 在多集群交付方面会提供全局流量分发、多集群自动调度策略、多集群灰度发布等更多高级特性特性。

定义交付工作流（Workflow）

Workflow 的背景前面已经提到过，而它的具体使用场景则很多，比如：在多环境应用交付场景中，用户可以定义不同的环境交付的顺序和前置条件；再例如最简单的需求，部署完成后需要通知开发者；再例如我们需要控制灰度发布的进程，流量切换的比例，再例如我们需要应用部署完成后执行 E2E 测试等。KubeVela 的工作流是面向持续交付（CD）过程的，同时也是声明式的，所以它既可以作为 CD 系统直接同 CI 系统（比如 Jenkins 等）对接，也可以嵌入到现有 CI/CD 体系中作为增强和补充，落地方式非常灵活。

在模型上，Workflow 是由一系列 Step 组成的，而在实现上，每一个 Step 则是一个独立的能力模块，由其具体的类型和参数来决定其具体步骤的能力。在 1.1 版本中，KubeVela 内置的 Step 已经比较丰富，欢迎大家试用、反馈。并且，Step 非常容易扩展，也能够让大家去对接已有的平台能力，做到无缝迁移。

连接 service mesh 提供灰度发布等高级运维操作

通过统一的应用模型集成各种不同的底层能力，依然是 KubeVela 最大的亮点之一。具体来说，KubeVela 通过 OAM 模型可以使得用户不需要任何 “脏乱差” 的胶水代码或者脚本就可以同任何云原生技术或工具（比如 Service Mesh）实现集成，从而为交付过程带来更多的云原生应用运维能力。在 1.1 版本中，KubeVela 已经内置了与 Istio 集成的案例。系统管理员可以通过 KubeVela 的插件管理机制便捷的启用 Istio 插件 。KubeVela 则负责将 Istio 的能力进行封装和抽象后交付给用户使用，使得用户无需成为 Istio 专家就可以直接使用这个金丝雀发布的场景（KubeVela 会为用户提供一个封装好的 Rollout 运维特征）。这种体验开发者来说是相当友好的，他既无需花费大量的时间去学习和掌握 Istio 的使用和配置，也无需关注 Istio 体系和各种云上托管版 Service Mesh 的差异，彻底解耦厂商锁定。

应用渐进式发布 Demo(结合 Workflow)

您可以参考 Rollout Demo 实现图示效果，或参考最佳实践 基于 Istio 的渐进式发布，体验完整的微服务渐进式发布和回滚。

以应用为中心的云资源交付

云厂商资源已经成为大多数应用开发者生产业务会采用的计算资源，它包括了基础设施、SaaS 服务、中间件服务、托管服务等。对此，KubeVela 的设计是从 “以应用为中心” 的视角出发，帮助开发者以完全 Serverless 的方式更好、更方便的管理云资源，而不是疲于应付各种不同的云产品和控制台。在实现上，KubeVela 内置集成了 Terraform 来作为云资源的编排工具，并且能够以统一的应用模型支持各个云厂商上百种不同类型云服务的部署、绑定和管理。

在使用上，我们目前将云资源分为以下三类：

• 作为组件：比如数据库、中间件、SaaS 服务等。比如 KubeVela 中的 Alibaba-RDS 服务就属于这种。
• 作为运维特征：比如日志分析、监控可视化、监控报警等服务。
• 作为应用运行基础设施：比如 Kubernetes 托管集群、SLB 负载均衡、NAS 文件存储服务等。

在后续的版本，KubeVela 会进一步增加更加丰富的云服务使用场景，对各个云厂商分散的资源和计算能力进行有效整合，降低开发者的使用门槛和服务触达路径，实现资源的复用和有效、安全的回收机制，降低用户费用。KubeVela 的 Terraform 云服务管理是目前社区中非常火热的一个组件，有大量来自北美、欧洲的贡献者参与其中，非常欢迎大家试用、贡献和提出需求。

更容易落地的 GitOps 持续交付实践

KubeVela 作为一个声明式的应用交付控制平面，天然就可以以 GitOps 的方式进行使用（可单独使用，也可配合 ArgoCD 等工具），并且能够为 GitOps 场景提供更多端到端的能力和增强、帮助 GitOps 理念以更加亲民和解决实际问题的方式在企业中落地。这些能力包括：

• 定义应用交付工作流（CD 流水线）
• 即：KubeVela 支持在 GitOps 模式中描述过程式的应用交付流程，而不只是简单的声明终态；
• 处理部署过程中的各种依赖关系和拓扑结构；
• 在现有各种 GitOps 工具的语义之上提供统一的上层抽象，简化应用交付与管理过程；
• 统一进行云服务的声明、部署和服务绑定；
• 提供开箱即用的交付策略（金丝雀、蓝绿发布等）；
• 提供开箱即用的混合环境 / 多集群部署策略（放置规则、集群过滤规则、跨环境 Promotion 等）；
• 在多环境交付中提供 Kustomize 风格的 Patch 来描述部署差异，而用户无需学习任何 Kustomize 本身的细节；
• …… 等等。

使用 KubeVela 践行 GitOps 理念，请参考 GitOps 最佳实践。

Kubevela 社区与生态

KubeVela 是一个从第一天就诞生在云原生社区的开源项目。截止目前，KubeVela 现已被 Salesforce、字节跳动、腾讯、网易游戏等 35+ 家不同行业的领先企业应用在实际生产环境，帮助他们在不同场景下实现更高效的云原生应用的交付和管理。而 KubeVela 在社区用户中的大规模实践，也正在促进 OAM 成为混合云 / 多云 / 分布式云领域应用交付的事实标准，并在微软、Oracle Cloud 等多家国际厂商中被采用。近日，以 OAM 模型为核心的《云计算开放应用架构》标准文件也已经由阿里云计算有限公司、中国信息通信研究院等 10 余家单位联合发起并在 “云原生产业大会” 现场发布。

在未来，在云原生社区和 CNCF 应用交付领域工作组（TAG App Delivery）的共同推动下，KubeVela 将继续在交付定义标准化、运维能力多样化、管理体系生态化三个方面发展，真正实现让混合环境下的应用交付就像我们今天使用 App Store 一样简单。我们看到开源社区正在围绕 KubeVela 的交付模型提出更多标准化组件、运维特征、插件、交付 Step 等能力，也非常欢迎新老社区用户前往：https://github.com/oam-dev/kubevela/issues/1662 进行登记、让社区听到每一位参与者的声音。

后续版本规划

打造天然面向混合环境的企业应用操作系统、让开发者享受交付应用的过程，这是 Kubevela 项目的目标和愿景：

• 1.0 版本，KubeVela 实现了基础的应用交付核心模型，解决了” 交付一切 “的关键能力问题，打造了可编程的应用交付和管理引擎。
• 1.1 版本，KubeVela 进一步完善了面向多环境应用交付的能力集和工作流，并且让用户可以通过命令行进行完整体验，并且上线了完整的中文文档。

而在接下来的 1.2 版本，KubeVela 将带来以应用为中心的控制面板 UI，实现便捷的企业应用组装、分发、交付流程，提供给开发者更简单的应用交付体验，同时覆盖边缘应用交付等更多的使用场景。