关于云计算: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+），并且您不须要对不同的应用程序进行隔离（例如按租户对他们进行分组），则不肯定须要此步骤来实现高性能。

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%+，具体取决于每个应用程序须要保留的资源数量。

优化前后的状态放弃工夫耗费

参考链接：https://github.com/kubevela/kubevela/pull/5504

为列表操作索引 AppKey

通过对 5 万多个应用程序的利用控制器进行 pprof 监督，咱们发现大部分 CPU 工夫都花在列举 ApplicationRevisions 和 ResourceTrackers 上。

KubeVela 外围控制器 CPU 应用状况火焰图

这是因为当咱们须要为一个应用程序查找这些资源时，咱们用标签选择器选出相匹配的资源。但在控制器运行时 controller-runtime 的 informer 下，这是通过匹配每个对象的标签来实现的。咱们通过为缓存增加额定的索引来优化它，这大大减少了列出应用程序和资源跟踪器所需的工夫老本。对于单列表操作，工夫老本从 40 毫秒降至 25 微秒，这是优化前状态放弃的一个瓶颈。

优化前和优化后的对账指标

参考链接：https://github.com/kubevela/kubevela/pull/5572

过滤不必要的更新

当一个应用程序达到稳固状态（已公布且没有进行中的更新或删除）时，每个协调操作的次要工作是探测底层资源并检测意外的偏移。通常，配置偏移不总是产生，因而咱们不须要向底层资源发送空的补丁申请。咱们察看到这能够将协调工夫缩短 20%。

应用程序控制器和每个阶段的对账工夫

此外，咱们发现应用程序控制器的每次协调都会收回利用订正更新申请。然而，一旦工作流胜利执行，利用订正就不会更新。因而，这些更新申请无需删除这些申请就能够在负载测试期间将性能晋升 27%。

优化前（19:50 之前）和优化后应用程序控制器的对账工夫比照

相似的问题是，从 v1.6 开始降级工作流后，状态被压缩，但垃圾回收的执行没有被去重。因而，当删除反复的 gc 过程，应用程序进入稳固状态时，咱们进一步实现了 23% 的性能优化，此时优化了应用程序控制器的运行。

参考链接：

1. https://github.com/kubevela/kubevela/pull/5598
2. https://github.com/kubevela/kubevela/pull/5600

间接连贯到集群网关

在钻研将资源交付到托管集群的应用程序时，咱们会发现集群网关（cluster-gateway）成了另一个潜在的瓶颈。默认状况下，多集群申请是沿着 vela-core -> kubernetes apiserver (hub) -> cluster-gateway -> kubernetes apiserver (managed) 的流程进行。这是通过利用 Kubernetes 的聚合 API 机制实现的，咱们能够通过容许应用程序控制器间接与集群网关通信来进行优化。

KubeVela 的多集群连贯架构

这不仅能加重 Kubernetes apiserver 的累赘，还能缩小多集群申请的网络跳数。通过这种办法咱们缩小了 40% 的提早。

应用程序控制器的一个多集群申请提早从 11 毫秒降到 6 毫秒

参考链接：https://github.com/kubevela/kubevela/pull/5595

Informer cache 缩小

默认的 controller-runtime informer 将缓存咱们在控制器中应用的所有结构化对象。对 KubeVela 而言，这些对象是 Application，ApplicationRevision，ResourceTracker 和 ConfigMap。通过控制器分片，KubeVela 可能将 Application，ApplicationRevision 和 ResourceTracker 的缓存分成不同的分片。但随着应用程序的不断更新，累积的 ApplicationRevision 会通过 informer cache 占用大量内存，只管它们并不常常应用且外部有大量反复数据。因而，为了优化 informer cache 的大小，咱们采取了以下几种办法。

