边缘 AI、K3s 与云边协同¶

边缘 AI 把推理放到摄像头、工厂、门店、车辆或现场服务器附近，以降低延迟、带宽和数据外传。但边缘节点通常网络不稳定、资源有限、物理环境不可控，不能直接复制数据中心的 Kubernetes 方案。

1. 什么时候值得放到边缘¶

适合边缘：

必须毫秒级响应；
上行带宽有限或昂贵；
原始数据不能离开现场；
断网时仍要工作；
设备控制闭环依赖本地推理；
云端只需要聚合结果而非原始流。

不适合边缘：

模型大到无法在现场硬件运行；
工作负载主要是离线批处理；
现场没有升级、监控和密钥轮换能力；
数据必须集中关联才能产生价值；
对一致性和集中控制要求远高于本地自治。

2. 三种部署模型¶

单站点 K3s¶

每个站点运行独立 K3s，云端用 GitOps 管理。适合站点内有多台服务器、需要标准 Kubernetes API，但站点之间不要求同一控制平面。

K3s 集成 containerd、轻量默认存储和网络组件，安装面较小，适合边缘和资源受限场景。参考：K3s Documentation

中心 Kubernetes + KubeEdge¶

CloudCore 在中心管理，EdgeCore 运行于边缘节点。它适合需要设备模型、Device Twin、弱网连接和云边状态同步的场景。

轻量进程/容器管理¶

只有单应用、极少设备且不需要 Kubernetes API 时，systemd、容器 Compose 或专用 OTA 系统可能更简单。边缘并不天然要求 Kubernetes。

3. 参考架构¶

中心云
├── Git / Registry / Model Registry
├── 训练与评估平台
├── Fleet / GitOps 控制面
└── 聚合监控与数据湖
          │ 间歇连接
          ▼
边缘站点
├── K3s 或 EdgeCore
├── 本地 Registry / 模型缓存
├── 推理服务
├── 消息总线与设备 Mapper
├── 本地时序库/缓冲区
└── 摄像头、PLC、传感器

控制面配置、模型制品和业务数据应使用不同通道和重试策略。

4. K3s 与 KubeEdge 怎么选¶

问题	更偏 K3s	更偏 KubeEdge
每站点是否需要独立控制面	是	否
站点能否长期自治	强	依赖 EdgeCore 本地能力
是否管理大量设备模型/状态	一般	强
是否需要中心统一 Kubernetes API	多集群聚合	云边单控制面模型
网络是否长期不稳定	可完全独立	专门设计云边通道
运维方式	每站点升级/备份	CloudCore + EdgeCore 生命周期

两者也可以组合，但复杂度明显上升，应先验证运维责任是否清晰。

5. 设备管理与推理不是一层¶

KubeEdge 使用 Device CRD、Device Twin 和 Mapper 管理设备元数据与状态。DMI 进一步分离设备管理面和数据面，使设备数据可以直接提供给边缘应用，不必全部回传云端。参考：KubeEdge DMI

推理服务负责模型计算；Mapper 负责协议和设备读写；业务应用负责把推理结果转换成控制动作。不要让模型容器直接实现所有工业协议和设备生命周期。

6. 弱网和离线设计¶

每个边缘应用都要明确：

断网后能持续运行多久；
配置和模型的最后已知良好版本；
本地缓存容量满时如何丢弃或聚合；
时钟漂移如何影响事件顺序；
恢复连接后如何去重和补传；
中心与本地配置冲突如何解决；
证书过期前能否在弱网环境轮换。

不要把云端 API 的同步成功作为本地推理请求的前置条件。

7. 模型发布策略¶

边缘模型发布建议分阶段：

中心完成离线质量、性能和安全评估；
生成签名模型包、摘要和兼容性元数据；
先发布到实验站点；
扩大到按硬件/区域分组的 Canary；
本地健康检查通过后切换；
保留至少一个可离线回滚版本；
汇总线上指标决定继续或停止。

版本元数据至少包含模型、运行时、驱动、预处理和标签字典版本。

8. 硬件与运行时¶

边缘设备可能是 x86 GPU 服务器、NVIDIA Jetson、独立 NPU、VPU 或纯 CPU。平台需要记录：

架构：amd64 / arm64；
加速器和驱动版本；
可用显存/共享内存；
功耗与散热模式；
推理运行时和支持算子；
摄像头/设备接口；
本地磁盘寿命和容量。

镜像必须支持目标架构。模型转换应在 CI 中按硬件矩阵完成，不要让每台边缘设备现场编译。

9. 边缘网络边界¶

KubeEdge 的 CloudHub/EdgeHub 通道承载控制面消息，并不替代 Pod 数据面的 CNI。Pod IP、同站点连通和 NetworkPolicy 仍由 CNI 负责；跨 LAN 服务发现可评估 EdgeMesh。参考：KubeEdge CNI and Edge Networking Boundary

排障时分清：

EdgeCore 是否连到 CloudCore；
CNI 是否成功创建 Pod 网络；
设备协议是否由 Mapper 正常读取；
推理 API 是否可用；
跨站点业务流量是否经过额外隧道。

10. 数据闭环¶

边缘不应把所有原始数据上传云端。常见分层：

本地实时推理；
本地短期环形缓存；
只上传事件、Embedding 或聚合指标；
按规则抽取困难样本；
云端标注和再训练；
新模型通过受控发布回到边缘。

困难样本采集必须满足隐私、带宽和保留策略。

11. 可观测性¶

边缘节点本地保留短期指标和日志，连接恢复后再聚合。需要监控：

推理延迟、吞吐和质量代理指标；
设备在线率和数据新鲜度；
CPU/GPU/NPU、温度、功耗和降频；
磁盘水位和写入寿命；
云边连接时延、断开时间和积压；
模型版本与发布状态；
证书和密钥到期时间。

中心看不到节点不代表节点停止工作，应单独表示“离线自治”和“未知状态”。

12. 物理与安全边界¶

边缘设备可能被接触、断电或带离现场：

全盘或数据分区加密；
Secure Boot/TPM 与设备身份；
签名镜像、模型和 OTA 包；
最小开放端口，不暴露 kube-apiserver；
本地调试接口可审计并自动过期；
Secret 不以明文长期保存在镜像；
设备丢失后能吊销身份；
恢复出厂和安全擦除流程明确。