KubeVela 稳定性及可扩展性评估

背景

随着 v1.8 的发布，基于 OAM 的应用程序交付项目 KubeVela 已经持续发展了 3 年多。目前已被各种组织采用并部署在生产环境中。无论是与托管定义一起使用还是在多个集群上进行管理，在单个 KubeVela 控制平面上运行数千个应用程序的情况并不少见。用户经常问的一个关键问题是 KubeVela 能否承载一定数量的应用程序。为了回答这个问题，KubeVela 进行了负载测试实验，制定了性能调优策略，并为关心 KubeVela 稳定性和可扩展性的用户总结了本指南，以供各位参考。

概述

若需要寻求一个基准，如下简要的表格仅供参考。

尽管以上数据可能因各种因素（如应用程序大小）而有所不同，但此基准适用于大多数常见场景。

历史

KubeVela 负载测试历史

KubeVela 过去进行了多次负载测试：

1. 2021 年 8 月对简单应用进行了负载测试。这次负载测试验证了节点数量不影响 KubeVela v1.0 的性能。它在一个拥有 1 千个虚拟节点和 1.2 万个应用程序的单个集群上进行了测试。这表明 Kubernetes apiserver 的速率限制是 KubeVela 核心控制器的瓶颈之一。目前为止，负载测试数据被视为标准基准。参考文献[1]。

它有以下几个限制：

a.不包括在 v1.1 中发布的多集群和工作流。

b.仅测试应用程序的创建和状态保持，忽略应用程序的持续更新。

2. 2022 年 2 月 v1.2 版本对基于工作流的应用程序（workflow-based application）进行的负载测试。此次负载测试主要侧重于如何在特定场景中微调应用程序控制器的性能，例如不需要 ApplicationRevision 的情况。开发几个可选的优化标志，并证明去掉某些功能以将性能提高 250% 以上。

3. 2022 年 8 月 v1.6 版本对工作流引擎（workflow engine）进行的负载测试。这次负载测试是在 KubeVela 将 cue 引擎从 v0.2 升级到 v0.4 时完成的。它主要发现了一些不必要的 cue 值初始化操作，这将导致额外的 CPU 使用成本。通过减少 75% 的 CPU 使用量进行修复。

4. 2023 年 2 月对 KubeVela v1.8 进行的负载测试，下面将详细介绍。本次负载测试在简单应用程序、大型应用程序、多个分片、多个集群、持续更新等多个场景下进行。同时应用了几种优化方法来处理一般情况。

全面指南

Part 01. 初期

KubeVela 应用的基本流程

KubeVela 应用的基本流程

KubeVela 应用通常是 KubeVela 生态系统中最常用的对象。它由 vela-core 内部的应用程序控制器处理，并将使用集群网关进行多集群交付。KubeVela 应用正常处理主要流程如下：

1. 用户通过 VelaCLI、kubectl、REST API、VelaUX 等向控制平面上的 Kubernetes apiserver 发送创建/更新/删除应用程序请求。
2. 请求发送到变异 Webhook 并验证 Webhook 以进行验证和字段自动填充。
3. 存储在 etcd 中的应用程序对象。vela-core 的 informer 接收到应用的创建/更新/删除事件，将其推送到队列中。
4. vela-core 的应用控制器观察事件并开始协调。
5. 对于新的应用程序，应用程序控制器会为其打上 Finalizer。
6. 控制器计算应用程序的当前版本并在集群中创建/更新它。
7. 控制器执行以工作流程为条件的工作流，运行状态维护和垃圾回收，最后，更新应用程序的状态。

应用程序工作流主要执行资源调度，为分析性能瓶颈并找到应对措施，因此有必要对整个处理流程进行概述。

如何配置高性能和鲁棒的 KubeVela？

除安装 KubeVela 之外，还有一些步骤建议用于设置高性能和鲁棒的 KubeVela 控制平面。请注意，这些步骤对于正常使用 KubeVela 并不是强制的，它们主要用于大规模场景，比如承载 2 千多个应用程序。

1. 启用可观测性插件。要全面了解您的 KubeVela 控制平面，强烈建议安装可观测性插件，包括 kube-state-metrics，prometheus-server 和 grafana。

a.如果您已拥有这些基础设施，并且它们不是由 KubeVela 插件构建的，则可以将 Grafana 仪表板[2]安装到您的 Grafana 中，并获取类似于 KubeVela 系统仪表板的内容。

KubeVela 系统仪表板

b.启用这些插件需要一些额外的计算资源，如 CPU 和内存。

2. 删除 Webhook。目前 KubeVela 的 Webhook 大大增加了应用程序变更请求的响应延迟。如果您已经安装了 KubeVela，请运行 kubectl delete mutatingwebhookconfiguration kubevela-vela-core-admission 和 kubectl delete validatingwebhookconfiguration kubevela-vela-core-admission 否则，添加 --set admissionWebhooks。

此步骤的负面影响包括以下几点：

a.无效应用程序在创建或更新期间不会被拒绝。相反，它将报告应用程序状态中的错误。

b.自动身份验证将会失效。替代方案是在应用程序应用时为其指定身份注释。

c.自动分片调度将会失效。替代方案是在应用程序应用时为其分配预定分片 ID。

3.【可选】启用 KubeVela 的多分片功能。通过使用 --set sharding.enabled=true 安装，并启用 vela-core-shard-manager 插件，可以运行多个分片（从 v1.8.0 开始）。通过分片，您可以对控制平面进行横向扩展，且不影响任何现有应用程序。

a.如果您在第 2 步中删除了 Webhook，则需要手动将应用程序的标签 controller.core.oam.dev/shard-id 设置为分片 ID（默认可以设置为 master 或 shard-0）。如果您没有删除 Webhook，应用程序将被平均分配。

b.vela-core-shard-manager 将使用相同的镜像、参数等从主分片中复制配置。如果您想使用不同参数，可以手动更改。

c.如果您没有大量的应用程序（10k+），并且您不需要对不同的应用程序进行隔离（例如按租户对他们进行分组），则不一定需要此步骤来实现高性能。

https://click.aliyun.com/m/1000371159/#云栖技术分享#。KubeVela 稳定性及可扩展性评估背景随着 v1.8 的发布，基于 OAM 的应用程序交付项目 KubeVela 已经持续发展了 3 年多。目前已被各种组织采用并部署在生产环境中。无论是与托管定义一起使用还是在多个集群上进行管理，在单个 KubeVela 控制平面

4.【推荐】如果可能，请在控制平面和托管的集群之间使用内网连接。建议参考此提示，但并不总是可行的。如果您的托管集群与 KubeVela 控制平面处于不同的网络区域（例如不同的地区或不同的云提供商），则无法执行此操作。内网带宽通常比互联网带宽更高，延迟也更低。因此，使用内网连接可以帮您获得更高的吞吐量和更快的跨集群请求响应速度。

如何进行负载测试

使用 KubeVela 进行负载测试的工具

在 Kubernetes 集群上设置 KubeVela 控制平面后，您可以尝试负载测试，查看您的 KubeVela 控