1. 在将 managedFields 和 http://kubectl.kubernetes.io/last-applied-configuration 存储在 informer 中时，须要删除 managedFields 和 http://kubectl.kubernetes.io/last-applied-configuration。特地是对于简单应用程序，它们可能会很大。它们或者对于 Kubernetes apiserver 和 CLI 工具很有用，但控制器中并不需要。因而在存储到缓存之前，咱们须要在控制器中将它们删除。

2. 通过共享 ComponentDefinition、TraitDefinition 和 WorkflowStepDefinition 的存储空间来缩小 ApplicationRevision 的内存使用量。大多数应用程序在零碎中仅仅应用几个常见定义，如 webservice 或 scaler。这些定义别离存储在 ApplicationRevisions 中，并占用了大量空间。因而，在应用程序控制器中，咱们设置了一个横向公共缓存，并让这些 ApplicationRevisions 指向存储在公共缓存中的定义，从而缩小内存应用。

KubeVela 的 informer cache 架构

3. 禁用 ConfigMap 的 informer cache。ConfigMap 的缓存是由 Workflow Context 引起的。应用程序工作流将运行上下文存储在 ConfigMap 中，但 ConfigMap 的缓存不仅蕴含工作流程应用的 ConfigMap，还包含其余未应用的 ConfigMap，这可能会占用大量空间。

优化前后的内存应用状况

在负载测试中，咱们发现这些办法联合在一起对内存应用状况进行了重大改良，特地是对于继续更新。以前的负载测试并不重点关注继续更新，但这会疏忽应用程序控制器中理论应用的缓存内存的减少。

Go 程序的内存应用状况并不简略。上述内存统计数据是操作系统报告的 RSS 大小。Go 程序的理论内存使用量小于此。Go 未应用的内存并不总是立刻返回给操作系统，并且存在内存碎片化，这将阻止它返回所有未应用的内存。因而，这里咱们还比拟了 Go 报告的 ALLOC 内存和 SYS 内存。ALLOC 内存能够视为理论应用的内存大小，SYS 内存示意 Go 从操作系统取得了多少内存。

通过 3000 个应用程序和 9000 个应用程序订正版本，咱们在优化之前失去了 1.02G 的 RSS，897M 的 SYS 和 401M 的 ALLOC。优化后，咱们失去了 739M 的 RSS，707M 的 SYS 和 203M 的 ALLOC。能够看到应用中的内存缩小了约 50%。总内存应用状况也缩小了约 25%。

参考链接：https://github.com/kubevela/kubevela/pull/5683

Part 03. 试验

多个分片

设置

KubeVela v1.8.0 反对 controller sharding[5]，容许 KubeVela 管制立体进行程度扩大。它通过利用 ListWatch 申请中的标签选择器来实现，controller-runtime 将其用作 KubeVela 应用程序控制器后端。它不仅限度了每个分片要解决的应用程序数量，还通过宰割缩小了内存缓存的大小。

控制器分片的架构

为了验证 KubeVela 控制器的多个分片能够按预期工作，咱们比拟了以下三种状况性能：

1. 单个分片，应用 0.5 核、1 Gi 内存。
2. 三个分片，每个分片应用 0.5 核、1 Gi 内存。
3. 应用 KubeVela v1.7.5 的单个分片，应用 0.5 核、1 Gi 内存。咱们在单个分片状况下测试了 3000 个小型应用程序（KubeVela 外围控制器的默认配置），在三个分片状况下测试了 9000 个小型应用程序（每个分片蕴含 3000 个应用程序，与单个分片状况雷同）。

剖析

试验表明，控制器分片能够横向扩大应用程序容量

与单个分片的状况相比，三个分片中每个分片的资源使用量类似

