我们团队在做一个面向工业产线的AI边缘推理平台时选型阶段经历了挺多纠结。一开始大家各有各的想法有人觉得直接写个Python服务跑在工控机上就行有人认为用docker-compose把几个容器跑起来就够了。但真正进了POC面对几十种设备协议、多个边缘节点、模型版本要更新、推理结果要回传、现场还要远程运维这些现实问题时单纯“装个服务”的思路完全撑不住。最后落地方案定成了Kubernetes加EdgeX Foundry的组合前者负责容器编排和平台化能力后者专门解决设备接入和数据治理再在K8s上挂一层模型推理服务。这篇文章就是这个项目从架构设计到落地部署的一次完整复盘适合正在做边缘AI平台、工业物联网数据中台或者想了解EdgeX和K8s怎么配合使用的朋友。1. 为什么这套组合能打先把Kubernetes和EdgeX各自的定位说清楚1.1 EdgeX Foundry解决的是“设备接入最后一公里”EdgeX Foundry是一个由Linux基金会托管的边缘物联网中间件框架设计目标非常纯粹把五花八门的设备接入问题抽象成标准服务。不管是Modbus TCP、OPC UA、BACnet、MQTT还是厂商私有的串口协议EdgeX都通过Device Service设备服务统一接入再通过Core Services提供数据采集、元数据管理、命令下发等能力。它的核心思想是“协议无关”上层应用不需要关心数据到底是通过485总线还是网络TCP进来的收到的都是统一格式的Event和Reading。这个价值在做边缘AI时特别明显。我们做产线异常检测现场设备有的走Modbus有的走S7还有几个老设备只能通过串口采如果没有EdgeX这一层AI推理服务就要自己适配每一种协议做出来的东西换个产线就废了。EdgeX把数据从设备侧“拉平”之后推理模块只需要从消息总线取数据、算结果、通过命令通道写回控制指令整个过程干净利落。1.2 Kubernetes解决的是“边缘节点的平台化难题”设备接入问题解决了下一步是平台怎么落地。边缘节点算力有限、网络不稳定、运维人员水平参差不齐这套环境不能指望手工装环境、手动更新程序。Kubernetes的价值在这里就浮现出来了容器化之后模型推理服务、EdgeX各模块、监控组件都能用声明式的方式部署节点挂了Pod会自动调度到其他节点模型要升级滚动更新直接完成不中断业务每个服务能设置CPU和内存Limit防止一个模块把节点资源吃满拖垮整个系统。用K8s还有一个容易被忽略的好处它把“应用如何部署”和“应用是什么”解耦了。你把EdgeX包成一个Chart把模型推理服务做成标准镜像以后新接一个工厂只要导入镜像、改一下设备配置半小时就能上线一套新平台。这在传统手工部署时代是不可想象的。1.3 这套组合不适合的场景选型要诚实当然Kubernetes加EdgeX并不是银弹。如果只是单机单业务跑一个摄像头做推理告警直接写个Docker Compose反而更轻快。K8s集群的运维成本是实打实的etcd、网络插件、存储插件都要有人懂EdgeX本身模块多学习曲线也不低。我们选它是出于多节点、多协议、平台化复制的需求如果你的场景是“一次部署、永远不动”那完全没必要上这么重的架构。做技术选型最怕的就是“手里拿把锤子看什么都是钉子”。2. 平台整体架构从数据采集到推理上云的完整链路2.1 分层架构设计接入层、核心层、业务层、管理面整体上我们把平台分成了四层。接入层由EdgeX的Device Services组成负责把现场设备接进来核心层是EdgeX的Core Services加Support Services负责数据的提取、转换、路由和存储业务层是跑在K8s上的AI推理服务、规则引擎、数据上报服务这是我们自己的代码管理面由Kubernetes的监控、日志、告警组件组成负责整个集群的运维和可观测性。这四层不是各管各的数据流是串起来的设备服务把数据采上来发给Core DataCore Data通过消息总线广播给所有订阅者规则引擎和处理服务消费数据筛选出需要推理的样本送给推理模块推理模块的结果一方面通过EdgeX Command服务写回设备比如控制电机停机一方面通过上报服务发送到云端平台。管理面则随时盯着每一个环节的健康状态。这个数据链路设计有一个原则每一层之间都通过接口或消息解耦谁挂了都不能拖垮整个流程。比如推理服务挂了EdgeX的数据采集和设备接入不能受影响这让故障隔离变得极其简单。2.2 EdgeX核心服务清单及在K8s中的部署形态EdgeX Foundry的核心服务大体分以下几类这个清单可以用来对应到K8s的工作负载上服务作用K8s部署形态说明core-data接收设备数据并持久化对外提供APIDeployment 内部Service数据量大的情况下建议调大副本并关注Rediscore-metadata管理设备、Profile、地址等元数据Deployment只存元数据数据量小不需要很高性能core-command接收指令并下发到设备服务Deployment供上层应用调用不直连设备core-keeper (3.x)注册中心与配置中心Deployment代替了旧版的consul的部分能力support-rulesengine基于规则对数据做实时判断Deployment可以用来做简单的阈值告警和推理触发support-scheduler定时任务调度Deployment用于周期性采集或定期清理数据kong / edgex-proxyAPI网关统一对外提供安全入口Deployment生产环境建议开启鉴权redis存储与消息总线Deployment PVC是EdgeX的“数据枢纽”必须做好持久化vault密钥管理Deployment安全服务生产环境不要省在K8s里Core Metadata这类服务对状态要求很低直接用Deployment跑就行Redis这类有状态组件要用StatefulSet加PVCKong需要配置路由规则通常再用一个LoadBalancer或Ingress暴露出去。EdgeX的各个服务其实都在同一个逻辑网络中通过内部DNS互相访问这个特性天然适配K8s的网络模型。2.3 AI推理服务怎么挂到平台上独立服务加异步消息AI推理模块我们没有塞进EdgeX里而是做成了独立的Deployment。主要考虑是EdgeX擅长的是设备接入和数据管理模型推理有自己的生命周期和扩展方式混在一起会让两边都别扭。推理服务的标准形态是一个gRPC服务或HTTP服务内部加载ONNX或TensorRT模型输入是EdgeX事件中的读数输出是推理结果和置信度。推理服务和EdgeX之间我们用异步消息通信具体用的是EdgeX的MessageBus默认走Redis Stream或MQTT。设备数据到了core-data之后通过消息总线广播推理服务以订阅者身份消费数据处理完的结果再通过消息总线或直接调用core-command API写回。这个“异步消费”模式让推理服务可以随时独立重启、弹性扩展不会阻塞数据采集链路。3. Kubernetes在边缘场景落地的关键优化点3.1 边缘集群选型K3s、KubeEdge、标准K8s怎么选Kubernetes本身有多个发行版在边缘场景要擦亮眼睛。标准Kubernetes适合功能完整的边缘节点对机器配置要求高一些K3s是Rancher出的轻量级发行版把很多边缘用不到的功能裁剪掉了安装包只有几十兆跑在嵌入式设备里都行KubeEdge则是专门为边云协同设计的方案云端和边缘端分开管理适合海量边缘节点的场景。我实际测下来如果边缘节点是常规X86工控机或性能还行的ARM盒子K3s是最舒服的。它是标准K8s的压缩包API完全兼容我们本地开发用的Minikube配置到了现场跑在K3s上几乎不用改而且K3s自带SQLite存储后端比etcd轻量得多对单主节点边缘部署非常友好。如果你边缘侧只有一两台机器别上KubeEdge那是给成百上千节点Scale Out设计的复杂度不划算。3.2 存储、网络、时区、设备透传这些“边缘专属硬骨头”边缘场景和云端最大的区别在于服务器不在一块、网络不稳定、外设五花八门。这里有几个坑是必须提前处理的。存储上云里有Ceph、云盘随便用边缘节点往往只有一块本地硬盘。EdgeX的Redis、Vault都需要持久化我们统一用local-path-provisioner提供的本地PV每个节点一个数据落在宿主机目录里再通过标签约束Pod调度到指定节点。这里必须说清楚用本地PV意味着数据只在该节点有状态Pod不能随便漂移所以在设计上就要给核心存储服务加上nodeSelector和调度约束。网络方面边缘集群没有云LoadBalancer我们直接把EdgeX和推理服务的NodePort开出来再用Nginx做统一入口如果是多节点高可用场景外层再挂一层Keepalived之类的虚拟IP。时区是个隐蔽问题容器默认是UTC时区模型按北京时间做时序数据分析会差8小时所有和业务时间相关的镜像都要在Dockerfile里显式设置TIME_ZONE或者用环境变量在运行时注入。设备透传是另一个大头工业相机、USB加密狗、串口设备都要直接捅进容器里。K8s的Device Plugin机制可以管理GPU和特殊设备但对串口这类简单设备用hostPath把/dev/ttyS0映射进容器最省事再用privileged权限允许容器访问宿主机设备。这样做有安全风险边缘内网环境可以接受但要注意对端口和设备做白名单限制。3.3 资源规划与离线部署镜像、存储、节点评估边缘节点资源紧张K8s的资源请求和限制必须设得好。以我们的单节点工控机4核8GB为例EdgeX全家桶加Redis通常需要大约2.5GB内存推理服务预留1GB左右基础系统占1GB多整体8GB是够用的但4GB很紧张跑起来会频繁触发OOM。建议给每个工作负载都设定好requests和limitsLimit不能超过节点总资源的一定比例给系统内核和K8s组件留足余量。离线部署是边缘项目常遇到的需求。工厂现场没有外网K8s节点又要拉镜像这是很现实的问题。我们在构建流程里就把所有需要的镜像推到本地镜像仓库比如Harbor在目标节点上把镜像预加载到containerd或docker里如果节点数量多再用registry mirror的方式让节点从内网仓库拉取。所有Helm chart和依赖包要提前打包脚本里也尽量不用在线安装命令。这类工作在项目一开始就要规划好否则到了现场想装个命令都装不上。3.4 利用Helm实现一键部署与版本管理到了第二个、第三个现场节点的时候再手工逐个部署无疑是在惩罚自己。我们把EdgeX和推理服务都打成了Helm Chart用一套values.yaml控制不同现场的项目配置包括设备连接信息、模型版本、资源限制、存储路径等。部署时一条命令helm repo add edgexfoundry https://edgexfoundry.github.io/edgex-helm helm install edgex edgexfoundry/edgex --namespace edgex --create-namespace -f values.yaml后端推理服务也用Helm管理整个过程现在可以用一条脚本跑完先检查节点状态再导入镜像然后执行Helm安装最后等所有Pod Ready。原来耗时一天的上线工作现在压缩到20分钟以内而且每次更新的内容都在版本控制里这对企业交付来说价值非常大。4. 实战记录从裸机到平台稳定运行的全过程4.1 阶段一准备边缘节点和K3s集群边缘节点建议用Ubuntu 22.04 LTSK3s版本我们当时用的是v1.28系列。安装命令很简单关键是确定好参数curl -sfL https://rancher-mirror.rancher.cn/k3s/k3s-install.sh | \ INSTALL_K3S_MIRRORcn sh -s - \ --write-kubeconfig-mode 644 \ --docker \ --disable servicelb \ --disable traefik这里有几个点需要解释--docker让K3s使用Docker作为容器运行时方便边缘场景下手动导入镜像和排查问题--disable servicelb和--disable traefik是去掉内置的负载均衡器和入口控制器因为我们自己用Nginx接管流量避免端口冲突和资源浪费。安装完成后用kubectl get nodes确认节点Ready再给节点打几个自定义Labelkubectl label node edge-node-01 node-role.kubernetes.io/workeredge kubectl label node edge-node-01 storage-nodetrue kubectl label node edge-node-01 inference-nodetrueLabel的作用是给后续的部署提供“调度锚点”比如有状态服务只能到storage-node上跑推理服务要到inference-node跑。这个做法在单一节点上看着多余但当边缘侧有主备机、多台计算节点的时候没有这些约束调度器会把Pod放到不合适的机器上。4.2 阶段二部署EdgeX Foundry核心服务EdgeX的Helm Chart会把所有服务一次性铺开。我们根据实际需求做的裁剪是关掉了不需要的示例设备服务AppService、Random Device Service只保留真正的设备服务和核心服务同时关闭了安全服务组的Vault内网环境减少资源消耗并把持久化存储打开。values.yaml关键配置片段参考如下persistence: enabled: true storageClass: local-path redis: persistence: enabled: true size: 2Gi vault: enabled: false devices: modbus: enabled: true # 关键所有Pod的资源限制 resources: coreData: requests: { cpu: 100m, memory: 128Mi } limits: { cpu: 1000m, memory: 512Mi } redis: requests: { cpu: 100m, memory: 256Mi } limits: { cpu: 1000m, memory: 1024Mi }部署完成后逐项检查Pod状态kubectl get pods -n edgex -w这里最容易被忽略的是Redis。EdgeX在K8s里的服务几乎全部依赖Redis做消息总线和存储如果Redis不正常所有服务都会像“连锁反应”一样报错。所以生产环境部署一定先把Redis的PVC确认好再检查它是否正常读写。用kubectl exec进Redis容器执行一次PING和SET测试确保没有权限和存储问题。4.3 阶段三接入一台真实Modbus设备我们项目的第一个真实接入对象是一台温控仪走Modbus TCP协议。接入步骤是这样的先在core-metadata里定义Device Profile声明数据的类型温度值Float32和地址寄存器地址100然后在Device Service配置里填上从站的IP和端口最后通过Device Service把设备实例添加到设备列表里。设备实例定义大致如下apiVersion: edgexfoundry.org/v1 kind: Device metadata: name: temperature-controller-01 spec: profile: temperature-sensor-profile serviceName: edgex-device-modbus protocols: modbus-tcp: Address: 192.168.1.20 Port: 502 UnitID: 1配置完并不是万事大吉设备服务起来之后我用EdgeX的Core Data API查数据发现温度值一直不来。排查了一圈原因是Modbus轮询周期在Profile里没设置Device Service不知道要定时去问设备要数据。后来在Profile的discovery和schedule里加上轮询配置数据才稳定入库。这里也提醒大家EdgeX的“设备接入”不是“设备插上线就完事”轮询、批量读取、数据分析这些参数都要在Profile里提前定义好。4.4 阶段四部署AI推理服务并打通数据流推理服务我们用的是Triton Inference Server加载ONNX模型模型做的是产线关键设备的温度与振动联合异常检测。服务部署在独立的命名空间inference下为了能让它消费EdgeX消息我们把EdgeX的Redis服务暴露为内部Service让推理服务通过该地址订阅消息。关键配置参考apiVersion: apps/v1 kind: Deployment metadata: name: anomaly-predictor namespace: inference spec: replicas: 1 selector: matchLabels: app: anomaly-predictor template: metadata: labels: app: anomaly-predictor spec: nodeSelector: inference-node: true containers: - name: predictor image: registry.internal/anomaly-predictor:2.3.1 env: - name: EDGEX_MESSAGEBUS_HOST value: edgex-redis.edgex.svc.cluster.local - name: EDGEX_MESSAGEBUS_PORT value: 6379 - name: MODEL_PATH value: /models/anomaly.onnx resources: requests: { cpu: 500m, memory: 512Mi } limits: { cpu: 2000m, memory: 1536Mi }数据流打通之后我们在现场做过一次通报异常的验证温度超过阈值模型输出异常标签和置信度推理服务通过调用EdgeX Core Command API给温控仪下发“启动冷却”指令从数据事件到设备动作的端到端时延不到500毫秒。这个结果客户很满意也证明K8s加EdgeX合在一起在工业实时控制场景是能扛住需求的。4.5 阶段五监控、日志与告警平台稳定运行后最重要的工作就是可观测性。我们把Prometheus和Grafana部署到集群里采集三类指标节点资源CPU、内存、磁盘、K8s工作负载状态、EdgeX服务自定义指标设备数据点数、消息延迟、错误次数。日志采集用的Loki加Promtail把EdgeX所有服务的日志统一收拢按命名空间和Pod名检索。告警规则也设了几条关键规则任一EdgeX核心Pod重启超过3次、Redis持久化失败、节点CPU连续5分钟超过85%、推理服务连续10分钟没有收到新数据。这些规则直接对接企业微信群机器人现场运维人员能够在问题刚冒头的时候就介入处理。这个阶段在项目里可能不显眼但实际交付的时候客户最看重的恰恰是“出了故障能不能快速定位”。5. 常见问题和排查实录帮你避开我踩过的坑5.1 EdgeX在K8s中部署与启动的典型故障现象根因解决方式core-data反复重启Redis连接失败或PVC异常先确认Redis Pod健康执行redis-cli ping再检查PVC状态和宿主机存储空间edgex-core-metadata启动报注册中心连接失败core-keeper或consul未就绪调整启动顺序给metadata服务增加initContainer等待依赖服务Kong网关启动失败与K8s里其他服务的端口冲突检查NodePort占用修改端口或改用Ingress设备服务连接设备超时设备IP端口在容器网络里不可达使用hostNetwork模式或为设备服务增加hostAliases和防火墙放行磁盘写满导致Redis崩溃日志和Data持久化都写在本地磁盘配置日志轮转使用PVC定期清理历史数据每次排查EdgeX在K8s里出问题我的经验是先看日志再看状态不要凭感觉重启。先执行kubectl logs看具体报错再结合kubectl describe pod看调度、挂载、存活探针是否正常。毕竟边缘环境的设备和网络千差万别不看到实际日志就重启往往是白忙一场。5.2 数据链路不通的排查思路与口诀数据链路是EdgeX集成最容易出问题的部分。我自己总结了一套“三步定位法”第一步用Core Data API查最近事件确认数据是否进入EdgeX第二步看规则引擎或推理服务是否消费到消息检查消息总线的Topic权限和格式第三步确认结果是否成功写回设备或上报云端检查Command服务和目标设备地址。用口决来记就是“采-存-流-算-回”。数据没到Core Data问题出在设备或设备服务到了Core Data但推理没响应问题出在消息总线和订阅逻辑推理有结果但没执行指令问题出在Command链路。这个排查顺序可以覆盖绝大多数数据链路故障避免东一榔头西一棒子。5.3 性能与稳定性相关的典型案例推理延迟波动是我们实际遇到过的最棘手的性能问题。一开始模型在推理服务器上跑单次推理在100毫秒左右但集成到平台后发现延迟有时飙到1秒以上。排查下来原因有两个一是没有给推理Pod设置足够的CPULimit导致CPU被抢占二是加载模型时没有预热每次冷启动都要重新加载模型文件。我们把模型加载逻辑改成服务启动时预加载、并设置了CPU的requests和limits后延迟稳定在150毫秒以内。另一个稳定性问题是EdgeX服务之间的内存泄漏。跑了两周后个别Device Service的内存从200MB慢慢涨到1.5GB最终被K8s OOMKilled。后来在Device Service配置里缩短了批量数据缓冲区的刷新时间同时对服务增加了内存Limit和自动重启策略问题才算控制住。这里也再次说明K8s的资源限制不是写来好看的它就是在逼你优化服务的资源使用让系统在长期运行时保持可预测。5.4 独家避坑心得生产环境的三个建议第一不要在生产环境开着Vault。EdgeX的安全服务Vault、Kong鉴权功能很强大但边缘节点的资源和运维能力有限一旦Vault的Token和密钥管理出了问题整个EdgeX服务会被密钥认证挡住无法启动。在内网隔离的生产环境中关闭安全服务组把安全重心放在网络隔离和系统加固上是更务实的做法。第二版本升级之前一定要看EdgeX的Breaking Changes。EdgeX从2.x升级到3.x有些服务的名称和API路径变化很大直接从旧版本的应用迁到新版本会碰到一堆404和字段错误。建议新项目直接用当前维护版本老项目升级前先对照官方的迁移文档逐一调整。第三把集群故障的场景演练做在前面。边缘现场的供电情况不可控断电重启之后K8s和EdgeX能不能自动恢复我们在测试环境模拟过“断电后重启”结果发现如果PVC挂载顺序不对Pod会有概率起不来。通过调整存储驱动的重挂载策略以及在K8s里配置Pod的restartPolicy和terminationGracePeriodSeconds现在断电恢复已经非常稳了。6. 写在最后的体会这套Kubernetes加EdgeX的AI边缘推理平台上线小半年我有一个越来越清晰的感受技术选型最终赢在“边界感”上。EdgeX负责设备接入和数据治理K8s负责应用编排和平台稳定AI推理独立成服务专注模型计算每一层都只做自己的事不越界出了问题也知道该找谁。如果当初硬要EdgeX去完成AI推理或者用K8s去直接处理设备协议无论是实现复杂度还是后期维护成本都会高出很多。最后再分享一个小技巧刚开始做边缘AI平台的时候不要一上来就追求大而全。先拿一个设备、一个模型、一个节点把链路打通再逐步叠加高可用、安全、多节点这些能力。我在项目初期也犯过贪多嚼不烂的毛病后来老老实实把一条链路跑得滚瓜烂熟后面所有扩展都是水到渠成的事。这套架构最大的优势就在于它给你留足了向上生长和向后兼容的空间你能走得多远取决于你把它当作一个项目还是一套可以持续演进的平台。
