Karmada大规模测试报告发布：突破100倍集群规模( 四 ) _生活百科

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对大规模集群的优化。一般来说，用户可以根据使用场景选择不同的部署模式，通过参数调优等手段来提升整个多集群系统的性能。