咱们能够看到，在应用三个分片时，每个分片可能解决 3000 个 应用程序且不会相互烦扰。在所有应用程序公布之后，每个分片的 RSS 内存使用量减少到 412 MiB，CPU 使用率为 0.1 核（均匀协调提早为 15 毫秒）。目前，该零碎总共蕴含 9000 个应用程序。与单个分片相比，分片模式下的内存使用量和 CPU 使用量绝对处于同一程度。运行 3000 个应用程序的单个分片，在所有公布之后应用大概 0.08 核，并应用 320 MiB 的内存。在应用分片和不应用分片之间也没有显著的 Reconcile 提早差别（公布后约 40〜50 毫秒，公布后为 10〜15 毫秒）。

v1.8.0 的性能比 v1.7.5 好得多

比照优化后的单分片案例与未优化的案例（v1.7.5），咱们能够看到均匀 Reconcile 工夫显著降落，特地是公布后的工夫老本（从 55ms 降至 16ms）。公布后的 CPU 使用率从 0.13 核降至 0.08 核。内存使用量从 676 MiB 缩小到 320 MiB。

总结

综上所述，咱们通过这个试验得出以下论断：

1. 与 v1.7.5 相比，v1.8.0 的性能有了很大的优化。
2. 部署多个分片能够横向减少零碎的利用容量，并且不会引入太多的开销。

具备继续更新的大型应用程序

设置

尽管之前的负载测试次要集中在应用程序的交付上，但在生产案例中，咱们看到用户一直降级带有数十个订正版本的应用程序。应用程序的继续更新是否会影响管制立体的稳定性依然存在疑难。因而，咱们进行了这个试验，在部署应用程序之后进行了几次更新。咱们发现，在优化之前的 v1.7.5 版本中，对应用程序的继续更新会导致 KubeVela 控制器的内存减少。这会使控制器更快地达到最大内存使用量。例如，部署 3000 个应用程序只用了大概 700 MiB，但将所有应用程序更新一次会使内存升至 900 MiB。将所有应用程序更新两次将导致控制器内存不足并解体。对于 v1.6 之前的版本来说，这种状况更糟，因为默认的应用程序订正版本限度很高，并且默认状况下零碎中保留了大量订正版本。解决这个问题有多办法，一种是将订正版本限度设置为较小的数字。从 v1.7.0 开始，这个数字被设置为 2，这意味着每个应用程序最多能够保留 2 个历史订正版本。KubeVela 在 v1.8.0 中实现的另一种办法是缩小内存耗费，特地是在继续更新期间减少内存使用量。如下面的章节所示，咱们能够留神到部署 3000 个轻量级应用程序的内存应用已大大减少。咱们测试了优化后的控制器性能，证实 0.5 核 1 Gi KubeVela 控制器能够解决 3000 个大型应用程序（每个应用程序带有 3 个部署、3 个密钥和 4 个配置映射）并继续更新。在试验中，咱们在 17:11 部署了 3000 个应用程序，并在大概 1 小时后实现了所有公布。（如果咱们减少负载测试客户端的部署速率，可能会更快。）而后咱们在 19:05、20:05、20:55、22:00、23:27 更新了所有的应用程序。请留神，每个应用程序的历史订正版本数量的默认设置为 2。因而，在前两次更新中，会生成新的应用程序订正版本，而在接下来的三次更新中，会创立新的订正版本并回收过期的订正版本。

剖析

应用程序更新比应用程序创立慢

应用程序的更新比部署须要更多的工夫，因为应用程序还须要解决过期资源的垃圾回收。因而，咱们察看到控制器队列的减少，但这并会不继续很长时间。应用程序的均匀工作流实现工夫依然放弃在 1 分钟以下。

在更新过程中 CPU 使用率很高，成为瓶颈。内存仅在前两次更新时减少（受 ApplicationRevision 的限度）

