81 lines
7.1 KiB
Markdown
81 lines
7.1 KiB
Markdown
---
|
||
title: KubeVela 简介
|
||
slug: /
|
||
---
|
||
|
||
## 什么是 KubeVela？
|
||
|
||
KubeVela 是一个开箱即用的现代化应用交付与管理平台，它使得应用在面向混合云环境中的交付更简单、快捷。使用 KubeVela 的软件开发团队，可以按需使用云原生能力构建应用，随着团队规模的发展、业务场景的变化扩展其功能，一次构建应用，随处运行。
|
||
|
||
|
||
|
||
|
||
## 为什么要用 KubeVela？
|
||
|
||
云原生技术的发展趋势正在朝着利用 Kubernetes 作为公共抽象层来实现高度一致的、跨云、跨环境的的应用交付而不断迈进。然而，尽管 Kubernetes 在统一底层基础架构细节方面表现出色，它并没有在混合的分布式部署环境之上提供应用层的软件交付模型和抽象。我们已经看到，这种缺乏统一上层抽象的软件交付过程，不仅降低了生产力、影响了用户体验，甚至还会导致生产中出现错误和故障。
|
||
|
||
然而，为现代微服务应用的交付过程建模是一个高度碎片化且充满挑战的事情。到目前为止，绝大多数试图解决上述问题的技术方案，要么过于简单以致于无法覆盖实际生产使用中的问题，要么过于复杂难以落地使用。云原生带来的基础设施能力爆发式增长也决定了新一代的应用管理平台不能以硬编码的方式做能力的集成和 UI 的构建，除了满足基础的功能和场景，平台本身的扩展能力成为了新时代应用管理平台的核心诉求。这就意味着平台不仅要简单易用，还要能够随着应用交付和管理的需求复杂度提升能够不断扩张，能够让开发者自助式的接入和使用，充分享受云原生生态的红利。
|
||
|
||
这也是 KubeVela 出现的核心价值：它既能够简化面向混合环境（多集群/多云/混合云/分布式云）的应用交付过程；同时又足够灵活可以随时满足业务不断高速变化所带来的迭代压力。它本身是一个面向混合交付环境同时又高可扩展的应用交付引擎，满足平台构建者的扩展和自建需求；同时又附加了一系列开箱即用的扩展组件，能够让开发者自助式的开发、交付云原生应用。
|
||
|
||
|
||
## KubeVela 核心功能
|
||
|
||
- **统一的应用交付模型**
|
||
|
||
KubeVela 创新性的提出了 [开放应用模型（OAM）](https://oam.dev/)来作为应用交付的顶层抽象，该模型支持交付任意类型的工作负载包括容器、数据库甚至是虚拟机到不同的云和 Kubernetes 集群中。用户无需关心任何基础设施细节，只需要专注于定义和部署应用即可。应用只需要一次编排，就可以随处运行，免去了适配不同平台的痛苦。
|
||
|
||
- **声明式交付工作流**
|
||
|
||
KubeVela 的整个交付模型完全是由用户声明式驱动的，兼顾用户体验和健壮性。实现层通过 [CUE 语言](https://cuelang.org/)（一种源自 Google Borg 系统的数据配置语言）保证可扩展性，运行在 Kubernetes 持续进行控制循环。这使得你可以自由的根据需求场景来设计和选用交付工作流中的每一个步骤，满足业务快速增长的需求，同时持续保证生产环境面向终态的稳定性。
|
||
|
||
- **多集群/混合云应用交付控制平面**
|
||
|
||
KubeVela 原生支持丰富的多集群/混合环境持续交付策略，也支持跨环境交付。它既可作为统一的持续交付控制平面增强现有 CI/CD 流水线，也可以满足现代 GitOps 应用交付的趋势与要求，以基础设施即代码（IaC）的方式来驱动持续交付过程。
|
||
|
||
|
||
## KubeVela 与其他软件形态对比
|
||
|
||
### KubeVela vs. CI/CD 系统（如 GitHub Actions，GitLab，Jenkins 等）
|
||
|
||
KubeVela 是一个工作在 CI 流程下游的 CD 控制平面（Continuous Delivery Control Plane）。所以 KubeVela 希望你保持现有的 CI 流程，而在需要开始制品部署时让 KubeVela 接管 CD 流程。KubeVela 会给你的 CD 流程带来大量的现代化应用交付最佳实践，比如：声明式交付工作流、可编程的工作流步骤、Pull 模型、多云/多集群交付流程、统一的云服务部署和绑定等等。
|
||
|
||
如果你已经在 CD 环节中采纳了 GitOps 实践，KubeVela 会更容易跟你的 CI/CD 系统集成，因为 KubeVela 是完全声明式的。只需要把 KubeVela 的应用部署描述文件放置在你的配置仓库当中，所有的 KubeVela 特性（包括声明式交付工作流、多云/多集群交付流程等）就会立刻在你 的 GitOps 流程中出现。
|
||
|
||
> 欢迎查阅用户手册来了解更多关于 KubeVela 与[各类 CI/CD 系统](./tutorials/jenkins)以及 [GitOps](./case-studies/gitops) 模式协作的实践.
|
||
|
||
### KubeVela vs. GitOps ( 如 ArgoCD，FluxCD 等)
|
||
|
||
KubeVela 并不会替换你的 GitOps 流程，它帮助你在这之上构建一个统一的控制平面，以便增强 GitOps 的能力。
|
||
|
||
* KubeVela 提供跨集群、跨云、跨环境交付的能力，它在单集群会采用诸如 FluxCD 这样的 GitOps 工具作为驱动。
|
||
* KubeVela 提供了一层用户友好的交付模型，这使得你不会被锁定，你可以灵活切换、扩展底层的实现而不需要改变上层的应用制品。
|
||
|
||
### KubeVela vs. PaaS 平台 ( 如 Heroku，Cloud Foundry 等 )
|
||
|
||
传统 PaaS 提供完整的应用程序部署和管理功能，旨在提高开发人员的体验和效率。在这个场景下，KubeVela 也有着相同的目标。
|
||
|
||
不过，KubeVela 和它们最大的区别在于其**可扩展性**。
|
||
|
||
KubeVela 是可编程的。它的交付工作流乃至整个应用交付与管理能力集都是由独立的可插拔模块构成的，这些模块可以随时通过编写 CUE 模板的方式进行增/删/重定义且变更会即时生效。与这种机制相比，传统的 PaaS 系统的限制非常多：它们需要对应用类型和提供的能力进行各种约束来实现更好的用户体验，但随着应用交付需求的增长，用户的诉求就一定会超出 PaaS 系统的能力边界。这种情况在 KubeVela 平台中则永远不会发生。
|
||
|
||
此外，KubeVela 是一个独立于运行时集群的应用交付控制平面（这是我们认为的下一代 PaaS 系统的合理形态），而现有的 PaaS 则往往选择以插件形式部署在运行时集群当中。
|
||
|
||
### KubeVela vs. Helm
|
||
|
||
Helm 是 Kubernetes 的包管理器，它能够以 Chart 为一个单元，提供打包、安装和升级的一组 YAML 文件的能力。
|
||
|
||
KubeVela 作为一个应用交付系统天然可以部署各种制品类型，Kustomize、Kubernetes Yaml 等，当然也包括 Chart。Helm 可以便捷的把 Chart 交付到一个集群，KubeVela 可以帮你把 Chart 交付到多个集群。
|
||
|
||
当然，KubeVela 还支持其他制品格式比如 Kustomize。
|
||
|
||
### KubeVela vs. Kubernetes
|
||
|
||
KubeVela 是一个基于云原生技术栈构建的现代应用交付系统。它利用了开放应用程序模型（Open Application Model）和 Kubernetes 作为控制平面来解决一个旷日已久的难题——如何让应用交付变得更加轻松愉快。
|
||
|
||
## 下一步
|
||
|
||
接下来，我们推荐你：
|
||
|
||
- 开始 [安装使用 KubeVela](./install)。
|