KubeEdge边缘计算部署实战：小白也能上手的完整指南

1. 项目概述：为什么说“KubeEdge边缘计算框架，小白也能部署了”不是标题党？

KubeEdge是当前主流的开源边缘计算框架之一，它把Kubernetes的能力延伸到了资源受限、网络不稳、地理位置分散的边缘设备端——比如工厂里的PLC控制器、摄像头模组、车载网关、农业传感器节点，甚至是一台树莓派。但过去两年里，我带过不少刚接触边缘计算的开发者、运维同学和高校学生做KubeEdge实验，90%的人卡在第一步：连集群都起不来。不是因为代码写错了，而是被一堆概念绕晕了——CloudCore/EdgeCore是什么关系？iptables规则怎么配？证书怎么签？etcd要不要单独装？NodePort和HostNetwork到底该选哪个？更别说还要手动编译二进制、改YAML、调证书有效期、处理cgroup v2兼容性问题……这些都不是“不会写代码”的问题，而是“不知道从哪下手”的系统性门槛。

所以当标题里出现“小白也能部署了”，它指的不是跳过所有技术细节，而是把原本需要3小时查文档+2小时试错+1小时重装的部署流程，压缩成一份可线性执行、每步有反馈、失败有定位路径的实操方案。它背后真正解决的是三个现实痛点：第一，环境异构性——边缘设备可能是ARM64架构的Jetson Nano，也可能是x86_64的工控机，还可能是国产芯片平台；第二，网络不可靠性——边缘节点常处于NAT后、无公网IP、带宽波动大，传统K8s的apiserver直连模式根本跑不通；第三，运维轻量化需求——你不可能给每个摄像头旁边配个运维工程师，必须让部署过程足够“傻瓜但可控”，出问题能一眼看出是证书、网络还是权限问题。

我最近在某高校实验室带一个智能巡检机器人项目，用的就是KubeEdge v1.13.0 + Kubernetes v1.28.3组合。整个边缘侧（5台树莓派4B）从零开始部署，包括证书生成、服务启停、日志定位、Pod调度验证，全程由两名大三学生独立完成，总耗时不到4小时。他们没碰过K8s，也没配置过TLS，但能照着步骤一条条执行，并在报错时准确告诉我“edgecore启动失败，日志里提示‘failed to load certificate’”。这说明什么？说明部署流程本身已经足够收敛、可观测、可归因——而这，才是“小白友好”的本质：不是降低技术深度，而是把技术复杂度封装成清晰的输入输出、明确的依赖边界和可复现的错误信号。

这个标题里的“小白”，指的是具备Linux基础操作能力（会ssh、会vi、会systemctl）、理解容器基本概念（镜像/容器/Pod）、能看懂YAML结构但无需掌握K8s内部原理的实践者。它不面向完全零基础的用户，也不面向追求极致定制化的专家，而是精准锚定在“想快速验证边缘AI推理、设备接入或本地化策略下发”这一类真实场景中的中坚力量。接下来的内容，就是我把这套已验证过5轮、覆盖ARM/x86/国产平台、适配主流Linux发行版（Ubuntu 22.04/CentOS 7.9/OpenEuler 22.03）的部署方法，毫无保留地拆解给你看。

2. 整体设计思路：为什么放弃“一键脚本”，坚持手把手分步部署？

很多人看到“小白友好”第一反应是：“那肯定有个install.sh一键搞定吧？”我明确告诉你：本次方案不提供任何一键安装脚本，也不推荐你直接clone网上那些未经验证的自动化部署仓库。这不是故弄玄虚，而是基于过去三年踩过的坑总结出的硬经验。

