企业官网建设流程全解析

KubeEdge 性能测试方案与实践指南：从 SLO 指标到六大测试场景的完整落地

【免费下载链接】kubeedgeKubernetes Native Edge Computing Framework (project under CNCF)项目地址: https://gitcode.com/GitHub_Trending/ku/kubeedge

KubeEdge 是 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 Objectives（SLO）进行基准测量：

同时，性能测试需要能够同时针对**容器化（containerized）与非容器化（un-containerized）**两种形态的 KubeEdge 运行。

非目标（Non-goals）

提案明确不做的事：不设计任何单个性能测试的具体实现细节。也就是说，该提案只定义"测什么、怎么部署、定什么指标"，而把每个测试用例的微观实现留给后续工作。

性能测试部署架构：双集群 + 独立测试客户端

部署拓扑总览

整套性能测试环境包含两个 Kubernetes 集群和一个独立测试客户端（部署架构图见 docs/images/perf/perf-deploy-type.png）：

1. K8S Cluster：一个真实的 K8S 集群，包含 K8S Master（图上的VM2）与其他VMs作为 K8S Nodes。该集群用于供应（provision）KubeEdge Edge Node，即把 Edge Node 以 Pod 的形式运行在 K8S Nodes 上。
2. KubeEdge Cluster：由 K8S Master（图上的VM4）与 K8S Node（图上的VM3）组成的集群，KubeEdge Cloud Part（CloudCore）Pod 和性能测试本身也运行在这个集群中。
3. 容器镜像：预先构建 KubeEdge Cloud Part 镜像与 KubeEdge Edge Node 镜像，并推送到任何可达的容器镜像仓库。
4. Test Client（VM1）：测试客户端，它通过 Deployment 控制器分别在KubeEdge Cluster中部署 KubeEdge Cloud Part Pod、在K8S Cluster中部署 KubeEdge Edge Node Pod，然后针对 KubeEdge Cluster 发起性能测试。

部署执行流程

运行性能测试前，开发者需要先完成上述第 1～3 项准备。随后：

1. Test Client 通过 Deployment 对象在KubeEdge Cluster部署 Cloud Part Pod、在K8S Cluster部署 Edge Node Pod；
2. 等待所有 Pod 启动并进入Running状态；
3. Cloud Part Pod 运行在独立的 VM（图上的VM3）上，Edge Node Pod 运行在K8S Cluster中；
4. Cloud Part 运行后尝试连接 K8S Master（图上的VM4），同时 Edge Node 尝试连接 Cloud Part；
5. 最终，Cloud Part、Edge Node 与 K8S Master 共同组成了KubeEdge Cluster。

虚拟机规格建议

Test Client（VM1）——用于部署 KubeEdge 并运行性能测试：

K8S Masters——两个 VM 均运行 K8S Master 服务（API Server、Scheduler 等），一个用于部署 KubeEdge Edge Node Pod，另一个用于部署 Cloud Part Pod 并运行性能测试：

K8S Nodes——其中一个 VM 运行 Cloud Part Pod（包含 Controllers、CloudHub 等），其余 VM 运行大量 KubeEdge Edge Node Pod（包含 Edged、EdgeHub 等）；VM 数量根据 Edge Node 数量动态调整：

容量估算：docker in docker 模拟 Edge Node

该部署方式与 K8S 社区的 KubeMark 方案类似——在 K8S Cluster 上模拟大量 hollow-node Pod。KubeEdge 也采用类似思路创建 KubeEdge Edge Node Pod 并通过 Deployment 下发，区别在于 KubeEdge Edge Node 使用docker in docker（DinD）：KubeEdge 部署的应用将运行在 Edge Node Pod 内部。

单个 Edge Node Pod 的资源占用约为：

• 1 Pod：0.10 vCPU & 250MB RAM

据此可以推算部署容量：

• 约 10 个 Pod / 1 vCPU；
• 以 32 vCPU / 128GB 的 K8S Node 规格计算，单节点约可部署320 个 Pod（Edge Node）/ 32 vCPU，内存消耗约 80GB；
• 若部署 5 台同规格 K8S Node，整体约可部署1500 个 Pod（Edge Node）/ 5 K8S Nodes。

这一容量估算是确定测试规模（如 Edge Node 数量上限）的重要依据，也解释了为什么测试环境需要 32 vCPU / 128GB 这种大规格 VM。

性能测试框架：基于 Ginkgo 与 Gomega

KubeEdge 性能测试框架基于Gomega与Ginkgo设计（框架结构见 docs/images/perf/perf-test-framework.png）。

框架组成

框架主要包含Utils Library与多种类型的测试：

• E2E Test
• Latency 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.ApiServer+DeploymentHandler, UID, ctx.Cfg.AppImageUrl[1], nodeSelector, replica) Expect(IsAppDeployed).Should(BeTrue()) err := utils.GetDeployments(&deploymentList, ctx.Cfg.ApiServer+DeploymentHandler) Expect(err).To(BeNil()) for _, deployment := range deploymentList.Items { if deployment.Name == UID { label := nodeName podlist, err = utils.GetPods(ctx.Cfg.ApiServer+AppHandler, label) Expect(err).To(BeNil()) break } } utils.CheckPodRunningState(ctx.Cfg.ApiServer+AppHandler, 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 -focus="LoadTest" and perf.test -skip="ScalabilityTest"

即通过-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)在用例开始时记录StartTime，End()记录EndTime，Duration()计算耗时，PrintResult()输出用例名、开始时间与耗时。E2E 用例在BeforeEach中创建计时器、在AfterEach中结束并打印结果，从而把"每个用例的耗时"变成可采集的性能数据。这正是性能测试框架在仓库中的实际落地点之一。

性能指标监控工具：Prometheus 与 Grafana

性能测试过程中采集的指标数据，提案推荐使用以下开源工具进行收集与可视化：

• Prometheus：负责指标采集与存储，是云原生生态的事实标准监控组件；
• Grafana：负责指标可视化，将 Prometheus 采集的数据以 Dashboard 形式呈现。

二者结合可用于观测不同负载条件下 Cloud Part 与 Edge Part 的 CPU、内存等资源占用曲线，与 SLO 指标（延迟、吞吐量、可扩展性）形成完整的性能观测闭环。

六大性能测试场景

提案共规划了 6 个性能测试场景，覆盖 KubeEdge 的南北向 API 与云边通道。

场景 1：Edge Nodes 加入 K8S Cluster

需要测试不同数量的 Edge Nodes，Edge 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 的北向 API（northbound 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 的南向 API（southbound 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 和 Pods：

• Edge 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 和 Devices：

• Edge 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 添加 Pod（Add Pod from CloudHub to EdgeHub）

该场景预期测量 KubeEdge 在CloudHub 与 EdgeHub 之间的性能。严格来说这不是一个 E2E 场景，但CloudHub 到 EdgeHub 的消息传递通道可能是系统瓶颈。提案撰写时 KubeEdge 使用web socket作为云边通信协议。

该场景采用模拟（mock）CloudHub 与 EdgeHub 行为的方式：向 EdgeHub 发送模拟的添加 Pod 消息，同时向 CloudHub 回送模拟的 Pod 状态消息，从而得到 CloudHub 与 EdgeHub 之间的精确延迟与吞吐量。

需要测试不同数量的 Edge Nodes 和 Pods：

• Edge 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）。

表格将在第一轮性能测试数据产出后填充。同时，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