作者 | Infoq Tina
背景
12 月 9 日，在 2021 年 KubeCon 云原生技术峰会上，CNCF 开源我的项目 KubeVela 发表推出了 1.2 版本。
KubeVela 是一个简略易用且高度可扩大的利用交付和治理平台，基于 Kubernetes 与 OAM 技术构建。其外围性能是让开发人员方便快捷地在 Kubernetes 上定义与交付古代微服务利用，而无需理解任何 Kubernetes 自身相干的细节。KubeVela 于 2020 年 11 月开源，2021 年 4 月公布 1.0 版本。
2021 年 7 月，KubeVela 和 OAM 我的项目整体捐献给 CNCF 基金会托管。在 1.2 版本中，KubeVela 新增了以利用为核心的控制面板 UI 性能，使利用组装、散发、交付流程变得更简略，并能够通过 UI 控制台及时理解整个交付链路状态，简化多云 / 混合环境交付形式。另外还新增了基于订阅模型的开源利用交付零碎，使企业和云原生利用开发者只须要在 GitHub/Gitlab 上批改代码，就能够主动实现云原生利用交付的整个链路。从开源到当初曾经有一年多，KubeVela 社区获得了什么样的停顿？有了哪些落地实际？1.2 版本中为什么会新减少这两个性能，适宜于什么场景？
为解答这些问题，InfoQ 采访了 OAM/KubeVela 产品和开源社区负责人曾庆国。
嘉宾简介：曾庆国（花名：悦达），阿里云技术专家，目前负责 OAM/KubeVela 产品和开源社区，从事云原生、利用交付、开源畛域钻研和实际多年，致力于推动云原生利用标准化和云原生技术“亲民化”。
专访问答
InfoQ：目前基于 Kubernetes 的云原生利用交付还存在哪些挑战和难点？业界对应的有哪些解决方案？
曾庆国：现在 Kubernetes 逐步成为了基础设施的规范集成界面，云原生生态的凋敝也为咱们提供了近乎有限的基础设施能力。然而泛滥的抉择是礼物，也是研发工程师的噩梦，大量简单的常识须要学习，就好比一个业务研发工程师须要理解操作系统底层的零碎调用一样。然而利用的高效、平安交付，才是工程师真正的诉求。如何用好云原生凋敝的技术生态，又能升高用户的应用门槛，同时安全可靠的交付利用，成为了业界新的挑战。业界的典型做法次要分为三类，一类是容器平台模式，原汁原味的透出底层组件，灵活性很强，但平台使用者须要学习组件大量的技术细节；第二类是在针对不同的业务场景构建外部的平台，然而因为顶层设计有余，拉通难度大，不同垂直场景成为相互独立的烟囱而无奈做到能力复用、对立治理；第三类则是基于 CI/CD 零碎，以脚本、配置等构建简略的形象体系简化应用，这个形式的问题在于无奈满足大规模场景的须要，脚本和配置文件散落各处，其上手和保护的门槛十分高，也有安全隐患。
InfoQ：KubeVela 在 Kubernetes 生态系统中处于什么地位？初心是解决什么样的问题？当初的指标与最后相比有所变动？
曾庆国：明天，无论是 Kubernetes 自身还是现有的各类利用交付零碎，都不足一个对立的面向利用交付过程的下层形象。这种不足往往同底层基础设施严密耦合，导致用户心智累赘很重并且重大依赖于用户集体的教训和能力。这不仅会大幅影响用户体验、降低生产效率，甚至还会导致谬误和故障的产生。KubeVela 是针对这个问题的开源、规范又不失灵便度的解法。KubeVela 在 Kubernetes 生态系统下层建设了“以利用为核心”的视角，业务层的开发者能够间接应用 KubeVela 作为开箱即用的 CI/CD 工具对接包含 Kubernetes 和云资源，实现利用交付和治理。对于中大型的公司，KubeVela 是一个具备充沛可扩展性的利用交付和治理引擎，这些公司能够基于 KubeVela 标准化的扩大机制，针对本身业务场景扩大利用交付能力，疾速构建本人的利用治理平台。这个初心始终没有变动，咱们从利用规范 OAM 到现在 KubeVela v1.2 行将推出的 UI 控制台，这一系列的工作都是在推动云原生社区从基础设施向应用层一直倒退和演进，最终实现开发者自助的利用交付和管理模式，最终冀望为业界带来规范和对立的云原生利用管理层，普惠云计算的开发者。
InfoQ：从中立主观的角度来讲，您们认为 PaaS 解决方案和 KubeVela 各有什么样的优缺点？
曾庆国：说到经典的 PaaS 解决方案，业界最闻名的就是 Heroku 和 Cloud Foundry，它们提供残缺的应用程序部署和治理性能，为业务开发人员提供了十分好的体验和开发效率。然而云原生的崛起带来了技术的全面降级，也带来了云计算的微小凋敝。传统的 PaaS 平台通过提供一层利用封装和形象为用户带来好的体验，但这层封装往往短少良好的定制化扩大能力，平台演进不得不齐全依附平台团队开发，无奈应答业务新的个性化需要，无奈应答新技术倒退的麻利集成。
KubeVela 和它们最大的区别在于其可扩展性，KubeVela 从设计的第一天就以高可扩大为准则，以此为外围提供端到端的形象和用户体验。它的交付工作流乃至整个利用交付与治理能力集都是由独立的可插拔模块形成的，这些模块能够随时通过编写 IaC 配置模板的形式进行增减、重定义，且变更会即时失效。借助这种从外围模型到 UI 出现都可能疾速变更的技术，使得 KubeVela 可能兼顾“应用简略”和“技术先进性”。
此外，KubeVela 是一个独立于运行时集群的利用交付管制立体，人造反对多集群、多云混合环境（这是咱们认为的下一代 PaaS 零碎的正当状态），而现有的 PaaS 则往往抉择以插件模式部署在运行时集群当中。
InfoQ：基于 Helm 的利用交付计划，和 KubeVela 解决方案相比，两者有哪些不同？
曾庆国：Helm 是 Kubernetes 的包管理器，它可能以 Chart 为一个单元，提供打包、装置和降级的一组 YAML 文件的能力。
KubeVela 是一个残缺的利用交付零碎，它借助扩大能力能够部署各种制品类型，当然也包含 Helm Chart，除此之外还包含 Kustomize、Terraform Modules 等。KubeVela 反对 Kubernetes 和云服务等多种运行平台。同时它也涵盖了多集群交付的能力，包含跨环境部署的各类编排能力。例如，你能够应用 KubeVela 定义一个由 WordPress Chart 和阿里云 RDS 实例组成的利用，编排这两个组件之间的程序关系，而后将它们依照肯定的策略散发到多个 Kubernetes 集群当中。
咱们也在社区里见到了一些基于传统 CI/CD 工具 和 Helm 做利用部署的解决方案，这类计划通常会通过相似 Jenkins/Gitlab 这样的 Pipeline，将利用制品打包成 Helm Chart，而后间接部署到 Kubernetes 集群中。这种模式看似简略，实际上存在三个方面的问题：
手工保护工作量大，比方因为突发的网络起因、或者因为 pipeline 零碎的某个故障，就会中断所有的公布并且须要人工染指，不足自愈能力，一旦场景有变动，就要批改脚本，比拟难保护。
没有一个对立的模型形容残缺的利用交付过程，不同的人能够从多处入口对系统进行变更，例如有的通过 CI/CD 零碎，有的间接改 Kubernetes，工夫久了零碎的配置会呈现很大的不统一，容易引发故障。
存在平安危险，CI/CD 平安域不隔离，基础设施多个集群的秘钥全都在 CI/CD 零碎中存储，一旦被黑客冲破容易引发十分大的系统安全危险。
KubeVela 是面向终态的利用交付和管理控制立体，KubeVela 的交付引擎具备自愈、幂等、收敛以及确定这四大个性，同时 KubeVela 背地有一个残缺的利用模型（OAM），这个能够作为对立的利用入口，防止配置漂移等问题。KubeVela 本身也具备残缺的 GitOps 以及多集群自治的性能，能够保障环境独立治理，平安域隔离。
InfoQ：社区针对小规模集群或集体开发者的场景有所疑难，认为无论是减少 API 层还是还需编码，KubeVela 的方向在复杂化利用交付和集群治理，对此您们有何认识？
曾庆国：KubeVela 从一开始就诞生于开源社区，演进至今已有上百位贡献者参加代码奉献，吸纳了来自阿里、腾讯、字节、第四范式、Gitlab 等一系列不同畛域公司的工程实际。KubeVela 从一开始的设计指标是保障充沛的可扩展性，这样能力满足用户的多样化场景需要，充分利用云原生畛域百花齐放的技术生态红利。
对于集体开发者或中小型科技企业，他们的理论需要必然是心愿应用云原生技术就像应用 iOS 操作系统一样，低门槛，易用且好用。把端到端的体验做成闭环能力更好满足他们，无论减少 API 层还是须要编码，都不是这类用户想要关怀的话题。
主观的说，在 KubeVela 最后的几个版本，因为要把面向可扩展性的外围设计做实，用户看到的状态更多是偏框架一层的实现。在倒退到 v1.1 版本当前，咱们就陆续退出了很多端到端的集成案例，包含 GitOps、Jenkins CI/CD、Helm 包的残缺部署等，行将公布的 v1.2 就更是一个面向小规模集群和集体开发者间接开箱即用的平台了，用户能够间接操作 KubeVela 的 UI 控制台就能够实现利用交付的残缺体验。
InfoQ：1.2 版本中，基于订阅模型的利用交付次要是解决什么场景下的问题？
曾庆国：基于订阅模型的利用交付次要解决以下几个维度问题：
1、区域隔离，平安自治
残缺的利用交付链条分为 CI 过程、配置过程和部署过程。在订阅模型中，管制平台反对主动从制品库发现制品的变更，从配置仓库发现配置的变更，从而执行后续的部署动作，Runtime 集群区域被动从管控平台获取到部署工作执行。每一个环节都独立工作，自成体系，每一个环节都依据须要进行受权和审核，安全可靠。
2、网络隔离，云边协同
订阅模型采纳 PULL 的模式，仅须要单向通信网络即可工作，在边缘利用交付中这是一个必须的选项。KubeVela 能够对立编排和治理云端和边缘端利用，实现云边协同。
3、集中管理，充沛自动化
方才咱们提到，每一个阶段都是独立自动化工作的，且具备自愈、幂等、收敛以及确定这四大个性。让咱们的治理侧实现对立。另一方面，在 KubeVela 1.2 版本中，次要打造了在多集群、多环境下微服务利用的对立治理解决方案。用户通过操作 UI 控制台，实现集群接入、租户调配、环境规划和利用交付等残缺用户故事。
InfoQ：目前 KubeVela 社区倒退状况如何？将来的门路布局是什么？
曾庆国：KubeVela 是一个从第一天就诞生在云原生社区的开源我的项目，KubeVela 背地的利用模型就是 OAM。自 2019 年阿里和微软公布 OAM 模型以来，OAM 模型以及 KubeVela 我的项目已被阿里、Oracle、Salesforce、腾讯、字节跳动、网易游戏等 40+ 家不同行业的当先企业应用在理论生产环境，帮忙他们在不同场景下实现更高效的云原生利用的交付和治理。
瞻望
KubeVela 我的项目倒退也十分迅速，至今曾经累计有上百位开发者参加奉献，社区有上百万的镜像下载。2021 年 7 月，KubeVela 和 OAM 我的项目也曾经整体捐献给 CNCF 基金会托管，所以这也是一个齐全中立的社区。KubeVela 在社区用户中的大规模实际，也正在促成 OAM 成为混合云 / 多云 / 分布式云畛域利用交付的事实标准，并在阿里、微软、Oracle Cloud、腾讯等多家国内外厂商中被采纳。2021 年 5 月，以 OAM 模型为外围的《云计算凋谢利用架构》标准文件也曾经由阿里云和信通院等 10 余家单位联结发动并在“云原生产业大会”现场公布。
随着 v1.2 版本的公布，将来 KubeVela 将更多的提供端到端的残缺用户体验，丰盛更多垂直场景下的能力，朝着开发者可能自助实现利用交付的方向演进，让混合环境下的利用交付就像咱们明天应用 App Store 一样简略。
您能够通过如下资料理解更多对于 KubeVela 以及 OAM 我的项目的细节：
我的项目代码库：github.com/oam-dev/kubevela 欢送 Star/Watch/Fork！
我的项目官方主页与文档：kubevela.io，从 1.1 版本开始，已提供中文、英文文档，更多语言文档欢送开发者进行翻译。
我的项目钉钉群：23310022；Slack：CNCF #kubevela Channel