先说一个真实案例：去年某智能制造客户采购了200台边缘网关，要求统一接入KubeEdge做设备管理。他们图省事，用了社区里一个star数很高的“kubeedge-auto-deploy”脚本。结果上线三天，17台设备出现边缘Pod反复重启，日志里全是context deadline exceeded。排查了两天才发现，那个脚本默认把cloudcore的--master参数写死为https://127.0.0.1:6443，而客户实际用的是高可用K8s集群，apiserver地址是VIP+LB，脚本没做健康检查就直接硬编码，导致cloudcore连不上真正的控制面。这种问题，脚本越“智能”，隐藏越深，修复成本越高。

所以我的设计逻辑非常朴素：用最直白的命令替代最炫的封装，用可中断的步骤替代不可逆的一键操作，用显式声明替代隐式推导。具体体现在四个关键选择上：

第一，证书体系不走自动签发，全部手动CA+子证书生成。KubeEdge依赖双向TLS认证，cloudcore和edgecore之间、edgecore与设备之间都要验身份。很多教程教用keadm init --auto-cert，看似方便，但一旦证书过期（默认365天），整个边缘集群就瘫痪，且无法热更新。我们采用OpenSSL手动生成根CA+服务证书+客户端证书，所有证书有效期设为10年（-days 3650），并把私钥权限严格限制为600，既安全又省心。

第二，不复用现有K8s集群的etcd，cloudcore独占单节点etcd实例。有人会问：“我K8s主节点已经有etcd了，能不能复用？”答案是：可以，但极其不推荐。KubeEdge的cloudcore对etcd的读写模式和K8s apiserver完全不同——它高频写入设备状态、心跳、元数据，而K8s apiserver侧重于资源对象的CRUD。混用会导致etcd WAL日志暴涨、磁盘IO打满，某次我们在某电力项目就因此触发了etcd leader频繁切换。所以本方案强制cloudcore使用独立etcd容器（v3.5.15），通过hostPath挂载持久化目录，彻底隔离。

第三，edgecore不以DaemonSet方式部署，改用systemd服务管理。虽然KubeEdge官方支持用K8s原生方式部署edgecore，但实际落地中你会发现：边缘设备重启后，DaemonSet Pod可能因网络未就绪而拉不起来；或者设备断网再恢复，Pod状态卡在ContainerCreating；更麻烦的是，你想查edgecore日志，得先kubectl logs，再找Pod名，再进容器——而systemd只要journalctl -u edgecore -f就能实时看。我们把edgecore打包成标准Linux服务，配置Restart=always、StartLimitIntervalSec=0，故障自愈能力反而更强。

第四，所有配置文件YAML不嵌套模板变量，全部写死关键参数并加注释。比如cloudcore的configmap里，websocket.server字段不写{{ .WebSocketServer }}，而是直接写https://192.168.10.100:10000，并在下一行用# 注意：此处必须填cloudcore所在节点的内网IP，不能写localhost或127.0.0.1注明。这样做的好处是：当你复制粘贴时，一眼就知道哪里要改；当你排查问题时，不用再去翻values.yaml猜变量值；当你交接给别人时，配置即文档。

这四个选择，表面看是“多此一举”，实则是把部署过程从“黑盒魔法”变成“白盒工程”。每一个步骤你都能解释清楚“为什么这么写”“不这么写会怎样”“改了某个值影响什么”。这才是小白真正能学会、能复用、能举一反三的基础。接下来，我们就按这个思路，一步步把KubeEdge从源码编译到集群跑通。

3. 核心细节解析：从源码到服务，每个环节的关键参数与避坑点

3.1 环境准备：操作系统、内核、Docker版本的硬性约束

别急着敲命令，先确认你的环境是否达标。KubeEdge对底层依赖比K8s更敏感，很多“部署失败”其实源于环境不匹配。我整理了一份经过实测的兼容矩阵，不是官网抄来的理论值，而是真正在树莓派、Jetson、x86服务器上跑通的数据：

重点说两个高频雷区：

第一，cgroup版本问题。KubeEdge v1.13默认只支持cgroup v1。如果你用的是较新内核（如Ubuntu 22.04默认5.15内核），启动时可能遇到：

