共计 3002 个字符，预计需要花费 8 分钟才能阅读完成。
简介：KubeVela 就是这样一个面向用户的下层平台我的项目。对于业务开发者来说，KubeVela 简略、易用，它能够让开发者以极低的心智累赘和上手老本在 Kubernetes 上定义与部署利用 … 但更重要的是，对于平台团队来说，KubeVela 可不是一个简略的 PaaS 或者 Serverless，它是一个可能以 Kubernetes 原生的形式进行任意扩大的 PaaS 内核，平台工程师能够基于它构建出任意的垂直业务零碎。
作者：KubeVela 社区
2021 年 6 月 22 日，在云原生计算基金会（CNCF）的 TOC 例会上投票决定通过，KubeVela 正式成为 CNCF 官网沙箱我的项目。通明、凋谢、开源中立的 KubeVela，将来将继续致力于打造对立、规范、跨云的利用治理和交付体验。
“KubeVela 就是这样一个面向用户的下层平台我的项目。对于业务开发者来说，KubeVela 简略、易用，它能够让开发者以极低的心智累赘和上手老本在 Kubernetes 上定义与部署利用 … 但更重要的是，对于平台团队来说，KubeVela 可不是一个简略的 PaaS 或者 Serverless，它是一个可能以 Kubernetes 原生的形式进行任意扩大的 PaaS 内核，平台工程师能够基于它构建出任意的垂直业务零碎。”
张磊，CNCF TOC Member
KubeVela 我的项目地址：ttps://github.com/oam-dev/kubevela
我的项目介绍
云原生技术正在以 Kubernetes 作为通用形象层，朝着跨云谋求统一的利用交付迈进。Kubernetes 尽管在底层根底构造细节形象方面表现出色，但带来了额定的复杂性。基于 Kubernetes 打造的各类 PaaS 林立却又互不相通，导致服务利用开发的平台团队，没有一个适合的框架来构建用户敌对且高度可扩大的形象。与此同时，混合云、多云、分布式云这些日益简单的业务场景中，利用交付也在逐步变得碎片化。
用 Go 语言开发的利用交付引擎 KubeVela，能帮咱们克服以上所有难题。作为 OAM（Open Application Model）在 Kubernetes 上的实现，KubeVela 我的项目从 oam-kubernetes-runtime 演进至今，发展势头十分迅猛，不仅间断登上 GitHub Go 语言趋势榜首和 HackerNews 首页，更是迅速播种了包含 MasterCard、Springer Nature、第四范式、SILOT、Upbound 等来自世界各地、不同行业的终端用户，甚至还呈现了像 Oracle Cloud、Napptive 等基于它构建的商业化产品。就在 2021 年 3 月底，KubeVela 社区发表蕴含所有稳定版 API 的 v1.0 版本 公布，正式开始向企业级生产可用迈进。
KubeVela 技术架构图
外围思路
对于平台开发人员而言，KubeVela 作为框架，通过执行以下操作来加重构建以开发人员为核心的平台的懊恼：
- 以开发人员为核心。KubeVela 通过引入 Application 的概念来形象基础架构级别的原语，从而捕捉微服务的残缺部署，而后依据应用程序的需要构建操作性能。
- 本地扩大。Application 由模块化的构建块组成，这些构建模块反对 CUELang【1】和 Helm【2】作为模板引擎。这使你可能以乐高格调形象 Kubernetes 的性能，并通过简略的 kubectl apply -f 将它们公布给最终用户。对形象模板所做的更改将在运行时失效，无需从新编译或重新部署 KubeVela。
- 简略而牢靠的形象机制。与大多数 IaC(基础设施即代码)解决方案不同，KubeVela 中的形象是用 Kubernetes Control Loop【3】构建的，所以它们永远不会在集群中留下配置漂移。作为 Kubernetes 自定义资源【4】，KubeVela 能够与任何 CI/CD 或 GitOps 工具无缝合作，不须要进行集成工作。
有了 KubeVela，平台构建者终于有了工具反对，能够设计易于应用的形象，并以高信念和低周转工夫将它们交付给终端用户。
对于终端用户 (例如应用程序开发人员) 来说，这种用 KubeVela 构建的形象将使他们可能以起码的致力设计并向 Kubernetes 公布应用程序 —他们要做的只是定义一个简略的应用程序，能够轻松地与任何 CI/CD 集成，而不须要治理一些基础设施细节。
更进一步，KubeVela 目前典型的利用场景有很多，比方：
- SasS 软件云端托管
- 面向混合云 / 分布式云的利用 PaaS
- 面向混合环境的 DevOps 平台，包含多集群 / 多环境 CD/CD 等
将来瞻望
为了更好的满足云原生下利用交付的更加疾速、多变和简单等业务需要个性，KubeVela 将遵循以下的 Roadmap 进一步演进：
- 目前 Component 接入须要通过 CUE 来实现对接转换。接下来，咱们打算对已有的体系做更好的反对 — 这包含已有的 Helm Chart、Kustomize 目录、Terraform Module 可能间接接入成为 Component。以 Helm Chart 为例，它的 values.schema.json 将对接成为 properties，输入的资源等同于 helm template 渲染后的后果。
- 增加环境初始化 (Initializer) 的能力，为开发团队提供公共的部署环境，比方集群、零碎 Operators & CRDs、公共服务 (Load Balancer, VPC, DB) 等。
- 增加面相利用公布过程的 Workflow 能力，让用户能够定义面向过程的运维命令。所有内置运维操作也将往 Workflow 方向革新，包含 apply resources、灰度降级、流量治理、多集群等。同时也会新增配置差异化、数据传递等新性能。同时 Workflow 能力整体设计是可插拔的，用户能够实现本人的能力（比方说灰度公布）来增加或替换。
- Vela 零碎部署上提供 standalone 模式，不须要 K8s 作为运行时底座，能够在单个容器 /VM 外面运行起来，适应一些比较复杂的管控部署环境。
- 用户体验这一侧，velacp 我的项目将去除 mongodb 依赖而转为间接应用 CRD 做存储。增加更多的垂直场景，实现端到端一键交付能力，产出 App Profile 这种可被分享复用的场景制品解决方案。
- 跟 CICD 零碎做更好的集成，包含 Github Actions、Jenkins 等，可能让用户实现 git push 就将利用公布进来。
2021 年 5 月 26 日，由阿里云计算有限公司、中国信息通信研究院等 10 余家单位联结发动的《云计算凋谢利用架构》标准文件在“云原生产业大会”现场公布。该架构以阿里云、微软云联结发动的开源我的项目“凋谢利用架构模型（Open Application Model，以下简称 OAM）”为实现根底，旨在为云端利用管理者提供对立的利用形容标准及凋谢应用程序能力治理框架，以期推动简洁、高效、可控的云原生利用治理与交付形式在更多行业和企业中的大规模落地。
咱们能够看到作为 KubeVela API Specification 的 OAM 正在汇聚行业共识，KubeVela 社区目前也在 GitHub 上取得 2.2k+ Star 认可，吸引到 3+ Maintainer、85+ Contributor 共建，以及 SheIn、滴普、谐云和风变科技等泛滥用户开始使用 KubeVela 在生产环境上。
原文链接
本文为阿里云原创内容，未经容许不得转载。
