KubeEdge Edgemark：用 Hollow 边缘节点构建云侧 CloudCore 规模化压测集群-平芜编程栈

KubeEdge Edgemark：用 Hollow 边缘节点构建云侧 CloudCore 规模化压测集群

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

KubeEdge 的 Edgemark 是一个受 Kubemark 启发的性能测试工具，它通过运行一组"空心"边缘节点（Hollow Edge Node）来构造一个规模远超真实部署的模拟 KubeEdge 集群，专门用于在规模化场景下暴露 CloudCore 等云侧组件的问题。读完本文，你将理解 Edgemark 的双集群架构与"Hollow"模拟原理，掌握从构建镜像、下发 tokensecret 到批量拉起 Hollow 节点并配合 ClusterLoader2 执行压测的完整流程，并能对照源码看懂edgemark可执行文件如何以伪造的 CRI 运行时替换真实容器能力。

一、Edgemark 是什么

Edgemark 的定位在 build/edgemark/README.md 中交代得很明确：

它是一个性能测试工具，设计灵感来自 Kubernetes 官方的 Kubemark，允许用户在模拟集群上做实验；
主要用例是可扩展性（scalability）测试——模拟集群的规模可以远大于真实集群；
目标是暴露那些只在大集群上才会出现的 KubeEdge 云侧组件（CloudCore）问题。

换句话说，Edgemark 并不模拟边缘设备上的业务负载，也不产生任何真实容器。它的价值在于：当你怀疑 CloudCore 在成百上千边缘节点规模下会出现性能退化、同步延迟或内存膨胀等问题，但手边并没有这么多真实边缘机器时，Edgemark 让你用外部集群里的一些轻量 Pod 来"顶替"海量边缘节点，把压力全部导向云侧。

二、架构：两个集群与"空心"边缘节点

2.1 集群拓扑

从 build/edgemark/README.md 的 Architecture 一节和 build/edgemark/edgemark_setup_guide.md 可以归纳出 Edgemark 方案由三类资源构成：

edgemark cluster（被测集群）：一个真实的 Kubernetes master（可以是 StandAlone 或 HA），其上部署 KubeEdge 的 CloudCore 组件，负责为 Hollow 边缘节点提供接入服务。Kubemark 式的设计里，master 组件运行在专用机器上，由 kubelet 以 Pod 形式创建和管理，kubelet 本身则以 systemd 或 supervisord 服务运行，好处是可以把 master 资源与其他负载完全隔离。
external cluster（外部集群）：一个真实的 Kubernetes 集群，用来承载所有 Hollow Edge Node 的 Pod。这些 Pod 运行在独立的edgemark命名空间中——"用真实集群上的 Pod 在被测集群中表现为节点"正是 Edgemark 设计的核心。
专用节点与负载均衡：CloudCore 有多个实例、需要多个专用节点来维持高可靠，高可用配置下还必须在 CloudCore 前面挂一个负载均衡器，把 Hollow 节点接入请求正确路由到健康的 CloudCore 实例上。且该负载均衡器必须能从 external cluster 中的 Hollow 节点直接路由到达。

2.2 HollowEdgeCore：假装是 EdgeCore

Hollow Edge Node 通过HollowEdgeCore注册到被测集群：它假装是一个普通 EdgeCore，但不会创建任何真实容器。其核心手法是用 Kubernetes 的 fake CRI 运行时来 mock 掉 runtime manager——除模拟运行时之外，其余行为与 edgecore 完全一致。

文档中给出的参考路径是k8s.io/kubernetes/pkg/kubelet/cri/remote/fake/fake_runtime.go（较旧的导入路径）。以当前仓库代码为准，这一能力来自k8s.io/cri-client/pkg/fake包，实现位于 hollow_edgecore.go：

GetFakeKubeletDeps（edge/cmd/edgemark/hollow_edgecore.go#L163-L205）通过fakeremote.GenerateEndpoint()生成一个 UDS endpoint，启动fakeremote.NewFakeRemoteRuntime()假运行时，再用remote.NewRemoteRuntimeService构建指向该假运行时的 CRI 客户端；
同时把 kubelet 依赖链上的其他环节一并换成 fake：cadvisortest.Fake（假 cadvisor）、cm.NewStubContainerManager()（stub 容器管理器）、containertest.FakeOS、mount.FakeMounter、subpath.FakeSubpath、hostutil.NewFakeHostUtil等；
保留的 volume plugins 为 emptydir、hostpath、secret、downwardapi、configmap、projected、local 这几类（见volumePlugins()，edge/cmd/edgemark/hollow_edgecore.go#L207-L217）。

2.3 注入机制：edged 模块的两个可替换默认值

Hollow 方案之所以成立，是因为 KubeEdge 的edged模块预留了两个全局默认函数指针，其注释明确写着"will only be changed when EdgeMark is enabled"（仅在启用 EdgeMark 时才会被修改），见 edge/pkg/edged/edged.go#L80-L84：