FATA[0000] failed to run KubeEdge: failed to initialize runtime: failed to get container runtime: failed to dial containerd: failed to connect to containerd: failed to dial containerd: connection refused

这不是containerd没启，而是edgecore压根没尝试连——因为它检测到/sys/fs/cgroup/cgroup.controllers存在，就认定是cgroup v2，直接退出。解决方案只有两个：要么降内核（不现实），要么强制切回cgroup v1。修改GRUB配置：

sudo nano /etc/default/grub # 找到 GRUB_CMDLINE_LINUX 行，末尾添加： # systemd.unified_cgroup_hierarchy=0 cgroup_enable=cpuset cgroup_enable=memory cgroup_memory=1 sudo update-grub && sudo reboot

重启后验证：cat /proc/1/environ | tr '\0' '\n' | grep cgroup应输出systemd.unified_cgroup_hierarchy=0。

第二，Docker版本陷阱。网上很多教程让你apt install docker.io，Ubuntu 22.04默认装的是20.10.21，看着够新，但实际编译KubeEdge时会报：

# k8s.io/kubernetes/pkg/kubelet/cm pkg/kubelet/cm/container_manager_linux.go:123:22: undefined: CpuManagerPolicyOptions

这是因为Docker 20.x绑定的containerd版本太老，与KubeEdge依赖的k8s.io/client-go版本冲突。正确做法是下载Docker 24.0.7的static binary：

curl -fsSL https://get.docker.com -o get-docker.sh sudo sh get-docker.sh # 然后手动替换 sudo systemctl stop docker sudo curl -L "https://download.docker.com/linux/static/stable/x86_64/docker-24.0.7.tgz" | sudo tar -xz -C /usr/bin/ --strip-components=1 sudo systemctl start docker

验证：docker version --format '{{.Server.Version}}'输出24.0.7。

提示：所有边缘设备务必关闭swap分区。KubeEdge的device controller会主动探测/proc/swaps，如果发现swap启用，直接拒绝注册节点。执行sudo swapoff -a，并注释/etc/fstab中swap行。

3.2 证书体系构建：为什么必须手动生成，以及每个证书的用途

KubeEdge的安全模型建立在严格的双向TLS之上，共涉及4类证书，缺一不可：

1. Root CA证书：用于签发所有子证书，是整个信任链的根。
2. CloudCore Server证书：cloudcore对外提供WebSocket服务（端口10000）时使用的证书。
3. CloudCore Client证书：cloudcore访问K8s apiserver时使用的证书（需绑定serviceAccount）。
4. EdgeCore证书：edgecore连接cloudcore时使用的客户端证书，每个边缘节点一份。

很多人试图用cfssl或kubeadm certs生成，结果在edgecore启动时报x509: certificate signed by unknown authority。根本原因是：KubeEdge不认K8s的CA，它要求自己的CA签发的证书链必须完整传递到边缘端。

我们用最原始的OpenSSL手动生成，全程可控：

步骤1：生成Root CA

# 创建CA目录 mkdir -p ~/kubeedge-ca && cd ~/kubeedge-ca # 生成私钥（注意权限！） openssl genrsa -out ca.key 2048 chmod 600 ca.key # 生成CA证书（有效期10年） openssl req -x509 -new -nodes -key ca.key -sha256 -days 3650 -out ca.crt -subj "/CN=KubeEdge-CA"

步骤2：生成CloudCore Server证书

# 创建server证书请求配置 cat > server-csr.json <<EOF { "CN": "cloudcore", "hosts": [ "127.0.0.1", "192.168.10.100", # 替换为cloudcore节点真实IP "localhost" ], "key": { "algo": "rsa", "size": 2048 }, "names": [ { "C": "CN", "ST": "Beijing", "L": "Haidian", "O": "KubeEdge", "OU": "Cloud" } ] } EOF # 生成私钥和CSR openssl genrsa -out server.key 2048 chmod 600 server.key openssl req -new -key server.key -out server.csr -subj "/CN=cloudcore" -config <(cat server-csr.json) # 用CA签发 openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out server.crt -days 3650 -sha256

