【转】KubeEdge 在 RISC-V 环境的编译、接入与运行实测

ErinD · July 2, 2026, 7:03am

前言

本文转自BlueDot陈冬冬
原文链接：https://mp.weixin.qq.com/s/pb8_PZ0LDKLBug-Z1CIE2Q

正文

随着 RISC-V 生态的持续发展，越来越多边缘计算场景开始关注多架构支持能力。对于 KubeEdge 来说，一个很自然的问题是：它的基础部署链路能否在真实 RISC-V 设备上运行起来？

本文将基于一块真实的 VisionFive2 开发板，展示如何在 Ubuntu Server 24.04.4 riscv64 环境中完成 KubeEdge 的基础部署验证。验证内容包括边缘侧依赖准备、KubeEdge 核心组件编译、边缘节点接入 CloudCore，以及基础容器化应用部署。

本次验证的目标并不是一次性证明 KubeEdge 已经具备完整生产可用能力，而是先确认一个更基础、更实际的问题：在真实 riscv64 环境下，是否可以打通从运行时准备、组件构建、节点接入到工作负载运行的核心流程。

为什么要做这次验证

边缘计算正在走向更多硬件形态，CPU 架构也不再局限于传统 x86 或 Arm。RISC-V 作为一种开放指令集架构，正在逐步进入嵌入式、物联网和边缘计算场景。

在这种背景下，验证 KubeEdge 在 RISC-V 设备上的可用性具有两个意义：

可以初步判断 KubeEdge 在新兴架构上是否具备可用起点；
可以为后续工作提供参考，包括工作负载兼容性测试、网络能力验证和长期稳定性评估。

本次验证使用 VisionFive2 作为目标平台，重点关注一个问题：KubeEdge 在 RISC-V 上的基础部署链路是否可行？

具体来说，需要验证以下内容：

边缘侧依赖是否可以在 riscv64 环境中安装和使用；
edgecore 和 keadm 是否可以在设备上成功编译；
边缘节点是否可以成功接入 CloudCore；
基础容器化工作负载是否可以在边缘侧正常运行。

前提条件

在开始之前，需要准备好硬件设备、操作系统环境和相关软件依赖。

硬件环境

本次验证使用的硬件如下：

开发板：VisionFive2
CPU 架构：RISC-V 64-bit
SoC：JH7110

操作系统

设备系统环境如下：

OS：Ubuntu Server 24.04.4
Architecture：riscv64
Image：

https://cdimage.ubuntu.com/releases/24.04.4/release/ubuntu-24.04.4-
preinstalled-server-riscv64+jh7110.img.xz

软件版本

本次验证中使用的软件版本如下：

验证范围

本次工作是一次基础能力验证，不是完整的生产可用性评估。

本次已验证内容

本轮验证覆盖以下内容：

基础操作系统和依赖环境准备；
容器运行时安装与配置；
KubeEdge 核心组件编译；
边缘节点接入 CloudCore；
基础应用部署与运行。

暂未覆盖内容

以下内容本次没有完整展开，后续仍需要继续验证：

多类型工作负载和多副本场景；
Service、DNS 以及更深入的 CNI 网络能力；
断连、重连和故障恢复场景；
长时间稳定性运行测试；
更多 RISC-V 开发板和系统发行版兼容性验证。

第 1 步：准备容器运行时环境

在启动 KubeEdge 之前，首先需要在 VisionFive2 上准备边缘侧运行时环境。该步骤主要包括安装和配置 runc、containerd、crictl、CNI plugins、nerdctl 和 buildkit。

在这个过程中，需要特别注意两类配置：

containerd 的 cgroup 驱动配置；
容器运行时使用的 pause 镜像。

安装 runc 和 containerd

sudo aptupdate&&sudoaptinstall-yrunc

wgethttps://github.com/containerd/containerd/releases/download/v2.2.2/containerd-2.2.2-linux-riscv64.tar.gz
sudotarCxzvf/usr/localcontainerd-2.2.2-linux-riscv64.tar.gz

sudocurl-Lhttps://raw.githubusercontent.com/containerd/containerd/v2.2.2/containerd.service-o/etc/systemd/system/containerd.service

sudomkdir-p/etc/containerd
containerdconfigdefault|sudotee/etc/containerd/config.toml

sudosed-i's/SystemdCgroup = false/SystemdCgroup = true/'/etc/containerd/config.toml
sudosed-i's#sandbox_image = ".*"#sandbox_image = "registry.k8s.io/pause:3.9"#'/etc/containerd/config.toml

sudosystemctldaemon-reload
sudosystemctlenable--now containerd

安装 crictl

wget https://github.com/kubernetes-sigs/cri-tools/releases/download/v1.35.0/crictl-v1.35.0-linux-riscv64.tar.gz
sudotarxzvfcrictl-v1.35.0-linux-riscv64.tar.gz-C/usr/local/bin

sudotee/etc/crictl.yaml<<EOF
runtime-endpoint:unix:///run/containerd/containerd.sock
image-endpoint:unix:///run/containerd/containerd.sock
timeout:10
debug:false
EOF

安装 CNI plugins

