简介：KubeVela 作为一个开箱即用、面向古代微服务架构的利用交付与治理平台，明天正式公布了 1.1 版本，以更加用户敌对和欠缺的功能集，开启了“让混合环境利用交付更加简略高效”的重要里程碑。
在云原生理念迅速遍及的明天，混合环境部署（混合云 / 多云 / 分布式云 / 边缘）曾经成为了大多数企业应用、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/ku… 进行注销、让社区听到每一位参与者的声音。
后续版本布局
打造人造面向混合环境的企业应用操作系统、让开发者享受交付利用的过程，这是 Kubevela 我的项目的指标和愿景：
1.0 版本，KubeVela 实现了根底的利用交付外围模型，解决了”交付所有“的要害能力问题，打造了可编程的利用交付和治理引擎。
1.1 版本，KubeVela 进一步欠缺了面向多环境利用交付的能力集和工作流，并且让用户能够通过命令行进行残缺体验，并且上线了残缺的中文文档。
而在接下来的 1.2 版本，KubeVela 将带来以利用为核心的控制面板 UI，实现便捷的企业应用组装、散发、交付流程，提供给开发者更简略的利用交付体验，同时笼罩边缘利用交付等更多的应用场景。
更多我的项目 Roadmap 信息，详见 Kubevela RoadMap
原文链接
本文为阿里云原创内容，未经容许不得转载。