edged.DefaultKubeletDeps：默认指向kubeletserver.UnsecuredDependencies，即真实的 kubelet 依赖构造逻辑，在 newEdged 中被调用；
edged.DefaultRunLiteKubelet：默认指向kubeletserver.Run，在 edged.Start 中被调用。

edgemark命令的run函数（edge/cmd/edgemark/hollow_edgecore.go#L108-L129）做的第一件事就是替换这两个变量：GetFakeKubeletDeps接管依赖构造，kubeletapp.RunKubelet接管 kubelet 启动流程；随后正常注册 beehive 模块edged、edgehub、metamanager，初始化元数据库 DAO 并调用core.Run()启动全部模块。从源码结构看，这意味着 Hollow 节点保留了真实的edgehub 消息链路（建链、收发消息、同步资源）与metamanager 元数据管理，只有"执行容器"这一层被掏空——这正是压测 CloudCore 下发/同步通路所需要的最小仿真面。

三、运行 Edgemark 的环境要求

根据 build/edgemark/README.md 的 Requirements 一节，运行 Edgemark 需要：

一个 Kubernetes 集群（称为external cluster），用于运行所有 Hollow Edge Node；
一个 Kubernetes 集群（称为edgemark cluster），作为 Hollow Edge Node 的 master；
edgemark cluster中若干专用节点，用于部署 CloudCore，以及一个为 Hollow Edge Node 暴露 CloudCore 服务的负载均衡器（该 LB 必须能从 Hollow Edge Node 直接路由到达）；
一个可访问的 Docker 仓库，其中包含 CloudCore、hollow-edge-node 和 node-problem-detector 的容器镜像。

四、搭建步骤实战

完整步骤参考 build/edgemark/edgemark_setup_guide.md，前置条件是 edgemark master 与 external cluster 均已就绪。

4.1 步骤一：在 edgemark cluster 部署 CloudCore

按官方 CloudCore 高可用部署方式部署 CloudCore（edgemark master 支持 StandAlone 或 HA 两种形态），使其能在 edgemark cluster 中为边缘节点提供接入。这一步遵循仓库中 CloudCore 的标准部署流程，不再赘述。

4.2 步骤二：构建 edgemark 镜像

如果你要构建/使用自己的 edgemark 镜像：

cd $GOPATH/src/github.com/kubeedge git clone git@github.com:kubeedge/kubeedge.git

然后：

cd $GOPATH/src/github.com/kubeedge/kubeedge make image WHAT=edgemark

构建完成后本地会得到名为kubeedge/edgemark:{tag}的镜像。

镜像的构建过程见 build/edgemark/Dockerfile：以golang:1.23.12-alpine3.21为构建基础镜像，安装build-base、linux-headers、sqlite-dev等依赖后以CGO_ENABLED=1静态编译github.com/kubeedge/kubeedge/edge/cmd/edgemark包（对应上文分析的 hollow 节点入口），最终产物拷入alpine:3.21精简运行时镜像，ENTRYPOINT固定为edgemark。

4.3 步骤三：在 external cluster 创建 Hollow 节点

1）创建命名空间并复制 tokensecret

tokensecret是 CloudCore 在 edgemark master 侧（kubeedge命名空间）生成、供边缘节点接入 CloudCore 时使用的令牌。先把它导出为文件：

kubectl get secret -nkubeedge tokensecret -oyaml > tokensecret.yaml

修改其中的命名空间为目标命名空间{ns}：

sed -i "s|namespace: .*|namespace: {ns}|g" tokensecret.yaml

在 external cluster 中创建命名空间与 secret：

kubectl create ns edgemark kubectl create -f tokensecret.yaml

2）应用模板创建 Hollow 节点

使用 build/edgemark/hollow_edge_node_template.yaml 这个 Deployment 模板，需先填充其中的占位参数：

模板参数	含义
`{{numreplicas}}`	edgemark 集群中 Hollow 节点的数量（Deployment 副本数）
`{{server}}`	暴露给 Hollow 节点加入的服务器地址（即 CloudCore 的负载均衡入口）
`{{edgemark_image_registry}}`	edgemark 镜像仓库地址
`{{edgemark_image_tag}}`	edgemark 镜像 tag

另外注意：external cluster 必须有足够资源运行{{numreplicas}}个 Hollow 节点 Pod。

模板的关键内容（原文照录）：

kind: Deployment apiVersion: apps/v1 metadata: name: hollow-edge-node spec: replicas: {{numreplicas}} selector: matchLabels: app: hollow-edge-node template: metadata: labels: app: hollow-edge-node spec: containers: - name: hollow-edgecore image: {{edgemark_image_registry}}/edgemark:{{edgemark_image_tag}} command: - edgemark args: - --token=$(TOKEN) - --name=$(NODE_NAME) - --http-server=https://{{server}}:10002 - --websocket-server={{server}}:10000 - --v=2 env: - name: NODE_NAME valueFrom: fieldRef: apiVersion: v1 fieldPath: metadata.name - name: TOKEN valueFrom: secretKeyRef: name: tokensecret key: tokendata resources: requests: cpu: 20m memory: 50M securityContext: privileged: true tolerations: - effect: NoExecute key: node.kubernetes.io/unreachable operator: Exists - effect: NoExecute key: node.kubernetes.io/not-ready operator: Exists

