最新要闻
- dotnetfx35无法安装_dotnetfx35
- 游客手机掉西湖被要1500元打捞费 景区:简单打捞不收费-全球观察
- 员工朋友圈未发广告被罚1万且开除:法院判赔5万 当前短讯
- 印度捷行航空申请破产 原因想不到:普惠发动机故障太多-视点
- 【e公司观察】原料涨价 锂电行业为何振奋不已?|当前看点
- 四川自贡一餐厅吃饭收15元空调费 店家:相当于雅间费-全球今头条
- 各主要高速公路、国省道干线交通总体安全顺畅 最新消息
- 有钱人为何在意电动车电费?李想用超级富豪朋友习惯解释原因-全球讯息
- 环球速看:格科微: 格科微有限公司关于公司实际控制人、董事长、首席执行官提议公司回购股份的公告
- 上海妍秀国际医疗美容诊所医生以及擅长项目推荐
- 报道:上半年最后一个假 端午节放3天:假期后需连上6天班
- 《街霸6》新角色韩蛛俐介绍片:疯美人脚法了得-全球观天下
- 最新快讯!三星宣布多款旧设备停止更新支持
- 清仓特价 森马板鞋/运动鞋39元起、T恤29元起-要闻速递
- 今日快讯:又一个小米6钉子户消失 米粉给妈妈换小米13 雷军点赞
- “广州市十佳科普使者”出炉|全球观察
手机
iphone11大小尺寸是多少?苹果iPhone11和iPhone13的区别是什么?
警方通报辅警执法直播中被撞飞:犯罪嫌疑人已投案
- iphone11大小尺寸是多少?苹果iPhone11和iPhone13的区别是什么?
- 警方通报辅警执法直播中被撞飞:犯罪嫌疑人已投案
- 男子被关545天申国赔:获赔18万多 驳回精神抚慰金
- 3天内26名本土感染者,辽宁确诊人数已超安徽
- 广西柳州一男子因纠纷杀害三人后自首
- 洱海坠机4名机组人员被批准为烈士 数千干部群众悼念
家电
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 应用正常处理主要流程如下:
- 用户通过 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%+,具体取决于每个应用程序需要保留的资源数量。
优化前后的状态保持时间消耗
参考链接:
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%的性能优化,此时优化了应用程序控制器的运行。
参考链接:
- https://github.com/kubevela/kubevela/pull/5598
- 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
Informercache减少
默认的 controller-runtime informer 将缓存我们在控制器中使用的所有结构化对象。对 KubeVela 而言,这些对象是Application,ApplicationRevision,ResourceTracker 和 ConfigMap。通过控制器分片,KubeVela 能够将Application,ApplicationRevision 和 ResourceTracker 的缓存分成不同的分片。但随着应用程序的不断更新,累积的ApplicationRevision 会通过 informer cache 占用大量内存,尽管它们并不经常使用且内部有大量重复数据。因此,为了优化 informer cache 的大小,我们采取了以下几种方法。
1.在将 managedFields 和 kubectl.kubernetes.io/last-applied-configuration 存储在 informer 中时,需要删除 managedFields 和 kubectl.kubernetes.io/last-applied-configuration。特别是对于复杂应用程序,它们可能会很大。它们或许对于 Kubernetes apiserver 和 CLI 工具很有用,但控制器中并不需要。因此在存储到缓存之前,我们需要在控制器中将它们删除。
2.通过共享 ComponentDefinition、TraitDefinition 和 WorkflowStepDefinition 的存储空间来减少 ApplicationRevision 的内存使用量。大多数应用程序在系统中仅仅使用几个常见定义,如 webservice 或 scaler。这些定义分别存储在 ApplicationRevisions 中,并占用了大量空间。因此,在应用程序控制器中,我们设置了一个横向公共缓存,并让这些 ApplicationRevisions 指向存储在公共缓存中的定义,从而减少内存使用。
KubeVela的informercache 架构
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. 实验
多个分片
设置
KubeVelav1.8.0支持controllersharding [5],允许 KubeVela 控制平面进行水平扩展。它通过利用 ListWatch 请求中的标签选择器来实现,controller-runtime 将其用作 KubeVela 应用程序控制器后端。它不仅限制了每个分片要处理的应用程序数量,还通过分割减少了内存缓存的大小。
控制器分片的架构
为了验证 KubeVela 控制器的多个分片可以按预期工作,我们比较了以下三种情况性能:
- 单个分片,使用0.5 核、1 Gi 内存。
- 三个分片,每个分片使用0.5 核、1 Gi 内存。
- 使用 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。
总结
综上所述,我们通过这个实验得出以下结论:
- 与 v1.7.5 相比,v1.8.0 的性能有了很大的优化。
- 部署多个分片可以横向增加系统的应用容量,并且不会引入太多的开销。
具有持续更新的大型应用程序
设置
虽然之前的负载测试主要集中在应用程序的交付上,但在生产案例中,我们看到用户不断升级带有数十个修订版本的应用程序。应用程序的持续更新是否会影响控制平面的稳定性仍然存在疑问。因此,我们进行了这个实验,在部署应用程序之后进行了几次更新。我们发现,在优化之前的 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 倍以上,但控制器的性能仅略有下降。
总结
总之,我们从实验中得知以下几点:
- 在标准控制器设置下,KubeVela 控制器能够容纳 3000 个大型应用程序并对其进行持续更新。
- 应用程序的更新速度比创建速度慢,它会消耗更多的计算资源。
- 与小型应用程序相比,大型应用程序对 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 会持续关注整个系统的底层性能,并确保它始终能够为应用程序交付提供稳定、快速的功能。
您可以通过如下材料了解更多关于 KubeVela 以及 OAM 项目的细节:
- 项目代码库:https://github.com/kubevela/kubevela欢迎 Star/Watch/Fork!
- 项目官方主页与文档:kubevela.io,从 1.1 版本开始,已提供中文、英文文档,更多语言文档欢迎开发者进行翻译。
- 项目钉钉群:23310022;Slack:CNCF #kubevela Channel
相关链接:
CNCF 官网的英文博客原文地址:https://www.cncf.io/blog/2023/04/12/stability-and-scalability-assessment-of-kubevela/
[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]controllersharding
https://kubevela.net/docs/platform-engineers/system-operation/controller-sharding
点击此处查看KubeVela项目官网
关键词:
KubeVela 稳定性及可扩展性评估_环球微动态
随机造数据的技巧总结
dotnetfx35无法安装_dotnetfx35
游客手机掉西湖被要1500元打捞费 景区:简单打捞不收费-全球观察
员工朋友圈未发广告被罚1万且开除:法院判赔5万 当前短讯
印度捷行航空申请破产 原因想不到:普惠发动机故障太多-视点
环球聚焦:appuploader 入门使用
环球快看点丨1、etcd基础介绍
【实变函数】01 - 更合理的积分
每日信息:关于如何使用pandas将不同的数据写入到同一个Excel的不同Sheet表中
【世界新视野】1159 Structure of a Binary Tree + 根据前序和中序构建二叉树+ 层序遍历模板复习
【e公司观察】原料涨价 锂电行业为何振奋不已?|当前看点
四川自贡一餐厅吃饭收15元空调费 店家:相当于雅间费-全球今头条
各主要高速公路、国省道干线交通总体安全顺畅 最新消息
热讯:写几行代码,了解响应式原理
第139篇:JS数组常用方法(map(),reduce(),foreach())
83.赋值运算符
IMF:中国将成为今年亚太地区经济增长关键驱动因素
有钱人为何在意电动车电费?李想用超级富豪朋友习惯解释原因-全球讯息
环球速看:格科微: 格科微有限公司关于公司实际控制人、董事长、首席执行官提议公司回购股份的公告
【2023 · CANN训练营第一季】昇腾AI入门Pytorch
世界微动态丨23 网络数据在内核中流转
ZooKeeper 避坑指南: ZooKeeper 3.6.4 版本 BUG 导致的数据不一致问题
5月3日全国铁路迎来返程客流高峰 预计发送旅客1935万人次 世界独家
上海妍秀国际医疗美容诊所医生以及擅长项目推荐
报道:上半年最后一个假 端午节放3天:假期后需连上6天班
《街霸6》新角色韩蛛俐介绍片:疯美人脚法了得-全球观天下
Bash—source命令&export命令&bashrc文件
最新快讯!三星宣布多款旧设备停止更新支持
清仓特价 森马板鞋/运动鞋39元起、T恤29元起-要闻速递
今日快讯:又一个小米6钉子户消失 米粉给妈妈换小米13 雷军点赞
22 URL到网卡:网络数据流动
“广州市十佳科普使者”出炉|全球观察
五一余额不足 最后一天返程现场排长队 网友:凌晨出门照堵不误
“插队婆孙”被做成恶搞表情包:如此“网暴”是否合适?
【全球聚看点】OpenAI API keys 的申请和测试小结
母子争吵儿子走丢 机场民警15分钟帮找到孩子|播资讯
【世界速看料】最便宜的16GB显存显卡出现了!AMD、NVIDIA统统靠边站
焦点报道:苹果、谷歌起草追踪设备行业规范:打击滥用定位功能
当前短讯!实惨!男子拍演唱会:激光导致手机摄像头直接报废
Realme 11 Pro+ 5G 曝光 在5月10日发布
66元的的钟薛高在东北只要3.8元一根!商家回应
开眼!丰田为混动车申请“手动挡”专利:只为保留驾驶乐趣 环球热推荐
游客停车31小时被收640元:明码标价 但已退还
Blazor学习之旅系列总结目录
国铁集团郑州局预计3日客流创历史新高
小学生写人作文开头结尾集锦_小学生写人作文-观速讯
【天天时快讯】阿维塔定金72小时内可退成空话 店长:“已锁单”
汽车盗窃案上升548% 纽约市免费发放500个苹果AirTag应对
【当前独家】 男子吐槽在景区停车场一路捡到26个螺丝钉 官方回应
青海省西宁市城西区西川南路消防救援站站长助理玛尼坚——磨砺技能 守护平安(劳动者之歌)
多地消费市场见闻
世界资讯:客户抛弃雷克萨斯LM来买 腾势D9 4月销量10526辆
19.99万元期待落空 打价格战的特斯拉为何突然涨价:利润下滑
观速讯丨Intel AVX-512指令集要回来!残血版?AMD正尽情享受
世界最资讯丨艾玛·沃森曝光新写真 透露2024年开拍新电影
24小时不打烊,365天对外接待……“临汾好办”不要太方便! 环球播资讯
每日热文:前缀和
可怜的欧美!RTX 3070上市两年半 终于破发|今头条
环球头条:雷蛇噬魂鲨极速版耳机发布:50mm驱动单元、30小时续航
别只会“王者峡谷五日游” 这几款游戏才是假期最佳解
每日关注!4月新能源销量:比亚迪、埃安、理想全线杀疯
全球要闻:巨亏236亿元!三星内存、闪存要减产25%
天天热头条丨“天空之城”游人如织
学系统集成项目管理工程师(中项)系列16b_风险管理(下)
世界观点:4年来首次下滑 AMD发布Q1季度财报:锐龙处理器成重灾区
五菱缤果营销比亚迪海豚话术曝光:颜值高、空间大
【速看料】五一后机票价格暴跌 飞三亚从2800降到280元 专家表态:很正常
联合国秘书长:呼吁以色列停止行政拘留的做法|全球观焦点
python图像处理库
Java读取数据库表
世界今热点:徊的拼音_徊怎么组词
流媒体时代谋生艰难!好莱坞编剧15年来将首次罢工
为何插电混动车主爱在外充电 理想高管分析:薅羊毛感觉爽
当前资讯!司机等红绿灯时看手机被罚200扣3分 车是静止状态:网友吵翻 但事实没错
NV一代神卡卷土重来!Steam新报告:RTX 40降价仍没存在感_当前热议
五一想在户外看电影、选购投影仪一定要注意这几点
浙商证券研究所所长助理陈杭离职:否认网传800万年薪,专心处理舆论_世界热资讯
81.数组 全球热门
Win11“颠覆性”功能被遗弃:失效三个月仍被微软无视
嘴硬还是明智?丰田高管:电动汽车技术不成熟、混动才实用
同花顺ai机构活跃度指标公式源码_活跃度100
Android-图片压缩(二)-纯干货
C# 常量 结构体 委托 热门看点
喝的二五八万是什么意思_二五八万是什么意思
性能达SteamDeck两倍!华硕ROG Ally掌机先行开箱来了
奇葩!插队发飙者称是换队 网友吐槽发飙发泼有理:景区称仍算插队
天天热议:手机就能跑!开源AI机器人MLC LLM发布:无需联网
喜欢玩手机 那就活该单身
沃尔沃首款全电动汽车现已准备好接触其首批英国客户
降价伤人伤己?特斯拉国内外突然涨价背后:实为去库存|每日短讯
ChatGPT导致信息泄露后:三星将开发内部AI工具
女子淄博吃烧烤排不上队被投喂饱 山东太热情:人民日报点赞
11.迷宫问题(BFS 储存路径)
哈弗的新款Boxy SUV由前路虎设计师设计|世界球精选
韩国大学生吃掉天价香蕉艺术品 称是行为艺术!原作者回应了 每日速读
焦点快报!最高热效率达44%:五菱柳机自研高热效发动机点火成功
私拆承重墙高楼已加固 居民称胆真大:多层裂纹被掩盖 还敢住吗
坏账损失核算方法有_坏账损失核算方法 世界即时看
卖不动很无奈?NVIDIA对RTX 4090官降:今年第三次了