当咱们查看 KubeVela 控制器的资源应用状况时，咱们留神到在更新过程中，CPU 使用率已达到 0.5 核，这是使控制器工作变慢的次要起因之一。控制器只有在利用部署和状态放弃资源时才反对并行执行，但目前不反对并行垃圾回收（咱们心愿在将来增加）。控制器的内存使用量在第一次公布后达到了 470 MiB。在前两次更新后，它回升到 580 MiB 和 654 MiB。而后对于以下更新，它放弃在 690 MiB 左右（低于内存限度的 70%），并且没有进一步间断减少。Go 的内存分配机制不会立刻将未应用的内存返回给操作系统，也不是所有未应用的内存总是能够被返回。因而，内存的理论使用量（调配的内存）通常远低于常驻集大小。当 KubeVela 控制器的队列中有很高的负载和积攒时，内存使用量可能会一度很高，但不会继续上来。有些人可能会问，这样的应用程序模板真的足够大？确实，咱们曾经看到有用户在一个应用程序中调度了 50 多个 Kubernetes 资源，这至多比咱们在这里测试的应用程序的 5 倍。但均匀而言，宏大的应用程序只是整个零碎的一小部分，并且这里的测试将所有应用程序设置为雷同的大小。此外，如果咱们将这个试验与上一节中的测试（多分片中的单个分片案例）进行比拟，其中，咱们对 3000 个小应用程序（3 个资源）应用了雷同的控制器配置，咱们能够发现在这个试验中应用的应用程序大了 3 倍以上，但控制器的性能仅略有降落。

总结

总之，咱们从试验中得悉以下几点：

1. 在规范控制器设置下，KubeVela 控制器可能包容 3000 个大型应用程序并对其进行继续更新。
2. 应用程序的更新速度比创立速度慢，它会耗费更多的计算资源。
3. 与小型应用程序相比，大型应用程序对 KubeVela 控制器的性能影响不大。

多集群

设置

上述负载测试和 KubeVela 在历史上所做的所有负载测试都应用单集群架构来部署和管理应用程序。随着越来越多的用户开始在多个集群中管理应用程序，咱们想要理解 KubeVela 在多集群场景下的体现。因而，咱们设计了这个试验。在这个试验中，咱们也应用了 KubeVela 控制器的默认配置，0.5 核 1 Gi，并应用 v1.8.0 中的集群网关的默认配置（0.5 核 200 MiB）。除了将这些资源部署到近程集群之外，咱们还应用了小型应用程序模板（1 个部署，1 个配置映射和 1 个密钥）。咱们进行这个试验是为了测试跨地区的性能。KubeVela 的管制立体部署在日本东京，而托管集群则部署在中国杭州。咱们还比拟了 v1.8.0 和 v1.7.5 的性能。v1.7.5 的集群网关默认配置应用 0.1 核 200 MiB，因而为了进行偏心比拟，咱们将其改良为 v1.8.0 中给出的资源。

剖析

v1.7.5 和 v1.8.0 都能够解决 3k 个多集群应用程序，但 v1.8.0 的性能更好

v1.8.0 控制器发送申请更少且速度更快

咱们发现，在这两个版本中，KubeVela 都可能在近程集群中解决 3000 个应用程序和治理资源，但 KubeVela v1.8.0 的性能优于 v1.7.5，这要归功于咱们下面提到的优化。咱们发现 v1.7.5 的控制器队列放弃在高状态，这是因为较长的协调工夫引起的，这可能会使控制器对应用程序渐变的响应变慢。除了针对集群网关的优化外，所有其余针对单个集群状况的优化技巧在多集群状况下也同样实用。

多集群申请比单个集群申请慢得多，次要由管制立体和托管集群间的提早引起

与单集群状况下的 3000 个小型应用程序相比，在近程集群中部署资源可能会大大增加 KubeVela 控制器的工夫老本。从仪表盘中能够看出，控制器的申请提早均匀约为 77 毫秒（单集群状况下为 20 毫秒），而集群网关的提早均匀约为 72 毫秒，与集群间提早相比开销很小。

CPU 使用率和内存使用率没有差别

只管提早比单集群状况更大，但如果咱们看 KubeVela 控制器的计算资源应用状况，会发现 CPU 使用率和内存使用率并没有太大的差别。