步骤3：生成CloudCore Client证书（用于访问K8s apiserver）

# 此证书需绑定K8s serviceAccount，所以CN必须是"system:node:cloudcore" cat > client-csr.json <<EOF { "CN": "system:node:cloudcore", "hosts": [], "key": { "algo": "rsa", "size": 2048 }, "names": [ { "C": "CN", "ST": "Beijing", "L": "Haidian", "O": "system:nodes", "OU": "KubeEdge" } ] } EOF openssl genrsa -out client.key 2048 chmod 600 client.key openssl req -new -key client.key -out client.csr -subj "/CN=system:node:cloudcore" -config <(cat client-csr.json) openssl x509 -req -in client.csr -CA /etc/kubernetes/pki/ca.crt -CAkey /etc/kubernetes/pki/ca.key -CAcreateserial -out client.crt -days 3650 -sha256

注意：/etc/kubernetes/pki/ca.crt是你的K8s集群CA，不是上面生成的kubeedge-ca.crt。这是cloudcore作为K8s节点向apiserver认证的身份。

步骤4：生成EdgeCore证书（每个边缘节点独立生成）

# 在边缘节点上执行（IP替换为cloudcore节点IP） cat > edge-csr.json <<EOF { "CN": "edge-node-01", "hosts": [], "key": { "algo": "rsa", "size": 2048 }, "names": [ { "C": "CN", "ST": "Beijing", "L": "Haidian", "O": "KubeEdge", "OU": "Edge" } ] } EOF openssl genrsa -out edge.key 2048 chmod 600 edge.key openssl req -new -key edge.key -out edge.csr -subj "/CN=edge-node-01" -config <(cat edge-csr.json) # 关键！用kubeedge-ca签发，不是K8s CA openssl x509 -req -in edge.csr -CA ~/kubeedge-ca/ca.crt -CAkey ~/kubeedge-ca/ca.key -CAcreateserial -out edge.crt -days 3650 -sha256

最终，cloudcore节点需存放：ca.crt,server.crt,server.key,client.crt,client.key
每个edge节点需存放：ca.crt,edge.crt,edge.key

注意：所有证书文件必须用base64 -w 0 xxx.crt转成单行字符串，填入后续YAML配置。不要直接复制二进制内容，否则YAML解析失败。

3.3 CloudCore服务部署：etcd独立部署与ConfigMap关键字段详解

CloudCore是KubeEdge的“大脑”，它运行在K8s集群内部，负责同步云端与边缘的状态。它的部署不是简单起个Pod，而是一套协同组件：etcd（状态存储）、cloudcore（核心服务）、cloudstream（可选，用于边缘视频流代理）。我们只部署前两者，精简可靠。

etcd独立部署（关键！）
创建etcd-deployment.yaml：

apiVersion: apps/v1 kind: Deployment metadata: name: kubeedge-etcd namespace: kubeedge spec: replicas: 1 selector: matchLabels: app: kubeedge-etcd template: metadata: labels: app: kubeedge-etcd spec: containers: - name: etcd image: quay.io/coreos/etcd:v3.5.15 command: - /usr/local/bin/etcd - --name=etcd-kubeedge - --data-dir=/var/lib/etcd - --listen-client-urls=http://0.0.0.0:2379 - --advertise-client-urls=http://192.168.10.100:2379 # cloudcore节点IP - --listen-peer-urls=http://0.0.0.0:2380 - --initial-advertise-peer-urls=http://192.168.10.100:2380 - --initial-cluster=etcd-kubeedge=http://192.168.10.100:2380 - --initial-cluster-token=etcd-kubeedge-cluster - --initial-cluster-state=new ports: - containerPort: 2379 name: client - containerPort: 2380 name: peer volumeMounts: - name: etcd-data mountPath: /var/lib/etcd volumes: - name: etcd-data hostPath: path: /var/lib/kubeedge-etcd type: DirectoryOrCreate --- apiVersion: v1 kind: Service metadata: name: kubeedge-etcd namespace: kubeedge spec: selector: app: kubeedge-etcd ports: - port: 2379 targetPort: 2379 name: client

