- Num of Nodes
- Num of Pods
SLIs/SLOs可扩展性和性能是多集群联邦的重要特性 。作为多集群联邦的用户 , 我们期望在以上两方面有服务质量的保证 。在进行大规模性能测试之前,我们需要定义测量指标 。在参考了 Kubernetes 社区的 SLI(Service Level Indicator)/SLO(Service Level Objectives)和多集群的典型应用,Karmada 社区定义了以下 SLI/SLO 来衡量多集群联邦的服务质量 。
- API Call Latency
文章插图
- Resource Distribution Latency
文章插图
- Cluster Registration Latency
文章插图
- Resource usage
文章插图
Note:
- 上述指标不考虑控制面和成员集群的网络波动 。同时,单集群内的 SLO 不会考虑在内 。
- 资源使用量是一个对于多集群系统非常重要的指标,但是不同多集群系统提供的上层服务不同,所以对各个系统来说资源的要求也会不同 。我们不对这个指标进行强制的限制 。
- 集群注册时延是从集群注册到控制面到集群在联邦侧可用的时延 。它在某种程度上取决于控制面如何收集成员集群的状态 。
PrometheusPrometheus 是一个开源的用于监控和告警的工具, 它包含数据收集、数据报告、数据可视化等功能 。在分析了 Clusterloader2 对各种监控指标的处理后,我们使用 Prometheus 根据具体的查询语句对控制面的指标进行监控 。
KindKind 是一个是用容器来运行 Kubernetes 本地集群的工具 。为了测试 Karmada 的应用分发能力,我们需要一个真实的单集群控制面来管理被联邦控制面分发的应用 。Kind 能够在节约资源的同时模拟一个真实的集群 。
Fake-kubeletFake-kubelet 是一个能模拟节点且能维护虚拟节点上的 Pod 的工具 。与 Kubemark 相比,fake-kubelet 只做维护节点和 Pod 的必要工作 。它非常适合模拟大规模的节点和 Pod 来测试控制面的在大规模环境下的性能 。
测试集群部署方案Kubernetes 控制面部署在单 master 的节点上 。etcd,kube-apiserver,kube-scheduler 和 kube-controller 以单实例的形式部署 。Karmada 的控制面组件部署在这个 master 节点上 。他们同样以单实例的形式部署 。所有的 Kubernetes 组件和 Karmada 组件运行在高性能的节点上,且我们不对他们限制资源 。我们通过 kind 来模拟单 master 节点的集群,通过 fake-kubelet 来模拟集群中的工作节点 。
测试环境信息控制面操作系统版本
Ubuntu 18.04.6 LTS (Bionic Beaver)
Kubernetes 版本
Kubernetes v1.23.10
Karmada 版本
Karmada v1.3.0-4-g1f13ad97
Karmada 控制面所在的节点配置
- CPU
推荐阅读
- 红魔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-飞机订票系统-脚本录制