Karmada 的架构集成了 Kubernetes 架构的简洁性和扩展性 。Karmada-apiserver 作为控制面的入口与 Kubernetes 的 kube-apiserver 类似 。你可以使用单集群配置中所需的参数优化这些组件 。
在整个资源分发过程中,API 调用时延在一个合理的范围 。
集群注册与资源分发在 Karmada 1.3 版本中,我们提供了基于 Bootstrap tokens 注册 Pull 模式集群的能力 。这种方式不仅可以简化集群注册的流程,也增强了集群注册的安全性 。现在无论是 Pull 模式还是 Push 模式,我们都可以使用 karmadactl 工具来完成集群注册 。与 Push 模式相比,Pull 模式会在成员集群运行一个名为 karmada-agent 的组件 。
集群注册时延包含了控制面收集成员集群状态所需的时间 。在集群生命周期管理的过程中,Karmada 会收集成员集群的版本,支持的 API 列表以及集群是否健康的状态信息 。此外,Karmada 会收集成员集群的资源使用量,并基于此对成员集群进行建模 , 这样调度器可以更好地为应用选择目标集群 。在这种情况下,集群注册时延与集群的规模息息相关 。上述指标展示了加入一个 5,000 节点的集群直至它可用所需的时延 。你可以通过关闭集群资源建模[2]来使集群注册时延与集群的大小无关,在这种情况下,集群注册时延这个指标将小于 2s 。
不论是 Push 模式还是 Pull 模式,Karmada 都以一个很快的速度来下发资源到成员集群中 。唯一的区别在于 karmada-controller-manager 负责所有 Push 模式集群的资源分发,而 karmada-agent 只负责它所在那一个 Pull 模式集群 。因此, 在高并发条件下发资源的过程中,Pull 在相同配置条件下会比 Push 模式更快 。你也可以通过调整 karmada-controller-manager 的--concurrent-work-syncs的参数来调整同一时间段内并发 work 的数量来提升性能 。
Push 模式和 Pull 模式的资源使用量对比在 Karmada 1.3 版本中 , 我们做了许多工作来减少 Karmada 管理大型集群的资源使用量 。现在我们很高兴宣布,相比于 1.2 版本 , Karmada 1.3 在大规模场景下减少了 85% 的内存消耗和 32% 的 CPU 消耗 。总的来说, Pull 模式在内存使用上有明显的优势,而在其他资源上相差的不大 。
在 Push 模式中,控制面的资源消耗主要集中在 karmada-controller-manager , 而 karmada-apiserver 的压力不大 。
文章插图
从 karmada-apiserver 的 qps 以及 karmada-etcd 的请求时延我们可以看出 karmada-apiserver 的请求量保持在一个较低的水平 。在 Push 模式中,绝大多数的请求来自 karmada-controller-manager 。你可以配置--kube-api-qps and --kube-api-burst这两个参数来控制请求数在一个确定的范围内 。
在 Pull 模式中,控制面的资源消耗主要集中在 karmada-apiserver,而不是 karmada-controller-manager 。
文章插图
从 karmada-apiserver 的 qps 以及 karmada-etcd 的请求时延我们可以看出 karmada-apiserver 的请求量保持在一个较高的水平 。在 Pull 模式中 , 每个成员集群的 karmada-agent 需要维持一个与 karmada-apiserver 通信的长连接 。我们很容易得出:在下发应用至所有集群的过程中 karmada-apiserver 的请求总量是是 karmada-agent 中配置的 N 倍(N=#Num of clusters) 。因此,在大规模 Pull 模式集群的场景下,我们建议增加 karmada-apiserver 的--max-requests-inflight以及--max-mutating-requests-inflight参数的值 , 和 karmada-etcd 的--quota-backend-bytes参数的值来提升控制面的吞吐量 。
现在 Karmada 提供了集群资源模型[3]的能力来基于集群空闲资源做调度决策 。在资源建模的过程中,它会收集所有集群的节点与 Pod 的信息 。这在大规模场景下会有一定的内存消耗 。如果你不使用这个能力,你可以关闭集群资源建模[4]来进一步减少资源消耗 。
总结与展望根据测试结果分析,Karmada可以稳定支持100个大规模集群,管理超过50万个节点和200万个Pod 。
在使用场景方面,Push模式适用于管理公有云上的Kubernetes集群 , 而Pull模式相对于Push模式涵盖了私有云和边缘相关的场景 。在性能和安全性方面,Pull模式的整体性能要优于Push模式 。每个集群由集群中的karmada-agent组件管理,且完全隔离 。但是,Pull模式在提升性能的同时,也需要相应提升karmada-apiserver和karmada-etcd的性能,以应对大流量、高并发场景下的挑战 。具体方法请参考kubernetes对大规模集群的优化 。一般来说,用户可以根据使用场景选择不同的部署模式,通过参数调优等手段来提升整个多集群系统的性能 。
推荐阅读
- 红魔6SPro游戏测试_红魔6SPro游戏表现
- 1分钟完成在线测试部署便捷收集班级同学文件的web管理系统
- 小米Civi续航怎么样_小米Civi续航测试
- 荣耀Magic3Pro续航测试_荣耀Magic3Pro续航怎么样
- 红米note10pro发热严重吗_红米note10pro发热测试
- 四 【单元测试】Junit 4--Junit4参数化
- 三 【单元测试】Junit 4--Junit4断言
- 二 【单元测试】Junit 4--eclipse配置Junit+Junit基础注解
- python渗透测试入门——取代netcat
- 二 【性能测试】Loadrunner12.55-飞机订票系统-脚本录制