容器在边缘解决什么
边缘网关上的业务逻辑会随现场需求变化，如果全部打包进固件，每次改动都要整机升级。容器把采集、预处理与转发拆成独立单元，可以单独升级与回滚，也让不同来源的应用在资源与权限上相互隔离，代价是多了一层运行时开销。
环节与风险
| 环节 | 关注点 | 风险 |
|---|---|---|
| 运行时 | 容器引擎自身占用的内存与存储 | 受限设备上运行时开销可能超过业务负载 |
| 镜像分发 | 弱网或离线环境需要本地仓库或预置镜像 | 升级中网络中断会让设备处于版本不一致状态 |
| 资源限制 | CPU、内存与存储配额 | 不做限制的应用可能耗尽网关资源 |
| 存储磨损 | 频繁写入镜像层与日志 | 嵌入式存储写放大严重，寿命明显缩短 |
| 回滚机制 | 保留上一版本镜像与配置 | 没有回滚通道时一次失败升级就是现场停机 |
典型使用场景
- 多算法并行：不同供应商的算法以独立容器运行并各自升级
- 灰度发布：先在小部分网关验证新版本再全量
- 环境一致性：把开发环境验证过的镜像原样部署到现场
- 资源隔离：把关键采集与控制逻辑同试验性应用隔开
边缘容器化的收益与网关规模相关：只有几台设备时，容器带来的运维复杂度可能超过它节省的升级成本。
不做资源配额与日志轮转时，单个容器失控或日志写满会同时影响同机上的其他业务，故障范围从单个应用扩散到整台网关。
镜像与配置分离
把配置与镜像分开管理：同一个镜像在不同站点配不同配置，升级时只替换镜像，可以显著减少需要构建与验证的版本数量，也降低现场差异带来的排查成本。