1000万云上开发者，全栈云产品0元试用：点击 免费试用 ，即刻开启云上实践之旅！

【资料图】

作者：殷达

背景

随着 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 应用正常处理主要流程如下：

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

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

如何配置高性能和鲁棒的 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+），并且您不需要对不同的应用程序进行隔离（例如按租户对他们进行分组），则不一定需要此步骤来实现高性能。

KubeVela 控制器分片架构

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

如何进行负载测试

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

在 Kubernetes 集群上设置 KubeVela 控制平面后，您可以尝试负载测试，查看您的 KubeVela 控制平面配置是否能满足您的业务需求。您可以根据使用场景从以下步骤开始。

1. 【可选】设置 kubemark 来模拟 Kubernetes 节点 。KubeVela 与 Kubernetes 集群的节点数无关，但如果你想尝试并验证这一点，可以使用 kubemark 模拟 Kubernetes 节点，这样允许你在不实际运行的情况下持有大量的 Pod。

a.每个 kubemark pod 都会向 Kubernetes apiserver 注册一个空节点，并将自己注册为一个节点，在此节点上分配的 Pod 不会实际执行，而是伪装自己正在运行。

b.你需要为这些空节点附加标签，并为负载测试创建的 Pod 设置节点亲和性。否则，它们可能会被分配到真实节点并实际运行，这将在负载测试期间产生巨大工作量，你应该避免这种情况。

c.你还应将污点附加到这些空节点，并为负载测试创建的 Pod 添加污点容忍。这样是为了防止将其他 Pod 分配到这些虚假节点上。例如，如果你在 Kubernetes 集群中将 Prometheus 服务器作为 Pod 运行以构建可观观测性，当它们被分配到空节点时，则不会实际运行，你将一无所获。

d.通常，一个 Kubernetes 集群中的每个节点最多可容纳数百个 Pod（这个数字在不同的配置中也有所不同），因此我们建议不要在每个空节点上运行太多的 Pod。20~40 个 Pod /节点可能是一个不错的选择。根据你想在负载测试中测试的 Pod 数量，应计算所需的空节点数。然后请记住，每个空节点都需要一个真正的 kubemark pod 来运行，因此您需要进一步估计运行一定数量的 kubemark pods 需要多少个真实节点。

e.结论：KubeVela 对一个集群的 1 千个空节点进行了负载测试，并验证了这个数字不会影响 KubeVela 的运行。有关更多实验细节，请参阅报告 [3] 。

2. 【可选】设置 k3d/KinD 以模拟托管集群 。KubeVela 与加入到控制平面的集群数也无关，除非您有超过数千个 Kubernetes 集群可供使用。如果您想验证这个事实，你可以设置 k3d 集群或 KinD 集群来模拟托管集群，并将它们加入到你的 KubeVela 控制平面。

a.托管集群使用的主要组件是 apiserver 和 etcd 。如果您不需要同时验证多个 pod 或节点的数量，则只需少量资源即可运行模拟的托管集群。就像您可以在 128 核 256 Gi 服务器上运行 200 多个 k3d 集群，并将它们加入到 KubeVela 控制平面中。

b.您可以为这些已加入的集群附加标签，并在应用程序交付期间测试选择集群的性能。例如，为每 5 个集群分配一个区域 ID。

c.托管集群上不会有实际负载运行（因为 KubeVela 主要关心应用交付，因此在多集群负载测试期间，我们主要调度零副本部署、configmaps 和 secrets）。但网络很重要，集群网关和托管集群的 apiserver 之间将有大量网络请求。因此，最好确保它们之间有足够的网络带宽和相对适中的延迟。否则，您将观察到网络 IO 速率限制。

d.结论：KubeVela 还对 200 个集群进行了负载测试，这些集群被均匀分布在 40 个区域。结果表明，控制平面能够以适当的配置处理这些集群上的应用程序。下面将进一步详细阐述。

3. 使用脚本交付大量应用程序 。有一个关于使用官方脚本部署负载测试应用程序的简单指南 [4] 。这些脚本会自动在多个并发线程中部署多个应用程序。它包含多个要设置的环境变量，包括要读取的应用程序模板、应用程序版本、应用程序的分片 ID 和集群 ID 等。您可以为负载测试创建自己的应用程序模板，并使用脚本进行实验。KubeVela 使用该脚本测试各种示例应用程序，并获取负载测试统计数据。

Part 02. 性能优化

在 KubeVela v1.8 中，我们添加了几种优化方法来提高应用程序控制器的性能。这些方法是通过实验完成的。

状态保持并行化

在 KubeVela v1.8 之前，应用程序的状态保持阶段，应用背后的资源是以逐一的状态保存的。我们将并行化添加到这个过程中，最大并发数为 5 。这会将状态保持的性能提高约 30%+，具体取决于每个应用程序需要保留的资源数量。

优化前后的状态保持时间消耗

剩余60%，完整内容请点击下方链接查看：

版权声明：本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。