共计 4843 个字符，预计需要花费 13 分钟才能阅读完成。
自 2020 年 OAM（Open Application Model）凋谢利用模型公布以来，KubeVela 经验了数十个版本的更新和演变，朝着现代化利用交付的高级性能一直倒退。明天，咱们将回顾 KubeVela 我的项目倒退至今的亮点性能和核心技术。
什么是 KubeVela？
KubeVela 是一个面向现代化利用的交付与治理平台，它使得利用在面向混合、多云环境中的交付和运维变得更简略、高效和牢靠。它有以下三个次要性能：
- 基础设施无关
KubeVela 可能将你的云原生应用程序部署到各种目的地，如 Kubernetes 多集群、不同的云平台和边缘设施。
- 可编程
KubeVela 具备用于建模应用程序和交付过程的形象层。这些形象层容许用户应用可编程形式构建更高级别的可重用模块，用于应用程序交付，并在 KubeVela 零碎中集成任意第三方我的项目（如 FluxCD、Crossplane、Istio、Prometheus）。
- 以利用为核心
KubeVela 面向业务利用开发专门设计，有丰盛的工具生态，包含 CLI、UI、GitOps、可观测性等，为应用程序的交付和运维减少了大量开箱即用的性能。
KubeVela 关注应用程序的整个生命周期，包含 Day-1 交付和 Day-2 运维阶段。它可能连贯各种继续集成工具，如 Jenkins 或 GitLab CI，并帮忙用户在混合环境中交付和运维应用程序。
为什么抉择 KubeVela？
艰难和挑战
现在，快速增长的云原生基础设施为用户部署应用程序提供了越来越多的能力，如高可用性和安全性，但也间接向应用程序开发人员裸露了越来越多的复杂性。
例如，Kubernetes 上的 Ingress 资源使用户可能轻松地对外裸露服务，但开发人员须要解决 Ingress 降级，当底层 Kubernetes 版本发生变化时，这须要对 Ingress 资源有肯定的理解。在各种云供应商之间进行混合部署可能会使这个问题变得更加艰难。
Open Application Model（凋谢利用模型）
为了应答上述挑战并弥合应用程序应用和基础设施细节了解之间的差距，阿里云和微软 Azure 在 2020 年独特提出了凋谢利用模型（OAM）。其目标是为应用程序交付定义一个统一的应用程序模型，与平台和实现无关。
定义的应用程序模型为开发人员形容了应用程序由什么组成以及工作形式的接口。前者被称为 OAM 中的组件，通常用于对应用程序的工作负载进行建模。后者被定义为 OAM 中的个性，它为组件提供附加额定的性能。
作为 OAM 的 KubeVela
KubeVela 是（OAM）Open Application Model 的实现之一。在 KubeVela 中，形象层由 CUE 反对，这是一种新鲜的配置编程语言，能够形容简单的渲染逻辑，它在应用层面与 JSON 统一，是 JSON 的超集。形象层简化了 Kubernetes 中资源的配置，暗藏了实现的细节，并仅向业务开发人员裸露无限参数。应用 KubeVela 应用程序，开发人员能够轻松地专一于应用程序的核心逻辑，例如应该应用哪个容器镜像以及如何拜访服务。
为了实现这一指标，应用 Kubernetes 原生资源的最佳实际被总结到 KubeVela X-Definitions 中，并应用 CUE 提供资源的渲染模板。这些模板能够从各种起源拜访，包含官网存储库、社区插件甚至零碎运营商的自定义实现，这些模板大多与基础设施实现无关，应用这些模板时，开发人员不须要理解底层基础设施构造。
组件和特色
应用程序模型将基础设施的形象分为两个不同的方面。组件形容了次要的工作负载，特地是在 Kubernetes 中能够是部署、StatefulSets、Helm Release 等。另一方面，特征描述了次要工作负载的附加性能，例如指定正本数的缩放器特色，网关特色聚合用于拜访的端点。组件和特色设计中的关注点拆散为形象提供了高度的可扩展性和可重用性。
例如，网关个性能够由不同的基础设施（如 Ingress 或 HTTPRoute）进行后端解决。应用该个性的应用程序开发人员只需关怀公开的参数，包含门路、端口和域名。该个性能够附加到各种类型的工作负载，由不同类型的组件进行形象，例如 Deployment、StatefulSet、CloneSet 等。
对于利用开发人员和 SRE 处于不同团队的状况下，KubeVela 为他们的责任做了明确的分工。
- 提供基础设施的平台团队负责构建 X-Definitions，以施行最佳实际和晋升部署信念。
- 最终用户只需抉择平台团队提供的组件和特色，并应用它们来组装应用程序。他们能够简略地享受相似 PaaS 的体验，而不是间接与基础设施进行交互。
得益于 KubeVela 的灵便、可扩大和可编程的零碎，这些都能够利用在不同的环境中。
对立交付
应用程序交付能够产生在任何中央。因而，KubeVela 应用程序的另一个指标是构建对立的交付，并在各种场景下为用户提供统一的应用。
混合云和多集群
除了形象层之外，KubeVela 还原生反对混合云或多集群架构，因为古代云原生利用不仅波及容器，还波及大量云资源。此外，越来越多的用户和团队开始面临将应用程序交付到各种环境或多集群以实现用于不同目标的艰难，例如测试或高可用性。
KubeVela 应用程序容许用户通过策略定义交付指标和差异化配置。形象层有助于暗藏集群如何注册和连贯的详细信息，并为应用程序开发人员提供与运行时无关的用法。
插件集成
为了丰盛交付能力，用户能够利用 KubeVela 插件集成来扩大他们的零碎。这些插件是可发现、可重用且易于装置的性能包。它们通常蕴含性能提供程序，包含宽泛的第三方我的项目，如 FluxCD、ClickHouse、Crossplane 等。插件不仅将这些我的项目装置到零碎中，还能同时为集成创立相应的定义，从而扩大了应用程序开发人员可能应用的组件和个性类型。
目前，KubeVela 社区曾经领有 80 多个插件。平台构建者能够依据其定制需要在零碎中享受这些开箱即用的集成。
通过启用零碎中的插件，最终用户能够以更自定义的形式组装应用程序，例如部署云资源或应用高级工作负载。
KubeVela 工作流
尽管凋谢利用模型定义了应用程序的组成，但在理论状况下，组成部分的交付过程依然可能有很大的差别。例如，一个应用程序中的不同组件可能具备相互依赖或数据传递，其交付步骤必须按特定程序执行。此外，交付过程有时还波及除资源交付之外的更多操作，例如降级或告诉。
因而，一个可扩大的工作流被设计了进去，以满足 KubeVela 中流程定制的需要。
与组件和特色一样，KubeVela 工作流程也利用 CUE 来定义工作流程步骤，提供了灵活性、可扩展性和可编程性。它能够被视为基础设施即代码（IaC）的另一种模式。
在 KubeVela 中，曾经提供了一系列内置的工作流程步骤，这些步骤提供了丰盛的开箱即用的性能，例如进行多集群部署，通过 Slack 或电子邮件发送告诉等。与波及运行额定容器的其余类型引擎相比，轻量级引擎确保了步骤执行的高性能和安全性。
与 KubeVela 中的组件和特色定义不同，工作流步骤定义不会将模板渲染成资源。相同，它形容了在步骤中要执行的操作，该操作调用各种提供程序中的底层原子函数。
通过应用工作流程和插件，用户能够构建任意交付流程并进行定制集成。例如，能够让继续集成工具触发 KubeVela 应用程序的交付，并实现联合 FluxCD 和其余插件的 GitOps 解决方案。
Day-2 治理
KubeVela 不仅关注 Day-1 的交付，还提供了一个对立的 Day-2 应用程序治理能力，以满足其可扩展性的需要。Day-2 治理对于零碎运维人员和应用程序开发人员来说是很有必要的，以便对交付的应用程序进行继续的运维，并确保应用程序始终处于可控状态。
资源管理
应用程序治理的根本能力是针对其资源的。KubeVela 的外围控制器一直监督交付资源的以后状态和所需状态之间的差别。它确保实时标准与交付流程记录的申明标准统一，从而无效地避免任何配置漂移。
此外，主动垃圾回收有助于回收降级或删除期间未应用的资源。有时还须要在多个应用程序之间共享资源。这些都是通过应用策略在 KubeVela 应用程序中实现的。
版本控制
KubeVela 应用程序会为交付记录保留历史记录。当新版本公布后果不合乎预期时，这些快照十分有用。更改查看能够用于诊断可能的谬误更改，回滚容许疾速复原到先前胜利的状态。
可观测性
KubeVela 将可观测性视为一等公民。它是用户监督应用程序状态和察看异样的眼睛。KubeVela 中有多个工具和办法能够执行察看工作。其中最间接的办法之一是应用 KubeVela 的 CLI 工具。Vela CLI 可能以细粒度或聚合级别为应用程序提供及时状态信息。
对于偏爱 Web 界面的用户，VelaUX 提供了另一种查看应用程序状态的办法。
在通过第三方我的项目（如 Grafana、Prometheus 或 Loki）监控应用程序的状况下，KubeVela 进一步提供了用于疏导可察看性基础设施的插件，并使用户可能通过形象层将察看规定自定义应用程序中的代码。
一系列开箱即用的指标和仪表板为用户提供了自动化零碎可观测的基本功能。这些可用于诊断系统级异样并帮忙进步整体性能。
生态系统
除了上述工具之外，KubeVela 生态系统中还有几个其余工具来促成应用软件交付和治理。
- Vela CLI
KubeVela CLI 提供了多种命令，可帮忙您操作应用程序，例如治理定义、查看资源、重新启动工作流、滚动版本等。
- VelaUX
VelaUX 是 KubeVela 的 Web UI。此外，它还将业务逻辑整合到根本的 API 中，并为非 k8s 专家用户提供开箱即用的用户体验。
- Terraform Controller
KubeVela 中的 terraform 控制器容许用户通过 Kubernetes 自定义资源应用 Terraform 治理云资源。
- Cluster Gateway
提供对立的多集群拜访接口的网关。作为 Kubernetes 聚合 API 服务器，网关利用本地身份验证和受权模块，并强制执行对托管集群的平安通明拜访。
- VelaD
建设在 k3s 和 k3d 之上，VelaD 将 KubeVela 与 Kubernetes 外围集成在一起，对于构建开发 / 测试环境十分有用。
- Vela Prism
KubeVela 扩大 API 服务器，基于 Kubernetes 聚合 API 服务构建。它将原生 API (如在 Grafana 上创立仪表板) 投射成 Kubernetes 资源 API 中，以便用户能够将第三方 API 作为 Kubernetes 原生资源进行治理。
- Vela Workflow
是一个独立的工作流引擎，它作为一个纯正的交付工具，能够交付多个 KubeVela 利用或连接其余零碎实现对立 CI/CD。与 Tekton 相比，它更轻量，对于根本的配置交互和数据传递次要通过 CUE 引擎执行，而不是依赖 Pod 和 Job 运行。
稳定性
为了确保 KubeVela 可能在无限资源下解决肯定数量的应用程序，咱们在各种状况下进行了屡次负载测试。试验表明，KubeVela 零碎的性能可能在一般大小的集群中解决数千个应用程序。可观性基础设施进一步裸露了 KubeVela 的瓶颈，疏导零碎运维人员进行定制调整，以晋升特定应用环境中下性能。
总结
目前，KubeVela 曾经被来自不同畛域的 300 多家企业应用于生产环境。有些用户次要应用 KubeVela 的形象能力来简化利用的应用和部署。有些用户在 KubeVela 上构建以利用为核心的管理系统。有些用户应用自定义的工作流程来编排交付流程。它在互联网、金融、电商、智能制作、AI 等畛域特地受欢迎，并被证实对于交付和治理大型利用十分有帮忙。
KubeVela 社区曾经吸引了来自寰球的贡献者，并在过来两年中一直发展壮大。现在，来自不同国家的 200 多名贡献者曾经参加了 KubeVela 的开发提出了数千个问题，其中 85% 曾经失去解决。此外，英语和中文社区还定期举办双周社区会议。
作者：殷达（晖树）
原文链接
本文为阿里云原创内容，未经容许不得转载。
