Karmada大规模测试报告发布:突破100倍集群规模( 五 )


关注点分离:资源模板和策略Karmada 使用 Kubernetes 原生 API 来表达集群联邦资源模板,使用可复用的策略 API 来表达集群的调度策略 。它不仅可以让 Karmada 能够轻松集成 Kubernetes 的生态, 同时也大大减少了控制面的资源数量 。基于此,控制面的资源数量不取决于整个多集群系统集群的数量,而是取决于多集群应用的数量 。
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大规模测试报告发布:突破100倍集群规模

文章插图
从 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大规模测试报告发布:突破100倍集群规模

文章插图
从 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参数的值来提升控制面的吞吐量 。

经验总结扩展阅读