执行：kubectl apply -f etcd-deployment.yaml

CloudCore ConfigMap（核心！80%的配置错误在这里）
创建cloudcore-config.yaml：

apiVersion: v1 kind: ConfigMap metadata: name: cloudcore-config namespace: kubeedge data: cloudcore.yaml: | global: hostname: "192.168.10.100" # 必须！cloudcore节点IP iptables: false # 边缘设备通常禁用iptables，这里也关掉 modules: cloudHub: tls: certFile: "/etc/kubeedge/certs/server.crt" keyFile: "/etc/kubeedge/certs/server.key" caFile: "/etc/kubeedge/certs/ca.crt" websocket: enable: true server: "192.168.10.100:10000" # 必须与server.crt的hosts一致 certFile: "/etc/kubeedge/certs/server.crt" keyFile: "/etc/kubeedge/certs/server.key" quic: enable: false deviceController: enable: true edgeController: enable: true nodeStatusUpdateFrequency: "10s" # 边缘心跳间隔，别设太短 cloudStream: enable: false router: enable: false kube: master: "https://192.168.10.100:6443" # K8s apiserver地址 kubeconfig: "/root/.kube/config" # 或用serviceaccount token requesttimeout: "30s"

关键字段解读：

• global.hostname：不是hostname命令输出，而是cloudcore能被边缘节点访问到的IP。如果cloudcore在NAT后，这里必须填公网IP或内网穿透地址。
• cloudHub.websocket.server：必须与server.crt中hosts字段完全一致，否则TLS握手失败。
• edgeController.nodeStatusUpdateFrequency：默认是5s，但在弱网边缘会导致大量重传。实测10s最稳，既能及时感知离线，又不压垮带宽。
• modules.cloudStream.enable：除非你要传视频流，否则一律false。开启后会额外占用200MB内存，且配置极其复杂。

最后部署cloudcore Deployment：

apiVersion: apps/v1 kind: Deployment metadata: name: cloudcore namespace: kubeedge spec: replicas: 1 selector: matchLabels: app: cloudcore template: metadata: labels: app: cloudcore spec: serviceAccountName: cloudcore containers: - name: cloudcore image: kubeedge/cloudcore:v1.13.0 command: - "/bin/bash" - "-c" - "cp -r /etc/kubeedge/certs/* /tmp/ && /usr/local/bin/cloudcore" volumeMounts: - name: certs mountPath: /etc/kubeedge/certs readOnly: true - name: config mountPath: /etc/kubeedge/config - name: tmp mountPath: /tmp volumes: - name: certs secret: secretName: kubeedge-certs # 之前创建的secret，含ca.crt/server.crt/server.key - name: config configMap: name: cloudcore-config - name: tmp emptyDir: {}

执行：kubectl apply -f cloudcore-deployment.yaml

提示：首次启动cloudcore，日志里会出现start cloudhub module successfully，然后停住几秒——这是正常现象，它在等待etcd ready。如果超过2分钟没输出，检查etcd Pod是否Running，kubectl logs -n kubeedge deploy/kubeedge-etcd看是否有ready to serve client requests。

4. 实操过程：从零开始，完整部署流程与每步验证方法

4.1 CloudCore节点部署（云端控制面）

假设你有一台Ubuntu 22.04服务器，IP为192.168.10.100，已安装Docker 24.0.7、Kubernetes v1.28.3（单节点集群），现在开始部署：

步骤1：创建命名空间与ServiceAccount

kubectl create namespace kubeedge kubectl create serviceaccount cloudcore -n kubeedge kubectl create clusterrolebinding cloudcore:default --clusterrole=system:node --serviceaccount=kubeedge:cloudcore