wget https://github.com/containernetworking/plugins/releases/download/v1.9.1/cni-plugins-linux-riscv64-v1.9.1.tgz
sudomkdir-p/opt/cni/bin
sudotarCxzvf/opt/cni/bincni-plugins-linux-riscv64-v1.9.1.tgz

sudomkdir-p/etc/cni/net.d
sudochmod755/etc/cni/etc/cni/net.d
sudotee/etc/cni/net.d/87-loopback.conf<<EOF
{
    "cniVersion":"0.3.1",
    "name":"lo",
    "type":"loopback"
}
EOF

安装 nerdctl 和 buildkit

wget https://github.com/containerd/nerdctl/releases/download/v2.2.2/nerdctl-2.2.2-linux-riscv64.tar.gz
sudotarCxzvvf/usr/local/binnerdctl-2.2.2-linux-riscv64.tar.gz

wgethttps://github.com/moby/buildkit/releases/download/v0.28.1/buildkit-v0.28.1.linux-riscv64.tar.gz
sudotarCxzvvf/usr/localbuildkit-v0.28.1.linux-riscv64.tar.gz

sudotee/etc/systemd/system/buildkitd.service<<EOF
[Unit]
Description=BuildKitDaemon(containerdworker)
Documentation=https://github.com/moby/buildkit
After=containerd.service
Requires=containerd.service

[Service]
Type=notify
ExecStart=/usr/local/bin/buildkitd--oci-worker=false--containerd-worker=true--containerd-worker-namespace=k8s.io--containerd-worker-addr=/run/containerd/containerd.sock
Restart=always
User=root
Group=root
LimitNOFILE=65535

[Install]
WantedBy=multi-user.target
EOF

sudosystemctldaemon-reload
sudosystemctlenable--now buildkitd

完成上述步骤后，边缘节点运行 KubeEdge 所需的基础运行时环境已经准备完成。

第 2 步：构建 RISC-V 兼容的 pause 镜像

在环境准备过程中，一个比较实际的问题是 pause 镜像兼容性。

为了让当前环境中的运行时链路更加可控，本次手动构建了一个适用于 RISC-V 的 pause:3.9 镜像，并将其加载到 KubeEdge 使用的本地 containerd 命名空间中。

mkdir -ppause-build/bin
cdpause-build

curl-LOhttps://raw.githubusercontent.com/kubernetes/kubernetes/v1.28.0/build/pause/linux/pause.c
sudoaptinstall-ygcc
gcc-Os-Wall-Wextra-static-obin/pause-riscv64pause.c

teeDockerfile<<EOF
FROMscratch
ARGARCH=riscv64
ADDbin/pause-${ARCH}/pause
ENTRYPOINT["/pause"]
EOF

sudonerdctl-nk8s.iobuild-tregistry.k8s.io/pause:3.9 .

这一步主要是为了避免后续创建 Pod 时因为镜像架构不兼容而失败。

第 3 步：在 riscv64 上编译 KubeEdge 组件

容器运行时准备完成后，下一步需要验证 KubeEdge 组件本身是否可以在 RISC-V 设备上成功构建。本次重点编译两个与边缘侧部署链路最相关的二进制文件：

edgecore
keadm 安装 Go

安装 Go

wget https://mirrors.aliyun.com/golang/go1.22.4.linux-riscv64.tar.gz
sudo tar -C /usr/local -xzf go1.22.4.linux-riscv64.tar.gz

echo "export PATH=\$PATH:/usr/local/go/bin" >> ~/.bashrc
source ~/.bashrc
go version

拉取源码并编译 edgecore / keadm

git clone https://github.com/kubeedge/kubeedge.git
cd kubeedge
git checkout v1.21.0

GIT_VERSION=$(git describe --tags --abbrev=0 || echo "v0.0.0-master")
GIT_COMMIT=$(git rev-parse --short HEAD)
GIT_TREE_STATE=$(if git status --porcelain | grep -q .; then echo "dirty"; else echo "clean"; fi)
BUILD_DATE=$(date -u +'%Y-%m-%dT%H:%M:%SZ')

LDFLAGS="-X github.com/kubeedge/kubeedge/pkg/version.gitVersion=${GIT_VERSION} \
-X github.com/kubeedge/kubeedge/pkg/version.gitCommit=${GIT_COMMIT} \
-X github.com/kubeedge/kubeedge/pkg/version.gitTreeState=${GIT_TREE_STATE} \
-X github.com/kubeedge/kubeedge/pkg/version.buildDate=${BUILD_DATE} \
-s -w"

GOARCH=riscv64 go build -ldflags "${LDFLAGS}" -o edgecore-riscv64 ./edge/cmd/edgecore
GOARCH=riscv64 go build -ldflags "${LDFLAGS}" -o keadm-riscv64 ./keadm/cmd/keadm/

sudo cp keadm-riscv64 /usr/local/bin/keadm

编译过程能够顺利完成，这本身就是一个重要结果：在本次测试版本路径下，KubeEdge 核心组件可以在该 RISC-V 平台上完成本地编译。

第 4 步：打包安装文件

为了方便后续复现和迁移，本次还将编译得到的 edgecore 二进制文件打包成安装镜像。

