KubeEdge 性能测试方案与实践指南从 SLO 指标到六大测试场景的完整落地【免费下载链接】kubeedgeKubernetes Native Edge Computing Framework (project under CNCF)项目地址: https://gitcode.com/GitHub_Trending/ku/kubeedgeKubeEdge 是 CNCF 旗下的 Kubernetes 原生边缘计算框架支持在云端大规模管理边缘节点与设备。本文以仓库中的 性能测试提案Performance Test Proposal 为核心系统讲解 KubeEdge 性能测试的目标指标体系、多集群部署架构、基于 Ginkgo/Gomega 的测试框架设计、Prometheus 与 Grafana 监控选型以及覆盖边缘节点接入、设备管理、应用下发、设备孪生更新和 CloudHub-EdgeHub 通道的六大测试场景。读完本文你将掌握 KubeEdge 性能测试的完整方法论、部署拓扑与可量化的性能阈值规划思路并能在当前仓库的tests/e2e测试框架基础上落地自己的性能测试用例。背景与动机为什么需要独立的性能测试体系KubeEdge 现有的测试体系主要聚焦于单元测试unit、集成测试integration和 E2E 测试用于验证功能正确性。但 KubeEdge 允许用户在云端管理大规模边缘节点与设备仅靠功能测试无法回答以下关键问题从云端下发一个应用边缘侧 Pod 多久能进入Ready状态大量设备同时上报状态时边缘侧吞吐量是多少不同负载下CloudCore、EdgeCore 的 CPU 和内存占用曲线如何因此提案明确提出需要一套专门的性能测试Performance Test用于测定 KubeEdge 的非功能特性non-functional characteristics包括延迟latency、吞吐量throughput、CPU 占用、内存占用等并据此评估 KubeEdge 的后续改进项improvement items。这份提案列出了 KubeEdge 可能涉及的性能测试场景与测试用例清单是整个性能测试工作的纲领性文档。目标Goals性能测试需要围绕以下 Service Level ObjectivesSLO进行基准测量指标定义延迟Latency从服务器收到请求到响应最后一个字节发送给用户的耗时吞吐量Throughput在给定时间内能够处理的请求数量可扩展性Scalability在不同负载条件下包括边缘节点数、Pod 数、设备数等的潜在扩容能力CPU 占用不同负载条件下 KubeEdge 各组件的 CPU 使用率内存占用不同负载条件下 KubeEdge 各组件的内存使用量同时性能测试需要能够同时针对**容器化containerized与非容器化un-containerized**两种形态的 KubeEdge 运行。非目标Non-goals提案明确不做的事不设计任何单个性能测试的具体实现细节。也就是说该提案只定义测什么、怎么部署、定什么指标而把每个测试用例的微观实现留给后续工作。性能测试部署架构双集群 独立测试客户端部署拓扑总览整套性能测试环境包含两个 Kubernetes 集群和一个独立测试客户端部署架构图见 docs/images/perf/perf-deploy-type.pngK8S Cluster一个真实的 K8S 集群包含 K8S Master图上的VM2与其他VMs作为 K8S Nodes。该集群用于供应provisionKubeEdge Edge Node即把 Edge Node 以 Pod 的形式运行在 K8S Nodes 上。KubeEdge Cluster由 K8S Master图上的VM4与 K8S Node图上的VM3组成的集群KubeEdge Cloud PartCloudCorePod 和性能测试本身也运行在这个集群中。容器镜像预先构建 KubeEdge Cloud Part 镜像与 KubeEdge Edge Node 镜像并推送到任何可达的容器镜像仓库。Test ClientVM1测试客户端它通过 Deployment 控制器分别在KubeEdge Cluster中部署 KubeEdge Cloud Part Pod、在K8S Cluster中部署 KubeEdge Edge Node Pod然后针对 KubeEdge Cluster 发起性能测试。部署执行流程运行性能测试前开发者需要先完成上述第 13 项准备。随后Test Client 通过 Deployment 对象在KubeEdge Cluster部署 Cloud Part Pod、在K8S Cluster部署 Edge Node Pod等待所有 Pod 启动并进入Running状态Cloud Part Pod 运行在独立的 VM图上的VM3上Edge Node Pod 运行在K8S Cluster中Cloud Part 运行后尝试连接 K8S Master图上的VM4同时 Edge Node 尝试连接 Cloud Part最终Cloud Part、Edge Node 与 K8S Master 共同组成了KubeEdge Cluster。虚拟机规格建议Test ClientVM1——用于部署 KubeEdge 并运行性能测试项目规格操作系统Ubuntu 18.04 server 64bitCPU4 vCPUs内存8 GB磁盘40 GB数量1K8S Masters——两个 VM 均运行 K8S Master 服务API Server、Scheduler 等一个用于部署 KubeEdge Edge Node Pod另一个用于部署 Cloud Part Pod 并运行性能测试项目规格操作系统Ubuntu 18.04 server 64bitK8S 版本v1.13.5Docker 版本v17.09CPU32 vCPUs内存128 GB磁盘40 GB数量2K8S Nodes——其中一个 VM 运行 Cloud Part Pod包含 Controllers、CloudHub 等其余 VM 运行大量 KubeEdge Edge Node Pod包含 Edged、EdgeHub 等VM 数量根据 Edge Node 数量动态调整项目规格操作系统Ubuntu 18.04 server 64bitK8S 版本v1.13.5Docker 版本v17.09CPU32 vCPUs内存128 GB磁盘40 GB数量2...N容量估算docker in docker 模拟 Edge Node该部署方式与 K8S 社区的 KubeMark 方案类似——在 K8S Cluster 上模拟大量 hollow-node Pod。KubeEdge 也采用类似思路创建 KubeEdge Edge Node Pod 并通过 Deployment 下发区别在于 KubeEdge Edge Node 使用docker in dockerDinDKubeEdge 部署的应用将运行在 Edge Node Pod 内部。单个 Edge Node Pod 的资源占用约为1 Pod0.10 vCPU 250MB RAM据此可以推算部署容量约 10 个 Pod / 1 vCPU以 32 vCPU / 128GB 的 K8S Node 规格计算单节点约可部署320 个 PodEdge Node/ 32 vCPU内存消耗约 80GB若部署 5 台同规格 K8S Node整体约可部署1500 个 PodEdge Node/ 5 K8S Nodes。这一容量估算是确定测试规模如 Edge Node 数量上限的重要依据也解释了为什么测试环境需要 32 vCPU / 128GB 这种大规格 VM。性能测试框架基于 Ginkgo 与 GomegaKubeEdge 性能测试框架基于Gomega与Ginkgo设计框架结构见 docs/images/perf/perf-test-framework.png。框架组成框架主要包含Utils Library与多种类型的测试E2E TestLatency Test延迟测试Load Test负载测试Scalability Test可扩展性测试其他可扩展类型E2E 测试用例示例提案中给出了一个 E2E 测试样例——创建 Deployment 并验证 Pod 正确启动It(E2E_Test_1: Create deployment and check the pods are coming up correctly, func() { var deploymentList v1.DeploymentList var podlist metav1.PodList replica : 1 //Generate the random string and assign as a UID UID deployment-app- utils.GetRandomString(5) IsAppDeployed : utils.HandleDeployment(http.MethodPost, ctx.Cfg.ApiServerDeploymentHandler, UID, ctx.Cfg.AppImageUrl[1], nodeSelector, replica) Expect(IsAppDeployed).Should(BeTrue()) err : utils.GetDeployments(deploymentList, ctx.Cfg.ApiServerDeploymentHandler) Expect(err).To(BeNil()) for _, deployment : range deploymentList.Items { if deployment.Name UID { label : nodeName podlist, err utils.GetPods(ctx.Cfg.ApiServerAppHandler, label) Expect(err).To(BeNil()) break } } utils.CheckPodRunningState(ctx.Cfg.ApiServerAppHandler, podlist) })该用例的流程体现了性能测试与功能 E2E 测试的一致性生成随机 UID → 通过 HTTP 调用 API Server 创建 Deployment → 轮询 Deployment 列表定位目标对象 → 按节点标签查询 Pod → 校验 Pod 进入 Running 状态。这套模式在当前仓库的 E2E 套件中已经落地例如 tests/e2e/apps/deployment.go 中的E2E_APP_DEPLOYMENT_1、E2E_APP_DEPLOYMENT_2等用例以及 tests/e2e/testsuite/testsuite.go 中封装好的CreateDeploymentTest、CreatePodTest辅助函数。运行方式与命令行接口默认情况下用户运行perf.sh脚本时性能测试框架会运行全部测试用户也可以通过命令行参数向perf.sh传入指定测试只运行特定用例。框架内置了丰富的命令行参数用于运行测试和生成测试文件例如perf.test -focusLoadTest and perf.test -skipScalabilityTest即通过-focus聚焦运行某类测试、通过-skip跳过某类测试。当前仓库的 E2E 入口 tests/e2e/e2e_test.go 采用ginkgo.RunSpecs组织测试套件并支持通过 JUnit 报告输出结果与提案中的框架设计一脉相承。框架特性清单全面的测试运行器comprehensive test runner内置异步asynchronicity测试支持模块化、易于定制日志与报告Logging and Reporting可扩展以增加更多特性内置命令行接口支持。源码印证测试计时器性能测试的核心是量化耗时。当前仓库在 tests/e2e/utils/timer.go 中提供了TestTimer与TestTimerGroup实现NewTestTimer(name)在用例开始时记录StartTimeEnd()记录EndTimeDuration()计算耗时PrintResult()输出用例名、开始时间与耗时。E2E 用例在BeforeEach中创建计时器、在AfterEach中结束并打印结果从而把每个用例的耗时变成可采集的性能数据。这正是性能测试框架在仓库中的实际落地点之一。性能指标监控工具Prometheus 与 Grafana性能测试过程中采集的指标数据提案推荐使用以下开源工具进行收集与可视化Prometheus负责指标采集与存储是云原生生态的事实标准监控组件Grafana负责指标可视化将 Prometheus 采集的数据以 Dashboard 形式呈现。二者结合可用于观测不同负载条件下 Cloud Part 与 Edge Part 的 CPU、内存等资源占用曲线与 SLO 指标延迟、吞吐量、可扩展性形成完整的性能观测闭环。六大性能测试场景提案共规划了 6 个性能测试场景覆盖 KubeEdge 的南北向 API 与云边通道。场景 1Edge Nodes 加入 K8S Cluster需要测试不同数量的 Edge NodesEdge Nodes 数量取自[1, 10, 20, 50, 100, 200...]。测试用例测量 Edge Nodes 加入 K8S Cluster 的启动时间以所有 Edge Nodes 进入Ready状态为结束标志测量 KubeEdge Cloud Part 的 CPU 与内存占用测量 KubeEdge Edge Part 的 CPU 与内存占用。场景 2从云端创建设备Create Devices from Cloud该场景预期测量 KubeEdge 的北向 APInorthbound API即云侧与 K8S Master 之间的交互能力。测试用例测量 K8S Master 与 KubeEdge Cloud Part 之间的延迟测量 K8S Master 与 KubeEdge Cloud Part 之间的吞吐量测量 KubeEdge Cloud Part 的 CPU 与内存占用。场景 3向 Edge 上报设备状态Report Device Status to Edge该场景预期测量 KubeEdge 的南向 APIsouthbound API即边缘侧与设备之间的交互能力。需要测试不同数量的 Devices每个 Edge Node 的 Devices 数量取自[1, 10, 20, 50, 100, 200...]。测试用例测量 KubeEdge Edge Part 与 device 之间的延迟测量 KubeEdge Edge Part 与 device 之间的吞吐量测量 KubeEdge Edge Part 的 CPU 与内存占用。通过不同设备数量下的延迟与吞吐量结果可以评估 KubeEdge Edge Part 对设备的可扩展性即每个 Edge Node 可以处理多少台设备见 docs/images/perf/perf-multi-devices.png。在协议方面需要考虑在 Edge Part 与设备之间测试不同协议例如Bluetooth、MQTT、ZigBee、BACnet、Modbus等。提案指出当前边缘 IoT 场景下可接受的延迟小于 20ms。测试可采用两种方式不同设备的模拟器emulators以及真实设备actual devices。场景 4从云端向边缘部署应用Application Deployment from Cloud to Edge该场景预期测量 KubeEdge 从 Cloud 到 Edge 的整体性能。注意docker 镜像下载延迟不计入该场景因此测试前需要确保 docker 镜像已经下载到 Edge Nodes 上。需要测试不同数量的 Edge Nodes 和 PodsEdge Nodes 数量取自[1, 10, 20, 50, 100, 200...]每个 Edge Node 的 Pods 数量取自[1, 2, 5, 10, 20...]。测试用例测量Pod 启动时间以所有 Pods 进入Ready状态为结束标志测量 KubeEdge Cloud Part 的 CPU 与内存占用测量 KubeEdge Edge Part 的 CPU 与内存占用。通过 Pod 启动时间结果可以评估 KubeEdge Edge Nodes 的可扩展性量化KubeEdge Cloud Part 能管理多少个 Edge Nodes、每个 Edge Node 能承载多少个 Pods见 docs/images/perf/perf-multi-edgenodes.png。场景 5从云端到设备更新设备孪生状态Update Device Twin State from Cloud to Device该场景预期测量 KubeEdge 的E2E 性能从云到设备、再从设备回到云的完整链路。需要测试不同数量的 Edge Nodes 和 DevicesEdge Nodes 数量取自[1, 10, 20, 50, 100, 200...]每个 Edge Node 的 Devices 数量取自[1, 10, 20, 50, 100, 200...]。测试用例测量E2E 延迟测量 KubeEdge Cloud Part 的 CPU 与内存占用测量 KubeEdge Edge Part 的 CPU 与内存占用。这些测试用例应分别在**系统空闲idle和高负载heavy load**两种状态下运行以评估系统在不同压力下的表现。场景 6从 CloudHub 向 EdgeHub 添加 PodAdd Pod from CloudHub to EdgeHub该场景预期测量 KubeEdge 在CloudHub 与 EdgeHub 之间的性能。严格来说这不是一个 E2E 场景但CloudHub 到 EdgeHub 的消息传递通道可能是系统瓶颈。提案撰写时 KubeEdge 使用web socket作为云边通信协议。该场景采用模拟mockCloudHub 与 EdgeHub 行为的方式向 EdgeHub 发送模拟的添加 Pod 消息同时向 CloudHub 回送模拟的 Pod 状态消息从而得到 CloudHub 与 EdgeHub 之间的精确延迟与吞吐量。需要测试不同数量的 Edge Nodes 和 PodsEdge Nodes 数量取自[1, 10, 20, 50, 100, 200...]每个 Edge Node 的 Pods 数量取自[1, 2, 5, 10, 20...]。测试用例测量 KubeEdge CloudHub 与 KubeEdge EdgeHub 之间的延迟测量 KubeEdge CloudHub 与 KubeEdge EdgeHub 之间的吞吐量测量 KubeEdge Cloud Part 的 CPU 与内存占用测量 KubeEdge Edge Part 的 CPU 与内存占用。根据延迟与吞吐量结果可以评估 KubeEdge EdgeHubs 的可扩展性与 Edge Nodes 的可扩展性评估方式相同。性能阈值Thresholds性能测试的最终目的是确定 KubeEdge 的性能与可扩展性边界这既为后续改进项improvement items提供依据也为用户提供推荐的部署配置与使用指南recommended setup and user guides。提案引用了 K8S 社区的可扩展性结论自 1.6 版本起K8S 可以在单个集群中支持 5000 个 Node 和 150000 个 Pod。KubeEdge 基于 K8S Master与 K8S 的差异在于KubeEdge Edge Nodes 不像 K8S Nodes 那样直接连接 K8S Master而是通过KubeEdge Cloud Part 连接 K8S Master 与 KubeEdge Edge Nodes同时 KubeEdge Edge Nodes 更加轻量占用更少的 CPU 与内存资源。提案如实说明撰写时 KubeEdge尚无与其他系统可对比的性能数据但可以通过性能测试数据来测量 KubeEdge 自身的性能与可扩展性从 0.3 版本开始获取原始测试数据并在后续版本中持续开展性能测试。提案定义了以下基于性能测试数据的阈值并明确指出大多数情况下超出这些阈值并不意味着 KubeEdge 宕机fails over只是整体性能会退化degrades。数量指标0.3 Release1.0 Release长期目标Edge Nodes 数量Pods 数量每个 Edge Node 的 Pods 数量Device 数量每个 Edge Node 的 Device 数量表格将在第一轮性能测试数据产出后填充。同时KubeEdge 性能测试用例将超过 5000 个 Edge Nodes 和 150000 个 Pods以便与 K8S Cluster 进行对比。结语从提案到落地这份性能测试提案为 KubeEdge 定义了一套完整、可执行的性能评估体系从延迟、吞吐量、可扩展性、CPU/内存五大 SLO 指标出发设计了双集群加独立测试客户端的部署拓扑规划了基于 Ginkgo/Gomega 的测试框架选定了 Prometheus/Grafana 监控栈并细化出覆盖云边南北向 API 与云边通道的六大测试场景。当前仓库中tests/e2e 目录下的 E2E 测试、测试计时器、Deployment 测试用例 与 设备管理测试用例都已成为该提案思想的具体实现载体。无论是评估 KubeEdge 单集群的承载上限还是为边缘节点、设备、应用的规模规划提供数据依据本文所述的方案都能直接作为你搭建性能测试环境的参考蓝本。【免费下载链接】kubeedgeKubernetes Native Edge Computing Framework (project under CNCF)项目地址: https://gitcode.com/GitHub_Trending/ku/kubeedge创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
KubeEdge 性能测试方案与实践指南：从 SLO 指标到六大测试场景的完整落地
KubeEdge 性能测试方案与实践指南从 SLO 指标到六大测试场景的完整落地【免费下载链接】kubeedgeKubernetes Native Edge Computing Framework (project under CNCF)项目地址: https://gitcode.com/GitHub_Trending/ku/kubeedgeKubeEdge 是 CNCF 旗下的 Kubernetes 原生边缘计算框架支持在云端大规模管理边缘节点与设备。本文以仓库中的 性能测试提案Performance Test Proposal 为核心系统讲解 KubeEdge 性能测试的目标指标体系、多集群部署架构、基于 Ginkgo/Gomega 的测试框架设计、Prometheus 与 Grafana 监控选型以及覆盖边缘节点接入、设备管理、应用下发、设备孪生更新和 CloudHub-EdgeHub 通道的六大测试场景。读完本文你将掌握 KubeEdge 性能测试的完整方法论、部署拓扑与可量化的性能阈值规划思路并能在当前仓库的tests/e2e测试框架基础上落地自己的性能测试用例。背景与动机为什么需要独立的性能测试体系KubeEdge 现有的测试体系主要聚焦于单元测试unit、集成测试integration和 E2E 测试用于验证功能正确性。但 KubeEdge 允许用户在云端管理大规模边缘节点与设备仅靠功能测试无法回答以下关键问题从云端下发一个应用边缘侧 Pod 多久能进入Ready状态大量设备同时上报状态时边缘侧吞吐量是多少不同负载下CloudCore、EdgeCore 的 CPU 和内存占用曲线如何因此提案明确提出需要一套专门的性能测试Performance Test用于测定 KubeEdge 的非功能特性non-functional characteristics包括延迟latency、吞吐量throughput、CPU 占用、内存占用等并据此评估 KubeEdge 的后续改进项improvement items。这份提案列出了 KubeEdge 可能涉及的性能测试场景与测试用例清单是整个性能测试工作的纲领性文档。目标Goals性能测试需要围绕以下 Service Level ObjectivesSLO进行基准测量指标定义延迟Latency从服务器收到请求到响应最后一个字节发送给用户的耗时吞吐量Throughput在给定时间内能够处理的请求数量可扩展性Scalability在不同负载条件下包括边缘节点数、Pod 数、设备数等的潜在扩容能力CPU 占用不同负载条件下 KubeEdge 各组件的 CPU 使用率内存占用不同负载条件下 KubeEdge 各组件的内存使用量同时性能测试需要能够同时针对**容器化containerized与非容器化un-containerized**两种形态的 KubeEdge 运行。非目标Non-goals提案明确不做的事不设计任何单个性能测试的具体实现细节。也就是说该提案只定义测什么、怎么部署、定什么指标而把每个测试用例的微观实现留给后续工作。性能测试部署架构双集群 独立测试客户端部署拓扑总览整套性能测试环境包含两个 Kubernetes 集群和一个独立测试客户端部署架构图见 docs/images/perf/perf-deploy-type.pngK8S Cluster一个真实的 K8S 集群包含 K8S Master图上的VM2与其他VMs作为 K8S Nodes。该集群用于供应provisionKubeEdge Edge Node即把 Edge Node 以 Pod 的形式运行在 K8S Nodes 上。KubeEdge Cluster由 K8S Master图上的VM4与 K8S Node图上的VM3组成的集群KubeEdge Cloud PartCloudCorePod 和性能测试本身也运行在这个集群中。容器镜像预先构建 KubeEdge Cloud Part 镜像与 KubeEdge Edge Node 镜像并推送到任何可达的容器镜像仓库。Test ClientVM1测试客户端它通过 Deployment 控制器分别在KubeEdge Cluster中部署 KubeEdge Cloud Part Pod、在K8S Cluster中部署 KubeEdge Edge Node Pod然后针对 KubeEdge Cluster 发起性能测试。部署执行流程运行性能测试前开发者需要先完成上述第 13 项准备。随后Test Client 通过 Deployment 对象在KubeEdge Cluster部署 Cloud Part Pod、在K8S Cluster部署 Edge Node Pod等待所有 Pod 启动并进入Running状态Cloud Part Pod 运行在独立的 VM图上的VM3上Edge Node Pod 运行在K8S Cluster中Cloud Part 运行后尝试连接 K8S Master图上的VM4同时 Edge Node 尝试连接 Cloud Part最终Cloud Part、Edge Node 与 K8S Master 共同组成了KubeEdge Cluster。虚拟机规格建议Test ClientVM1——用于部署 KubeEdge 并运行性能测试项目规格操作系统Ubuntu 18.04 server 64bitCPU4 vCPUs内存8 GB磁盘40 GB数量1K8S Masters——两个 VM 均运行 K8S Master 服务API Server、Scheduler 等一个用于部署 KubeEdge Edge Node Pod另一个用于部署 Cloud Part Pod 并运行性能测试项目规格操作系统Ubuntu 18.04 server 64bitK8S 版本v1.13.5Docker 版本v17.09CPU32 vCPUs内存128 GB磁盘40 GB数量2K8S Nodes——其中一个 VM 运行 Cloud Part Pod包含 Controllers、CloudHub 等其余 VM 运行大量 KubeEdge Edge Node Pod包含 Edged、EdgeHub 等VM 数量根据 Edge Node 数量动态调整项目规格操作系统Ubuntu 18.04 server 64bitK8S 版本v1.13.5Docker 版本v17.09CPU32 vCPUs内存128 GB磁盘40 GB数量2...N容量估算docker in docker 模拟 Edge Node该部署方式与 K8S 社区的 KubeMark 方案类似——在 K8S Cluster 上模拟大量 hollow-node Pod。KubeEdge 也采用类似思路创建 KubeEdge Edge Node Pod 并通过 Deployment 下发区别在于 KubeEdge Edge Node 使用docker in dockerDinDKubeEdge 部署的应用将运行在 Edge Node Pod 内部。单个 Edge Node Pod 的资源占用约为1 Pod0.10 vCPU 250MB RAM据此可以推算部署容量约 10 个 Pod / 1 vCPU以 32 vCPU / 128GB 的 K8S Node 规格计算单节点约可部署320 个 PodEdge Node/ 32 vCPU内存消耗约 80GB若部署 5 台同规格 K8S Node整体约可部署1500 个 PodEdge Node/ 5 K8S Nodes。这一容量估算是确定测试规模如 Edge Node 数量上限的重要依据也解释了为什么测试环境需要 32 vCPU / 128GB 这种大规格 VM。性能测试框架基于 Ginkgo 与 GomegaKubeEdge 性能测试框架基于Gomega与Ginkgo设计框架结构见 docs/images/perf/perf-test-framework.png。框架组成框架主要包含Utils Library与多种类型的测试E2E TestLatency Test延迟测试Load Test负载测试Scalability Test可扩展性测试其他可扩展类型E2E 测试用例示例提案中给出了一个 E2E 测试样例——创建 Deployment 并验证 Pod 正确启动It(E2E_Test_1: Create deployment and check the pods are coming up correctly, func() { var deploymentList v1.DeploymentList var podlist metav1.PodList replica : 1 //Generate the random string and assign as a UID UID deployment-app- utils.GetRandomString(5) IsAppDeployed : utils.HandleDeployment(http.MethodPost, ctx.Cfg.ApiServerDeploymentHandler, UID, ctx.Cfg.AppImageUrl[1], nodeSelector, replica) Expect(IsAppDeployed).Should(BeTrue()) err : utils.GetDeployments(deploymentList, ctx.Cfg.ApiServerDeploymentHandler) Expect(err).To(BeNil()) for _, deployment : range deploymentList.Items { if deployment.Name UID { label : nodeName podlist, err utils.GetPods(ctx.Cfg.ApiServerAppHandler, label) Expect(err).To(BeNil()) break } } utils.CheckPodRunningState(ctx.Cfg.ApiServerAppHandler, podlist) })该用例的流程体现了性能测试与功能 E2E 测试的一致性生成随机 UID → 通过 HTTP 调用 API Server 创建 Deployment → 轮询 Deployment 列表定位目标对象 → 按节点标签查询 Pod → 校验 Pod 进入 Running 状态。这套模式在当前仓库的 E2E 套件中已经落地例如 tests/e2e/apps/deployment.go 中的E2E_APP_DEPLOYMENT_1、E2E_APP_DEPLOYMENT_2等用例以及 tests/e2e/testsuite/testsuite.go 中封装好的CreateDeploymentTest、CreatePodTest辅助函数。运行方式与命令行接口默认情况下用户运行perf.sh脚本时性能测试框架会运行全部测试用户也可以通过命令行参数向perf.sh传入指定测试只运行特定用例。框架内置了丰富的命令行参数用于运行测试和生成测试文件例如perf.test -focusLoadTest and perf.test -skipScalabilityTest即通过-focus聚焦运行某类测试、通过-skip跳过某类测试。当前仓库的 E2E 入口 tests/e2e/e2e_test.go 采用ginkgo.RunSpecs组织测试套件并支持通过 JUnit 报告输出结果与提案中的框架设计一脉相承。框架特性清单全面的测试运行器comprehensive test runner内置异步asynchronicity测试支持模块化、易于定制日志与报告Logging and Reporting可扩展以增加更多特性内置命令行接口支持。源码印证测试计时器性能测试的核心是量化耗时。当前仓库在 tests/e2e/utils/timer.go 中提供了TestTimer与TestTimerGroup实现NewTestTimer(name)在用例开始时记录StartTimeEnd()记录EndTimeDuration()计算耗时PrintResult()输出用例名、开始时间与耗时。E2E 用例在BeforeEach中创建计时器、在AfterEach中结束并打印结果从而把每个用例的耗时变成可采集的性能数据。这正是性能测试框架在仓库中的实际落地点之一。性能指标监控工具Prometheus 与 Grafana性能测试过程中采集的指标数据提案推荐使用以下开源工具进行收集与可视化Prometheus负责指标采集与存储是云原生生态的事实标准监控组件Grafana负责指标可视化将 Prometheus 采集的数据以 Dashboard 形式呈现。二者结合可用于观测不同负载条件下 Cloud Part 与 Edge Part 的 CPU、内存等资源占用曲线与 SLO 指标延迟、吞吐量、可扩展性形成完整的性能观测闭环。六大性能测试场景提案共规划了 6 个性能测试场景覆盖 KubeEdge 的南北向 API 与云边通道。场景 1Edge Nodes 加入 K8S Cluster需要测试不同数量的 Edge NodesEdge Nodes 数量取自[1, 10, 20, 50, 100, 200...]。测试用例测量 Edge Nodes 加入 K8S Cluster 的启动时间以所有 Edge Nodes 进入Ready状态为结束标志测量 KubeEdge Cloud Part 的 CPU 与内存占用测量 KubeEdge Edge Part 的 CPU 与内存占用。场景 2从云端创建设备Create Devices from Cloud该场景预期测量 KubeEdge 的北向 APInorthbound API即云侧与 K8S Master 之间的交互能力。测试用例测量 K8S Master 与 KubeEdge Cloud Part 之间的延迟测量 K8S Master 与 KubeEdge Cloud Part 之间的吞吐量测量 KubeEdge Cloud Part 的 CPU 与内存占用。场景 3向 Edge 上报设备状态Report Device Status to Edge该场景预期测量 KubeEdge 的南向 APIsouthbound API即边缘侧与设备之间的交互能力。需要测试不同数量的 Devices每个 Edge Node 的 Devices 数量取自[1, 10, 20, 50, 100, 200...]。测试用例测量 KubeEdge Edge Part 与 device 之间的延迟测量 KubeEdge Edge Part 与 device 之间的吞吐量测量 KubeEdge Edge Part 的 CPU 与内存占用。通过不同设备数量下的延迟与吞吐量结果可以评估 KubeEdge Edge Part 对设备的可扩展性即每个 Edge Node 可以处理多少台设备见 docs/images/perf/perf-multi-devices.png。在协议方面需要考虑在 Edge Part 与设备之间测试不同协议例如Bluetooth、MQTT、ZigBee、BACnet、Modbus等。提案指出当前边缘 IoT 场景下可接受的延迟小于 20ms。测试可采用两种方式不同设备的模拟器emulators以及真实设备actual devices。场景 4从云端向边缘部署应用Application Deployment from Cloud to Edge该场景预期测量 KubeEdge 从 Cloud 到 Edge 的整体性能。注意docker 镜像下载延迟不计入该场景因此测试前需要确保 docker 镜像已经下载到 Edge Nodes 上。需要测试不同数量的 Edge Nodes 和 PodsEdge Nodes 数量取自[1, 10, 20, 50, 100, 200...]每个 Edge Node 的 Pods 数量取自[1, 2, 5, 10, 20...]。测试用例测量Pod 启动时间以所有 Pods 进入Ready状态为结束标志测量 KubeEdge Cloud Part 的 CPU 与内存占用测量 KubeEdge Edge Part 的 CPU 与内存占用。通过 Pod 启动时间结果可以评估 KubeEdge Edge Nodes 的可扩展性量化KubeEdge Cloud Part 能管理多少个 Edge Nodes、每个 Edge Node 能承载多少个 Pods见 docs/images/perf/perf-multi-edgenodes.png。场景 5从云端到设备更新设备孪生状态Update Device Twin State from Cloud to Device该场景预期测量 KubeEdge 的E2E 性能从云到设备、再从设备回到云的完整链路。需要测试不同数量的 Edge Nodes 和 DevicesEdge Nodes 数量取自[1, 10, 20, 50, 100, 200...]每个 Edge Node 的 Devices 数量取自[1, 10, 20, 50, 100, 200...]。测试用例测量E2E 延迟测量 KubeEdge Cloud Part 的 CPU 与内存占用测量 KubeEdge Edge Part 的 CPU 与内存占用。这些测试用例应分别在**系统空闲idle和高负载heavy load**两种状态下运行以评估系统在不同压力下的表现。场景 6从 CloudHub 向 EdgeHub 添加 PodAdd Pod from CloudHub to EdgeHub该场景预期测量 KubeEdge 在CloudHub 与 EdgeHub 之间的性能。严格来说这不是一个 E2E 场景但CloudHub 到 EdgeHub 的消息传递通道可能是系统瓶颈。提案撰写时 KubeEdge 使用web socket作为云边通信协议。该场景采用模拟mockCloudHub 与 EdgeHub 行为的方式向 EdgeHub 发送模拟的添加 Pod 消息同时向 CloudHub 回送模拟的 Pod 状态消息从而得到 CloudHub 与 EdgeHub 之间的精确延迟与吞吐量。需要测试不同数量的 Edge Nodes 和 PodsEdge Nodes 数量取自[1, 10, 20, 50, 100, 200...]每个 Edge Node 的 Pods 数量取自[1, 2, 5, 10, 20...]。测试用例测量 KubeEdge CloudHub 与 KubeEdge EdgeHub 之间的延迟测量 KubeEdge CloudHub 与 KubeEdge EdgeHub 之间的吞吐量测量 KubeEdge Cloud Part 的 CPU 与内存占用测量 KubeEdge Edge Part 的 CPU 与内存占用。根据延迟与吞吐量结果可以评估 KubeEdge EdgeHubs 的可扩展性与 Edge Nodes 的可扩展性评估方式相同。性能阈值Thresholds性能测试的最终目的是确定 KubeEdge 的性能与可扩展性边界这既为后续改进项improvement items提供依据也为用户提供推荐的部署配置与使用指南recommended setup and user guides。提案引用了 K8S 社区的可扩展性结论自 1.6 版本起K8S 可以在单个集群中支持 5000 个 Node 和 150000 个 Pod。KubeEdge 基于 K8S Master与 K8S 的差异在于KubeEdge Edge Nodes 不像 K8S Nodes 那样直接连接 K8S Master而是通过KubeEdge Cloud Part 连接 K8S Master 与 KubeEdge Edge Nodes同时 KubeEdge Edge Nodes 更加轻量占用更少的 CPU 与内存资源。提案如实说明撰写时 KubeEdge尚无与其他系统可对比的性能数据但可以通过性能测试数据来测量 KubeEdge 自身的性能与可扩展性从 0.3 版本开始获取原始测试数据并在后续版本中持续开展性能测试。提案定义了以下基于性能测试数据的阈值并明确指出大多数情况下超出这些阈值并不意味着 KubeEdge 宕机fails over只是整体性能会退化degrades。数量指标0.3 Release1.0 Release长期目标Edge Nodes 数量Pods 数量每个 Edge Node 的 Pods 数量Device 数量每个 Edge Node 的 Device 数量表格将在第一轮性能测试数据产出后填充。同时KubeEdge 性能测试用例将超过 5000 个 Edge Nodes 和 150000 个 Pods以便与 K8S Cluster 进行对比。结语从提案到落地这份性能测试提案为 KubeEdge 定义了一套完整、可执行的性能评估体系从延迟、吞吐量、可扩展性、CPU/内存五大 SLO 指标出发设计了双集群加独立测试客户端的部署拓扑规划了基于 Ginkgo/Gomega 的测试框架选定了 Prometheus/Grafana 监控栈并细化出覆盖云边南北向 API 与云边通道的六大测试场景。当前仓库中tests/e2e 目录下的 E2E 测试、测试计时器、Deployment 测试用例 与 设备管理测试用例都已成为该提案思想的具体实现载体。无论是评估 KubeEdge 单集群的承载上限还是为边缘节点、设备、应用的规模规划提供数据依据本文所述的方案都能直接作为你搭建性能测试环境的参考蓝本。【免费下载链接】kubeedgeKubernetes Native Edge Computing Framework (project under CNCF)项目地址: https://gitcode.com/GitHub_Trending/ku/kubeedge创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考