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

内存

Maximum Capacity: 512 GB

磁盘

Disk /dev/vda: 200 GiB, 214748364800 bytes, 419430400 sectors组件参数配置

karmada-apiserver

--max-requests-inflight=2000--max-mutating-requests-inflight=1000

karmada-aggregated-server

--kube-api-qps=200--kube-api-burst=400

karmada-scheduler

--kube-api-qps=200--kube-api-burst=400

karmada-controller-manager

--kube-api-qps=200--kube-api-burst=400

karmada-agent

--kube-api-qps=40--kube-api-burst=60

karmada-etcd

--quota-backend-bytes=8G测试执行在使用 Clusterloader2 进行性能测试之前，我们需要自己通过配置文件定义性能测试策略。我们使用的配置文件如下：
unfold me to see the yaml
name: testnamespace:number: 10tuningSets: - name: Uniformtinyqps qpsLoad: qps: 0.1 - name: Uniform1qps qpsLoad: qps: 1steps: - name: Create deploymentphases: - namespaceRange:min: 1max: 10 replicasPerNamespace: 20 tuningSet: Uniformtinyqps objectBundle: - basename: test-deployment objectTemplatePath: "deployment.yaml" templateFillMap:Replicas: 1000 - namespaceRange:min: 1max: 10 replicasPerNamespace: 1 tuningSet: Uniform1qps objectBundle: - basename: test-policy objectTemplatePath: "policy.yaml"# deployment.yamlapiVersion: apps/v1kind: Deploymentmetadata:name: {{.Name}}labels:group: test-deploymentspec:replicas: {{.Replicas}}selector: matchLabels:app: fake-podtemplate:metadata:labels:app: fake-podspec:affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: typeoperator: Invalues: - fake-kubelettolerations: - key: "fake-kubelet/provider"operator: "Exists"effect: "NoSchedule"containers: - image: fake-podname: {{.Name}}# policy.yamlapiVersion: policy.karmada.io/v1alpha1kind: PropagationPolicymetadata:name: testspec: resourceSelectors: - apiVersion: apps/v1kind: Deploymentplacement: replicaScheduling: replicaDivisionPreference: Weighted replicaSchedulingType: DividedKubernetes 资源详细的配置如下表所示：

文章插图
详细的测试方法和过程，可以参考
https://github.com/kubernetes/perf-tests/blob/master/clusterloader2/docs/GETTING_STARTED.md[1]
测试结果APIResponsivenessPrometheus:

文章插图

文章插图
Cluster Registration Latency:

文章插图
Note: Karmada 的 Pull 模式适合用于私有云的场景。与 Push 模式相比，成员集群会运行一个名为 karmada-agent 的组件。它会从控制面拉取用户提交的应用，并运行在成员集群中。在 Pull 模式集群注册的过程中，它会包含安装 karmada-agent 的时间。如果 karmada-agent 的镜像已经准备完毕的话，它很大程度上取决于单集群内 Pod 启动的时延。这里不过多讨论 Pull 模式的注册时延。
Resource Distribution Latency:

文章插图
Push ModeEtcd latency:

文章插图
Resource Usage:

文章插图

文章插图
Pull ModeEtcd latency:

文章插图
Resource Usage:

文章插图

文章插图
成员集群中的 karmada-agent 消耗了 40m CPU(cores)和 266Mi Memory(bytes) 。
结论与分析在以上的测试结果中，API调用时延和资源分发时延均符合上述定义的SLIs/SLOs 。在整个过程中，系统消耗的资源在一个可控制的范围。因此，Karmada能稳定支撑100个大规模集群，并且管理超过500,000个节点和2,000,000个的pods 。在生产中， Karmada能有效支持数以百计的大规模的集群。接下来，我们会具体分析每个测试指标的数据。
关注点分离：资源模板和策略Karmada 使用 Kubernetes 原生 API 来表达集群联邦资源模板，使用可复用的策略 API 来表达集群的调度策略。它不仅可以让 Karmada 能够轻松集成 Kubernetes 的生态, 同时也大大减少了控制面的资源数量。基于此，控制面的资源数量不取决于整个多集群系统集群的数量，而是取决于多集群应用的数量。