这一步赋予cloudcore访问K8s节点资源的权限。注意：--clusterrole=system:node是必须的，否则edgeController无法更新Node状态。

步骤2：准备证书与Secret将前面生成的ca.crt,server.crt,server.key,client.crt,client.key拷贝到/root/kubeedge-certs/目录。创建Secret：

kubectl create secret generic kubeedge-certs \ -n kubeedge \ --from-file=ca.crt=/root/kubeedge-certs/ca.crt \ --from-file=server.crt=/root/kubeedge-certs/server.crt \ --from-file=server.key=/root/kubeedge-certs/server.key \ --from-file=client.crt=/root/kubeedge-certs/client.crt \ --from-file=client.key=/root/kubeedge-certs/client.key

步骤3：部署etcd与CloudCore依次执行：

kubectl apply -f etcd-deployment.yaml kubectl apply -f cloudcore-config.yaml kubectl apply -f cloudcore-deployment.yaml

等待2分钟，检查状态：

# 确认etcd和cloudcore Pod都在Running kubectl get pods -n kubeedge # 查看cloudcore日志，关键成功标志 kubectl logs -n kubeedge deploy/cloudcore | grep -E "(start.*module|cloudhub.*successfully|edgecontroller.*started)" # 验证cloudcore WebSocket端口是否监听（在cloudcore节点执行） sudo ss -tlnp | grep :10000 # 应输出：LISTEN 0 4096 *:10000 *:* users:(("cloudcore",pid=12345,fd=10))

如果ss没输出，说明cloudcore没起来。此时看日志：

kubectl logs -n kubeedge deploy/cloudcore --tail=50

常见错误：

• failed to connect to etcd：检查etcd Pod是否Running，kubectl logs -n kubeedge deploy/kubeedge-etcd看是否有ready to serve client requests。
• x509: certificate is valid for 127.0.0.1, not 192.168.10.100：server.crt的hosts没包含cloudcore节点IP，重新生成证书。

步骤4：开放防火墙端口

sudo ufw allow 10000/tcp # cloudcore WebSocket端口 sudo ufw allow 10001/tcp # cloudstream端口（如果启用） sudo ufw reload

4.2 EdgeCore节点部署（边缘设备端）

以树莓派4B（Ubuntu 22.04 ARM64）为例，IP为192.168.10.101：

步骤1：安装Docker与基础工具

# 安装Docker 24.0.7 ARM64版 curl -fsSL https://get.docker.com -o get-docker.sh sudo sh get-docker.sh # 下载ARM64 static binary sudo curl -L "https://download.docker.com/linux/static/stable/arm64/docker-24.0.7.tgz" | sudo tar -xz -C /usr/bin/ --strip-components=1 sudo systemctl restart docker # 安装jq（解析JSON日志必备） sudo apt update && sudo apt install -y jq

步骤2：下载并解压EdgeCore二进制

# 创建目录 sudo mkdir -p /etc/kubeedge /var/lib/kubeedge # 下载v1.13.0 ARM64版（注意架构！x86服务器不能用这个） sudo curl -L "https://github.com/kubeedge/kubeedge/releases/download/v1.13.0/keadm-v1.13.0-linux-arm64.tar.gz" | sudo tar -xz -C /usr/local/bin/ # 验证 sudo /usr/local/bin/edgecore --version # 输出：KubeEdge v1.13.0

步骤3：准备证书与配置文件将前面生成的ca.crt,edge.crt,edge.key拷贝到树莓派/etc/kubeedge/certs/目录：

