7.3 KiB
| title | slug |
|---|---|
| KubeVela 简介 | / |
背景
云原生技术的发展趋势正在朝着利用 Kubernetes 作为公共抽象层来实现高度一致的、跨云、跨环境的的应用交付而不断迈进。然而，尽管 Kubernetes 在屏蔽底层基础架构细节方面表现出色，它并没有在混合与分布式的部署环境之上引入上层抽象来为软件交付进行建模。我们已经看到，这种缺乏统一上层抽象的软件交付过程，不仅给降低了生产力、影响了用户体验，甚至还会导致生产中出现错误和故障。
然而，为现代微服务应用的交付过程进行建模是一个高度碎片化且充满挑战的事情。到目前为止，绝大多数试图解决上述问题的技术方案，要么过于简化而不足以解决实际问题，要么过于复杂以至于几乎无法落地。另一方面，今天的很多应用管理平台主要专注在 UI 和集成上工作，平台本身的能力其实很有限且难以扩展，这意味着随着应用交付需求的增长，用户诉求超出此类系统的能力边界只是一个时间问题。
今天，越来越多的应用研发团队期盼着这样一个平台：它既能够简化面向混合环境（多集群/多云/混合云/分布式云）的应用交付过程；同时又足够灵活可以随时满足业务不断高速变化所带来的迭代压力。然而，尽管平台团队很希望能帮上忙，但构建这样一个面向混合交付环境同时又高可扩展的应用交付系统，着实是一项令人生畏的任务。
什么是 KubeVela？
KubeVela 是一个开箱即用的、现代化的应用交付与管理平台。KubeVela 通过以下设计，使得面向混合/多云环境的应用交付变得非常简单高效：
- 完全以应用为中心 - KubeVela 创新性的提出了开放应用模型（OAM）来作为应用交付的顶层抽象，并通过声明式的交付工作流来捕获面向混合环境的微服务应用交付的整个过程，甚至连多集群分发策略、流量调配和滚动更新等运维特征，也都声明在应用级别。用户无需关心任何基础设施细节，只需要专注于定义和部署应用即可。
- 可编程式交付工作流 - KubeVela 的交付模型是利用 CUE 来实现的。CUE 是一种诞生自 Google Borg 系统的数据配置语言，它可以将应用交付的所有步骤、所需资源、关联的运维动作以可编程的方式粘合成一个 DAG（有向无环图）来作为最终的声明式交付计划。相比于其他系统的复杂性和不可扩展性，KubeVela 基于 CUE 的实现不仅使用简单、扩展性极强，也更符合现代 GitOps 应用交付的趋势与要求。
- 运行时无关 - KubeVela 是一个完全与运行时基础设施无关的应用交付与管理控制平面。所以它可以按照你定义的工作流与策略，面向任何环境交付和管理任何应用组件，比如：容器、云函数、数据库，甚至 AWS EC2 实例等等。
什么情况下该学习、使用 KubeVela ？
- 云原生时代的应用研发人员、DevOps 开发者：KubeVela 基于 Kubernetes 提供了大量开箱即用的能力，提供了围绕应用开发者的平台体验，无需学习复杂概念即可满足大多数通用场景的需求。
- 云原生应用平台的构建者、PaaS 服务提供商、基础设施平台管理员：KubeVela 基于 Kubernetes 提供了大量编排和扩展能力，能够 100% 满足任意的扩展需求，交付任意形态的应用制品。
- 第三方软件供应商（ISV）、垂直领域应用开发者：KubeVela 可以帮助你构建标准化的软件交付物，交付到任意云厂商和 Kubernetes 数据中心。
架构图
KubeVela 的整体架构如下图所示：
控制平面
正如项目名字所暗示的那样，KubeVela 依靠 Kubernetes 作为应用交付与管理控制平面的核心实现。这个机制是 KubeVela 在大规模应用交付场景中保证自动化和确定性的关键所在。用户只需要通过以应用程序为中心的 API 与平台进行交互，然后 KubeVela 就会根据用户声明的策略、规则和工作流，将应用分发到目标基础设施运行起来，并始终确保这个状态的成功。
运行时基础设施
运行时基础设施是应用程序实际运行的地方。 KubeVela 允许你将应用程序交付到任何平台比如公有云、私有云、本地环境或者 Kubernetes 集群（本地、托管产品或 IoT/边缘）上。KubeVela 本身不运行在这些基础设施当中，并且与它们完全解耦。
产品形态对比
KubeVela vs. 平台即服务 (PaaS)
典型的例子是 Heroku 和 Cloud Foundry。 它们提供完整的应用程序部署和管理功能，旨在提高开发人员的体验和效率。在这个情况下，KubeVela 也有着相同的目标。
不过，KubeVela 和它们最大的区别在于其可扩展性。
KubeVela 对待交付应用没有任何限制，它的整个应用交付与管理能力集也是由独立的可插拔模块（CUE 模块）构成的，这些模块可以随时通过编写 CUE 模板的方式进行增加或者定制。与这种机制相比，传统的 PaaS 系统的限制非常多：它们需要对应用类型和提供的能力进行各种约束来实现更好的用户体验，但随着应用交付需求的增长，用户的诉求就一定会超出 PaaS 系统的能力边界。这种情况在 KubeVela 平台中则永远不会发生。
KubeVela vs. Serverless
AWS Lambda 等 Serverless 平台可以为 Serverless 应用管理提供极佳的用户体验和敏捷性。然而，这些平台本质上也带来了更多限制，它们可以说是 PaaS 的一类极端情况，同 KubeVela 的区别也是类似。
另一方面，KubeVela 可以轻松部署任何函数类型的组件，包括基于 Kubernetes 的 Serverless 工作负载（例如 KNative/OpenFaaS 函数）或云函数（例如 AWS Lambda）。
KubeVela vs. 跨平台开发者工具
典型的例子是 Hashicorp 的 Waypoint。 Waypoint 是一个面向开发者的应用部署工具，它引入了一个一致的工作流（即构建、部署、发布）来模拟在不同平台上交付应用程序的过程。
KubeVela 可以与此类工具无缝集成。在这种情况下，开发人员将使用 Waypoint 工作流作为平台的 UI，然后通过 KubeVela 来完成跨混合环境的应用部署、管理和发布。
KubeVela vs. Helm
Helm 是 Kubernetes 的包管理器，它能够以 Chart 为一个单元，提供打包、安装和升级的一组 YAML 文件的能力。
KubeVela 作为一个应用交付系统天然可以部署各种制品类型，当然也包括 Helm Chart。 例如，你可以使用 KubeVela 定义一个由 WordPress Chart 和 AWS RDS 实例组成的应用，编排这两个组件之间的顺序关系，然后将它们按照一定的策略分发到多个 Kubernetes 集群当中。
当然，KubeVela 还支持其他制品格式比如 Kustomize。
KubeVela vs. Kubernetes
KubeVela 是一个基于云原生技术栈构建的现代应用交付系统。它利用了开放应用程序模型（Open Application Model）和 Kubernetes 来解决一个旷日已久的难题——如何让应用交付变得更加轻松愉快。
下一步
现在，让我们开始安装使用 KubeVela！