总结

从这个试验咱们个别能够理解到以下几点：

1. 在多集群场景下，v1.8.0 KubeVela 的性能体现比 v1.7.5 好。

2. 在多集群场景下，KubeVela 控制器的内存耗费靠近单集群状况。

3.KubeVela v1.8.0 可能默认 解决包含单集群、大型应用程序、多集群部署、继续更新在内的 3k 个应用程序。

4. 如果托管集群与管制立体之间的提早较大，则 KubeVela 控制器的性能将会更差。

优化办法：

a. 通过减少 CPU、并发和 QPS/Burst，进步 KubeVela 控制器的并行性。

b. 缩小跨集群的提早。（查看网络带宽并确保没有速率限度）

大规模

设置

在测试了多集群和多个分片之后，咱们当初晓得 KubeVela 有能力解决跨集群的大量应用程序。咱们设计了一个大规模的负载测试，以验证通过适当的配置，单个 KubeVela 管制立体能够满足治理海量集群的须要。咱们通过 k3d 在 64 核 256 Gi 虚拟机（阿里云上的 ECS）上模仿了 200 个托管集群。对于管制立体，咱们应用了大型 ACK 集群（阿里云上的 Kubernetes），其中有 8 个（3 个主节点和 5 个工作节点）32 核 128 Gi 节点。咱们运行了 5 个分片控制器，每个分片控制器都有 8 核 32 Gi，32 个并发协调器，4000 QPS 6000 Burst。咱们又运行了另外 5 个集群网关，每个都有 2 核 1 Gi。请留神，咱们容许托管集群位于在同一个 VPC 中，并应用内网连贯。这将缩小管制立体和托管集群之间的提早，并减少最大网络吞吐量。咱们向零碎部署了 40 万个小型应用程序。它们的资源被平均分配到了 200 个集群中。

管制立体上运行的应用程序和控制器数量

剖析

这 40 万个应用程序的交付分为了几个阶段。首先，咱们部署了 2 万个应用程序，以查看是否一切正常，并查看是否存在任何潜在瓶颈。其次，咱们部署了另外 18 万个应用程序，以查看零碎是否可能承载 20 万个应用程序。最初，咱们将数量减少到 40 万。

随着多集群申请提早减少，控制器体现不佳。通过向集群网关增加更多 CPU 并打消 pod 间不均衡的工作负载来解决

当咱们部署了 20 万个应用程序时，控制器的性能开始降落，你会发现在大概 2:00 时，控制器队列开始回升，均匀和谐工夫大大增加。这是由 KubeVela 控制器的一个分片重新启动引起的，须要进一步考察。控制器自身的重启并没有影响应用程序的运行，但起初咱们发现 cluster-gateway pod 的负载没有平衡散布。大量负载集中在两个 cluster-gateway pod 上，导致它们的 CPU 使用率达到 90% 以上。这大大降低了多集群申请的吞吐量，导致应用程序协调迟缓。大概在 10:00，咱们留神到了该异样，并重新启动集群网关 pod 以进步它们的 CPU（4 核 1 Gi * 5），这解决了裸露的瓶颈。起初咱们又增加了另外 20 万个应用程序，响应提早始终很低。公布了 40 万个应用程序后，均匀和谐工夫（reconciliation time）为 70 毫秒，但在不同的分片间有所不同。一些分片具备较低的多集群申请提早，例如每个申请 15 毫秒，而其余分片的提早更高，可达 30 毫秒。起因还于集群网关的多个正本之间负载不均衡。但总的来说，如果您只有一个 cluster-gateway 正本，您将不会遇到此问题。

因为核心管制立体与托管集群之间的集群网关间接通过内网连贯，多集群申请与管制立体内申请具备类似的提早