几个值得注意的细节：

NODE_NAME通过fieldRef: metadata.name取 Pod 名，从而让每个 Hollow 节点在被测集群中拥有唯一的节点名；
TOKEN从 secrettokensecret的tokendata键注入，对应edgemark的--token参数；
--http-server指向https://{{server}}:10002（边缘节点申请证书的 HTTP 服务），--websocket-server指向{{server}}:10000（消息链路 WebSocket 服务），二者均落在 CloudCore 的负载均衡入口上；
资源请求很小（20m CPU / 50M 内存），这符合"空心"节点的定位：算力开销几乎可以忽略，可以低成本堆出大规模。

填充完成后应用：

kubectl create -f hollow-edge-node_template.yaml

等待这些 Hollow 节点 Pod 进入 Running 状态后，在 edgemark master 上即可看到这些 Pod 已注册为 edgemark master 的节点。至此，edgemark master 与 external cluster 共同组成了 edgemark 集群。

4.4 步骤四：使用 ClusterLoader2 执行性能测试

edgemark 集群搭建完成后，即可配合ClusterLoader2（Kubernetes 官方的可扩展性与性能测试框架）开展压测。运行压测时只需把 provider 配置为kubemark，例如：

./clusterloader --testconfig=config.yaml --provider=kubemark --kubeconfig=${HOME}/.kube/config --v=2

--provider=kubemark的语义是：测试框架将目标集群中的节点视为 Kubemark 式模拟节点进行调度与压测，这与 Edgemark 的 Hollow 节点设计一脉相承。具体测试配置（config.yaml）的编写遵循 ClusterLoader2 的通用规范，可按其官方 Getting started 文档组织用例。

五、edgemark 命令行参数解析

edgemark是一个基于 cobra 的单命令程序（命令名即edgemark，不接受位置参数），其业务参数定义于 hollow_edgecore.go 的addFlags（edge/cmd/edgemark/hollow_edgecore.go#L131-L138），并叠加了 kubelet 的全局 flags（如--docker-only）与globalflag注册的标准全局参数（如-v日志级别）：

参数	默认值	说明（源码注释）
`--token`	空	边缘节点加入集群时使用的令牌（决定接入 CloudCore 的凭据）
`--name`	`fake-node`	该 Hollow 节点的名字，最终作为节点注册名
`--websocket-server`	空	WebSocket 消息服务地址（模板中为`{{server}}:10000`）
`--http-server`	空	边缘节点申请证书所用的 HTTP 服务地址（模板中为`https://{{server}}:10002`）
`--node-labels`	空	附加到节点上的额外标签（map 形式）

这些 flag 会被映射进一份EdgeCoreConfig（EdgeCoreConfig，edge/cmd/edgemark/hollow_edgecore.go#L140-L161），其中针对压测场景做了若干关键覆盖：

DataBase.DataSource固定为/edgecore.db（容器内 SQLite 元数据库路径）；
EdgeHub模块的Token、HTTPServer、WebSocket.Server分别取命令行传入的 token / http-server / websocket-server；
Edged.HostnameOverride取--name，NodeLabels取--node-labels；
kubelet 相关裁剪：RegisterNode置为true（保证节点注册到被测集群），CgroupsPerQOS、EnableControllerAttachDetach置为false，ProtectKernelDefaults置为false——从源码结构看，这些关闭项都是围绕"没有真实容器与内核环境"这一前提做的适配。

六、小结与适用边界

Edgemark 的设计可以概括为三点：其一，双层集群——external cluster 出算力、edgemark cluster 出被测 master 与 CloudCore；其二，Hollow 仿真——用 fake CRI 运行时与一系列 fake 依赖掏空容器执行层，同时保留 edgehub/metamanager 等真实消息与元数据链路，让 CloudCore 感受到"真实的"大规模边缘接入压力；其三，标准化压测出口——Hollow 节点注册为普通节点后，即可直接套用 ClusterLoader2（--provider=kubemark）的成熟用例。

需要明确的适用边界：Edgemark 面向的是云侧组件在大规模节点下的可扩展性测试，它不验证边缘侧真实业务负载，也不替代边缘设备功能测试；搭建前需同时具备 external cluster、edgemark cluster（含 CloudCore 专用节点与 LB）以及包含所需镜像的仓库。相关文档与实现入口可继续深入：build/edgemark/README.md、build/edgemark/edgemark_setup_guide.md、build/edgemark/hollow_edge_node_template.yaml、edge/cmd/edgemark/hollow_edgecore.go 与 edge/pkg/edged/edged.go。

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

创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考