1. 课程导入

在智能制造、能源电力、轨道交通、智慧水务等场景中，数据产生的速度越来越快，控制决策对时延的要求越来越苛刻。如果所有数据都上传到云端处理，再等待云端返回指令，网络抖动、带宽成本和数据安全都会成为瓶颈。边缘计算正是为了解决这一问题而出现：把计算、存储、网络与智能分析能力下沉到靠近设备、靠近现场的一侧，让数据在产生地附近完成处理与响应。而边缘控制器，就是承载这些边缘计算任务的工业级硬件与软件平台。

本课程的主题是边缘控制器容器化部署。它要回答的核心问题是：如何把原本直接安装在边缘控制器操作系统上的应用，改造成以容器方式运行、可编排、可升级、可隔离、可观测的部署形态。学完本课程，你应当能够理解容器化在边缘侧的价值，掌握镜像构建、容器运行、资源限制、网络与存储挂载、设备访问、批量下发与远程运维等关键能力，并能结合工业现场约束做出合理的部署设计。

一、核心概念：从边缘计算到容器化部署

边缘计算是一种分布式计算范式，强调在数据源与云端之间引入靠近现场的算力节点，完成实时控制、协议转换、数据清洗、本地推理和断网自治。它并不是云计算的替代品，而是与云形成分工：边缘负责低时延、高可靠、本地闭环；云负责全局建模、跨厂区协同、长期数据沉淀与模型训练。

边缘控制器是运行在工业现场的控制器设备，通常具备多核处理器、工业总线接口、多网口、宽温设计与看门狗机制。它既可能承担传统 PLC 的逻辑控制职责，也可能运行数据采集、边缘网关、视觉推理、协议转换等上层应用。与传统 PLC 相比，边缘控制器更强调开放的操作系统、丰富的网络能力和可扩展的软件生态。

容器化部署则是把应用及其依赖打包成标准镜像，在隔离的容器中运行。容器共享宿主机内核，启动快、体积小、资源开销低，非常适合边缘侧资源受限但应用多样的环境。与虚拟机相比，容器不需要为每个应用运行完整操作系统，因此在边缘控制器上更具优势。

二、方法流程：容器化部署的典型链路

边缘控制器的容器化部署并不是简单地把应用塞进容器，而是一条从开发到运维的完整链路。典型流程如下：

1. 应用容器化：编写 Dockerfile，把应用、依赖库、运行时环境打包成镜像，明确入口命令与暴露端口。
2. 镜像构建与推送：在构建机上执行构建，打上版本标签，推送到镜像仓库，供边缘侧拉取。
3. 边缘侧拉取与运行：边缘控制器从仓库拉取镜像，按部署描述启动容器，挂载设备、数据卷与配置。
4. 资源与设备约束：通过 CPU、内存限制和 device 映射，保证实时任务不被其他容器挤占。
5. 编排与批量下发：借助 K3s、KubeEdge 或自研 Agent，把同一应用批量部署到多台边缘控制器。
6. 可观测与升级：采集日志、指标与健康状态，支持滚动升级、回滚与远程排障。

下面是一个最小化的容器运行示例，用于说明边缘侧启动一个数据采集容器的基本方式：

docker run -d \
  --name edge-collector \
  --restart unless-stopped \
  --cpus="0.5" --memory="256m" \
  --device=/dev/ttyS0:/dev/ttyS0 \
  -v /data/collector:/var/lib/collector \
  -e MODBUS_SLAVE=1 \
  -p 5020:5020 \
  registry.local/edge/collector:1.2.0

这段命令体现了边缘容器化的几个关键点：资源限制、设备直通、数据持久化、环境变量配置和端口映射。理解这些参数，是后续章节深入实践的基础。

三、案例场景：边缘控制器在工业中的定位

以一条汽车零部件装配线为例。产线上有 PLC 控制的气动执行机构、视觉检测相机、扭矩枪和扫码器。传统方案中，视觉检测需要单独工控机，数据采集需要网关，协议转换需要另一台设备，现场机柜里堆叠了多台机器，布线复杂、维护困难。

引入边缘控制器后，一台设备即可承载多个容器：协议转换容器负责把 Modbus 数据转为 OPC UA；视觉推理容器调用本地 GPU 或 NPU 完成缺陷检测；数据采集容器把关键工艺参数写入本地时序库；控制逻辑容器在断网时仍能维持本地闭环。云端只接收汇总结果和异常事件，带宽压力大幅下降。

四、误区与复盘：学习前必须澄清的认知