mkdir -p install/usr/local/bin/
cp edgecore-riscv64 install/usr/local/bin/edgecore
cd install
tar zcvf kubeedge-v1.21.0-linux-riscv64.tar.gz usr/

tee Dockerfile <<EOF
FROM busybox:stable
ADD kubeedge-v1.21.0-linux-riscv64.tar.gz /
CMD ["sh"]
EOF

sudo nerdctl -n k8s.io build -t docker.io/kubeedge/installation-package:v1.21.0 .

这一步不是验证链路的最终目标，但有助于后续分发、部署和重复验证。

第 5 步：将边缘节点接入 CloudCore

依赖和二进制文件准备完成后，可以使用 keadm join 将 VisionFive2 节点接入云端 CloudCore。

这一步是整个验证中的关键环节，用于确认 RISC-V 边缘节点与 CloudCore 的云边连接链路是否可用 。

sudo keadm join \
--cgroupdriver=systemd \
--cloudcore-ipport=<CLOUDCORE_IP>:30000 \
--hub-protocol=websocket \
--certport=30002 \
--kubeedge-version=v1.21.0 \
--remote-runtime-endpoint=unix:///run/containerd/containerd.sock \
--edgenode-name=vf2-2 \
--set modules.edgeStream.server=<CLOUDCORE_IP>:30004,modules.edgeStream.enable=true,modules.metaManager.enable=true,modules.metaManager.metaServer.enable=true,modules.eventBus.enable=false,modules.serviceBus.enable=true,modules.edgeHub.websocket.server=<CLOUDCORE_IP>:30000 \
--token=<TOKEN>

执行完成后，边缘节点能够成功加入集群，并且节点状态正常。

这说明 VisionFive2 作为 RISC-V 边缘节点，已经可以完成与 CloudCore 的基础接入验证。

第 6 步：在边缘节点上运行基础工作负载

节点成功接入只是第一步。为了完成完整验证链路，还需要确认边缘侧是否能够真正运行容器化应用。

本次使用一个简单的 Nginx 应用进行验证。

tee edgetest.yaml<<EOF
apiVersion:apps/v1
kind:Deployment
metadata:
name:nginx-edge
spec:
replicas:1
selector:
    matchLabels:
      app:nginx-edge
template:
    metadata:
      labels:
        app:nginx-edge
    spec:
      nodeName:vf2-2
      hostNetwork:true
      automountServiceAccountToken:false
      containers:
      -name:nginx-edge
        image:nginx
        imagePullPolicy:IfNotPresent
        ports:
        -containerPort:80
EOF

kubectlapply-fedgetest.yaml

部署完成后，Nginx 应用能够在边缘节点上正常创建并运行。

至此，本次验证的核心链路已经闭环：

依赖环境准备完成；
KubeEdge 组件成功编译；
RISC-V 边缘节点成功接入 CloudCore；
基础容器化工作负载成功运行。

验证结果

基于本轮测试结果，可以得到以下阶段性结论。

VisionFive 2 上可以安装边缘侧依赖

在 VisionFive2 的 Ubuntu 24.04.4 riscv64 环境中，containerd、runc、crictl、CNI plugins、nerdctl 和 buildkit 等基础运行时组件可以完成安装和配置。

KubeEdge 核心组件可以在 riscv64 上编译

edgecore 和 keadm 均可以在当前 RISC-V 环境下成功编译，说明 KubeEdge 在该平台上具备可行的源码构建路径。

边缘节点可以成功接入 CloudCore

通过 keadm join，VisionFive2 节点可以接入云端，并保持正常节点状态，说明 KubeEdge 在 RISC-V 上的基础云边接入链路是可行的 。

▍基础工作负载可以在边缘侧运行

Nginx 应用能够成功部署到边缘节点，并在设备侧正常运行。这说明当前环境不仅可以完成编译和接入，也能够支撑基础容器化工作负载。

当前结论

如果用三个词概括本轮验证结果，可以总结为：

可编译
可接入
可运行

也就是说，在本次测试环境下，KubeEdge 已经能够在 VisionFive2 RISC-V 设备上完成基础部署链路验证 。

对于希望在 RISC-V 设备上探索 KubeEdge 的开发者来说，这可以作为一个可参考的起点。

后续工作

扩展更多类型的工作负载兼容性测试；
系统验证 Service、DNS 和更深入的 CNI 网络行为；
验证断连、重连和故障恢复能力；
在真实设备上进行长时间稳定性观察；
覆盖更多 RISC-V 开发板和系统组合。

只有完成这些更系统的验证，才能从“可以跑起来“进一步走向“足够稳定、足够可靠”。

总结

本次基于 VisionFive2 的验证表明，KubeEdge v1.21.0 可以在 Ubuntu 24.04.4 riscv64 环境中完成基础端到端部署流程：

运行时环境可以准备；
核心组件可以编译；
边缘节点可以接入云端；
基础工作负载可以成功运行。

对于 RISC-V 生态来说，这是一个小但具体的进展。对于 KubeEdge 在新兴架构上的验证工作来说，它也提供了一个可复现、可继续扩展的实践参考。