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地址是VIPLB脚本没做健康检查就直接硬编码导致cloudcore连不上真正的控制面。这种问题脚本越“智能”隐藏越深修复成本越高。所以我的设计逻辑非常朴素用最直白的命令替代最炫的封装用可中断的步骤替代不可逆的一键操作用显式声明替代隐式推导。具体体现在四个关键选择上第一证书体系不走自动签发全部手动CA子证书生成。KubeEdge依赖双向TLS认证cloudcore和edgecore之间、edgecore与设备之间都要验身份。很多教程教用keadm init --auto-cert看似方便但一旦证书过期默认365天整个边缘集群就瘫痪且无法热更新。我们采用OpenSSL手动生成根CA服务证书客户端证书所有证书有效期设为10年-days 3650并把私钥权限严格限制为600既安全又省心。第二不复用现有K8s集群的etcdcloudcore独占单节点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服务配置Restartalways、StartLimitIntervalSec0故障自愈能力反而更强。第四所有配置文件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服务器上跑通的数据组件最低要求推荐版本实测不兼容案例操作系统Ubuntu 20.04 / CentOS 7.6Ubuntu 22.004 LTS / OpenEuler 22.03CentOS 8.5systemd版本过高edgecore service启动失败内核版本Linux 4.155.4.0-150-genericUbuntu 22.04Linux 6.1部分ARM板卡cgroup v2默认启用edgecore crashDocker20.10.024.0.7static binaryDocker 25.xcontainerd 1.7与edgecore的CRI接口不兼容Go语言1.191.21.6编译cloudcore/edgecore必需Go 1.22KubeEdge v1.13尚未适配编译报错重点说两个高频雷区第一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_hierarchy0 cgroup_enablecpuset cgroup_enablememory cgroup_memory1 sudo update-grub sudo reboot重启后验证cat /proc/1/environ | tr \0 \n | grep cgroup应输出systemd.unified_cgroup_hierarchy0。第二Docker版本陷阱。网上很多教程让你apt install docker.ioUbuntu 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 binarycurl -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-components1 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类证书缺一不可Root CA证书用于签发所有子证书是整个信任链的根。CloudCore Server证书cloudcore对外提供WebSocket服务端口10000时使用的证书。CloudCore Client证书cloudcore访问K8s apiserver时使用的证书需绑定serviceAccount。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 /CNKubeEdge-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 /CNcloudcore -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 /CNsystem: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 /CNedge-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.yamlapiVersion: 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 - --nameetcd-kubeedge - --data-dir/var/lib/etcd - --listen-client-urlshttp://0.0.0.0:2379 - --advertise-client-urlshttp://192.168.10.100:2379 # cloudcore节点IP - --listen-peer-urlshttp://0.0.0.0:2380 - --initial-advertise-peer-urlshttp://192.168.10.100:2380 - --initial-clusteretcd-kubeedgehttp://192.168.10.100:2380 - --initial-cluster-tokenetcd-kubeedge-cluster - --initial-cluster-statenew 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.yamlCloudCore ConfigMap核心80%的配置错误在这里创建cloudcore-config.yamlapiVersion: 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 DeploymentapiVersion: 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是否Runningkubectl 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创建命名空间与ServiceAccountkubectl create namespace kubeedge kubectl create serviceaccount cloudcore -n kubeedge kubectl create clusterrolebinding cloudcore:default --clusterrolesystem:node --serviceaccountkubeedge:cloudcore这一步赋予cloudcore访问K8s节点资源的权限。注意--clusterrolesystem:node是必须的否则edgeController无法更新Node状态。步骤2准备证书与Secret将前面生成的ca.crt,server.crt,server.key,client.crt,client.key拷贝到/root/kubeedge-certs/目录。创建Secretkubectl create secret generic kubeedge-certs \ -n kubeedge \ --from-fileca.crt/root/kubeedge-certs/ca.crt \ --from-fileserver.crt/root/kubeedge-certs/server.crt \ --from-fileserver.key/root/kubeedge-certs/server.key \ --from-fileclient.crt/root/kubeedge-certs/client.crt \ --from-fileclient.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,pid12345,fd10))如果ss没输出说明cloudcore没起来。此时看日志kubectl logs -n kubeedge deploy/cloudcore --tail50常见错误failed to connect to etcd检查etcd Pod是否Runningkubectl logs -n kubeedge deploy/kubeedge-etcd看是否有ready to serve client requests。x509: certificate is valid for 127.0.0.1, not 192.168.10.100server.crt的hosts没包含cloudcore节点IP重新生成证书。步骤4开放防火墙端口sudo ufw allow 10000/tcp # cloudcore WebSocket端口 sudo ufw allow 10001/tcp # cloudstream端口如果启用 sudo ufw reload4.2 EdgeCore节点部署边缘设备端以树莓派4BUbuntu 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-components1 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.yamlapiVersion: 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.podSandboxImageARM64架构必须用ARM镜像。pause:3.9是官方支持的最新版x86用pause:3.9-amd64。步骤4创建Systemd服务创建/etc/systemd/system/edgecore.service[Unit] DescriptionKubeEdge EdgeCore Service Afternetwork.target [Service] Typesimple Userroot WorkingDirectory/etc/kubeedge ExecStart/usr/local/bin/edgecore Restartalways RestartSec10 KillModeprocess LimitNOFILE65536 [Install] WantedBymulti-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.100telnet 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 typeedge步骤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