sudo mkdir -p /etc/kubeedge/certs sudo cp ca.crt edge.crt edge.key /etc/kubeedge/certs/ sudo chmod 600 /etc/kubeedge/certs/*

创建/etc/kubeedge/config/edgecore.yaml：

apiVersion: edgecore.config.kubeedge.io/v1alpha2 kind: EdgeCore global: hostname: "edge-node-01" # 节点名称，将显示在K8s Node列表 iptables: false ip: "192.168.10.101" # 边缘节点IP，必须能被cloudcore访问 writeTimeout: 30 readTimeout: 30 modules: edged: hostnameOverride: "edge-node-01" interfaceName: "eth0" # 网卡名，用ip a确认 runtimeType: "docker" dockerAddress: "unix:///var/run/docker.sock" podSandboxImage: "registry.cn-hangzhou.aliyuncs.com/google_containers/pause:3.9" imagePullProgressDeadline: "1m" eventbus: enable: true deviceTwin: enable: true metaManager: enable: true edgeHub: heartbeat: "10s" projectID: "" nodeID: "edge-node-01" tls: caFile: "/etc/kubeedge/certs/ca.crt" certFile: "/etc/kubeedge/certs/edge.crt" keyFile: "/etc/kubeedge/certs/edge.key" websocket: url: "wss://192.168.10.100:10000" # cloudcore IP+端口 certFile: "/etc/kubeedge/certs/edge.crt" keyFile: "/etc/kubeedge/certs/edge.key" caFile: "/etc/kubeedge/certs/ca.crt" dbTest: enable: false serviceBus: enable: false twin: enable: false edged: version: "v1"

关键字段说明：

• global.ip：必须填边缘节点能被cloudcore ping通的IP。如果树莓派走WiFi，确保ip a看到的wlan0地址在此处。
• modules.edgeHub.websocket.url：协议必须是wss://，端口必须是cloudcore的10000，且IP必须与cloudcore server.crt的hosts一致。
• modules.edged.podSandboxImage：ARM64架构必须用ARM镜像。pause:3.9是官方支持的最新版，x86用pause:3.9-amd64。

步骤4：创建Systemd服务创建/etc/systemd/system/edgecore.service：

[Unit] Description=KubeEdge EdgeCore Service After=network.target [Service] Type=simple User=root WorkingDirectory=/etc/kubeedge ExecStart=/usr/local/bin/edgecore Restart=always RestartSec=10 KillMode=process LimitNOFILE=65536 [Install] WantedBy=multi-user.target

启用服务：

sudo systemctl daemon-reload sudo systemctl enable edgecore sudo systemctl start edgecore

步骤5：验证边缘节点注册在cloudcore节点执行：

kubectl get nodes # 应看到： # NAME STATUS ROLES AGE VERSION # edge-node-01 Ready agent,edge 2m v1.13.0

如果STATUS是NotReady，检查：

# 查看边缘节点日志 sudo journalctl -u edgecore -f --since "2 minutes ago" # 常见错误： # "failed to connect to cloudhub" → 检查网络连通性：ping 192.168.10.100，telnet 192.168.10.100 10000 # "x509: certificate signed by unknown authority" → 检查edge.crt是否用kubeedge-ca签发，ca.crt是否一致 # "no route to host" → 检查cloudcore防火墙是否开放10000端口

4.3 首个边缘应用部署：验证Pod能否在边缘运行

部署一个简单的Nginx，验证调度是否生效：

步骤1：打标签让K8s知道这是边缘节点

kubectl label node edge-node-01 node-role.kubernetes.io/edge= kubectl label node edge-node-01 type=edge

步骤2：创建Deployment，指定调度到边缘

apiVersion: apps/v1 kind: Deployment metadata: name: nginx-edge namespace: default spec: replicas: 1 selector: matchLabels: app: nginx-edge template: metadata: labels: app: nginx-edge spec: nodeSelector: node-role.kubernetes.io/edge: "" # 调度到带此label的节点 tolerations: - key: node-role.kubernetes.io/edge operator: Exists effect: NoSchedule containers: - name: nginx image: nginx:1.21.6 ports: - containerPort: 80

执行：kubectl apply -f nginx-edge.yaml

步骤3：验证Pod是否在边缘节点运行

kubectl get pods -o wide # 输出应类似： # NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES # nginx-edge-7b8d9c5f4-2xq9z 1/1 Running 0 45s 172.1