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

我们将一个多集群的资源池规模按优先级描述为以下所示的三个维度：

Num of Clusters: 集群数量是衡量一个多集群系统资源池规模和承载能力最直接且最重要的维度，在其余维度不变的情况下系统能接入的集群数量越多，说明系统的资源池规模越大，承载能力越强。
Num of Resources(API Objects): 对于一个多集群系统的控制面来说，存储并不是无限制的，而在控制面创建的资源对象的数量和总体大小受限于系统控制面的存储，也是制约多集群系统资源池规模的重要维度。这里的资源对象不仅指下发到成员集群的资源模板，而且还包括集群的调度策略、多集群服务等资源。
Cluster Size: 集群规模是衡量一个多集群系统资源池规模不可忽视的维度。一方面，集群数量相等的情况下，单个集群的规模越大，整个多集群系统的资源池越大。另一方面，多集群系统的上层能力依赖系统对集群的资源画像，例如在多集群应用的调度过程中，集群资源是不可或缺的一个因素。综上所述，单集群的规模与整个多集群系统息息相关，但单集群的规模同样不是制约多集群系统的限制因素。用户可以通过优化原生的Kubernetes组件的方式来提升单集群的集群规模，达到扩大整个多集群系统的资源池的目的，但这不是衡量多集群系统性能的关注点。本次测试中，社区参考了kubernetes的大规模集群的标准配置以及测试工具的性能，制定了测试集群的规模，以贴切实际生产环境中的单集群配置。在集群的标准配置中，Node与Pod毫无疑问是其中最重要的两个资源，Node是计算、存储等资源的最小载体，而Pod数量则代表着一个集群的应用承载能力。事实上，单集群的资源对象也包括像service，configmap，secret这样的常见资源。这些变量的引入会使得测试过程变得更复杂，所以这次测试不会过多关注这些变量。

Num of Nodes
Num of Pods

对于多集群系统而言想要无限制地扩展各个维度而且又满足 SLIs/SLOs 各项指标显然是不可能实现的。各个维度不是完全独立的，某个维度被拉伸相应的其他维度就要被压缩，可以根据使用场景进行调整。以 Clusters 和 Nodes 两个维度举例，在 100 集群下将单集群的 5k 节点拉伸到 10k node 的场景或者在单集群规格不变的同时扩展集群数量到 200 集群，其他维度的规格势必会受到影响。如果各种场景都进行测试分析工作量是非常巨大的，在本次测试中，我们会重点选取典型场景配置进行测试分析。在满足 SLIs/SLOs 的基础上，实现单集群支持 5k 节点，20k pod规模的100数量的集群接入和管理。
SLIs/SLOs可扩展性和性能是多集群联邦的重要特性。作为多集群联邦的用户，我们期望在以上两方面有服务质量的保证。在进行大规模性能测试之前，我们需要定义测量指标。在参考了 Kubernetes 社区的 SLI(Service Level Indicator)/SLO(Service Level Objectives)和多集群的典型应用，Karmada 社区定义了以下 SLI/SLO 来衡量多集群联邦的服务质量。