同时值得注意的是，在这种大规模试验中，治理集群和管制立体彼此凑近，它们之间的流量传输也十分快。因而，与下面的多集群试验不同，咱们能够放弃与单集群状况类似的的低调谐工夫（reconciliation time）。

随着利用数量的减少，内存和 CPU 的使用率增长的速度比利用数量的增长慢得多

40 万个应用程序并不是 KubeVela 管制立体可包容的最大数量。每个控制器分片只应用了不到 20% 的 32 Gi 内存，CPU 使用率也远未满负荷。但因为在 hub Kubernetes 的 etcd 中存储了大量对象（Application、ResourceTracker、ApplicationRevision），因而 hub kube-apiserver 和其余原生组件（如 kube-controller-manager）开始应用大量计算资源，例如超过 90 Gi 的内存。零碎的瓶颈逐步落到 Kubernetes 自身。

为了进一步验证上述假如，咱们将 KubeVela 控制器的内存从每个分片 8 个 核 32 Gi 缩减到每个分片的 8 核 16 Gi（总共 5 个分 片），并应用一个具备 16 核 4 Gi 的单个集群网关副原本打消工作负载的不均衡。咱们将应用程序的数量减少到 50 万，发现所有分片都具备类似的性能。所有控制器分片的 CPU 和内存使用率均失常。控制器分片的工作队列为空，状态保留的均匀协调工夫均匀约为 60 毫秒。群集网关 Pod 的负载较高，但能够将多集群申请的均匀提早放弃在较低水平（23 毫秒）。

调整后所有分片的资源应用状况类似

当咱们将应用程序数量从 40 万减少到 50 万时，发现对账工夫没有显著减少

咱们认为，40 万 /50 万个应用程序的数量对于简直所有的 KubeVela 用户曾经足够大了，因而咱们在这里进行了试验。

总结

总之，这个大规模试验表明，在特定条件下，KubeVela 管制立体具备扩大和包容极大量应用程序的能力。

总结

通过一系列在不同场景下的试验，KubeVela v1.8.0 展现了其稳定性和可扩展性。与 v1.7.5 相比，其性能有相当大的晋升，这为零碎运维人员有信念让 KubeVela 治理大规模利用平台。当初，KubeVela 曾经倒退成为构建利用平台的综合解决方案。尽管进行的负载测试笼罩了 KubeVela 一些最风行的用例，但咱们也看到了 KubeVela 许多更高级的用法，比方输出 / 输入简单工作流、金丝雀公布、GitOps 等。依据用户应用 KubeVela 的形式，KubeVela 零碎的性能可能会暴露出不同的瓶颈。咱们总结了一些微不足道的解决方案，如下所示。

诊断系统性能瓶颈及解决办法

有时，整个利用零碎的瓶颈并不是 KubeVela 自身。例如，如果托管集群的响应速度迟缓或吞吐量无限，咱们能够进步 KubeVela 控制器的吞吐量，但控制器自身无奈缩小提早。因为插件带来的零碎可观测性，在大多数状况下，您能够在仪表板上找到零碎性能不佳的一些线索，并利用适当的策略进行优化。将来，KubeVela 会继续关注整个零碎的底层性能，并确保它始终可能为应用程序交付提供稳固、疾速的性能。

相干链接：

CNCF 官网的英文博客原文地址：https://www.cncf.io/blog/2023/04/12/stability-and-scalability…

[1] 参考文献

https://kubevela.net/blog/2021/08/30/kubevela-performance-test

[2] Grafana 仪表板

https://grafana.com/grafana/dashboards/18200-kubevela-system/

[3] 报告

https://kubevela.net/blog/2021/08/30/kubevela-performance-test

[4] 指南

https://github.com/kubevela/kubevela/tree/master/hack/load-test#use-of-application-bulk-deploy-scripts

[5] controller sharding

https://kubevela.net/docs/platform-engineers/system-operation…

作者：殷达

原文链接

本文为阿里云原创内容，未经容许不得转载。