在部署大规模WiFi覆盖网络时，不少工程师遇到过这样的问题：一台边缘网关设备既要跑认证服务，又要处理探针数据、做流量分析，还得支持本地策略路由——多个功能模块挤在一起，一个模块出错就拖垮整台设备。这时候，容器技术的隔离机制就成了很自然的选择。
不是虚拟机，但比进程更干净
很多人第一反应是上虚拟机，但WiFi覆盖场景下的AP控制器或边缘网关往往资源有限（比如ARM架构的4GB内存设备），开几个VM太重。而容器通过Linux内核的cgroups和namespaces实现轻量级隔离：每个服务运行在独立的PID、网络、挂载命名空间里，彼此看不到对方的进程、端口、文件系统。比如，把微信连WiFi的认证服务放进一个容器，把蓝牙信标扫描模块放进另一个，它们共用同一个Linux内核，但不会互相kill -9，也不会抢80端口。
真实配置片段长这样
某园区WiFi项目中，工程师用Docker Compose编排了三个容器：
version: '3.8'
services:
portal:
image: nginx:alpine
network_mode: "bridge"
ports: ["8080:80"]
radius:
image: freeradius/freeradius-server:latest
network_mode: "bridge"
cap_add: ["NET_ADMIN"]
sniffer:
image: wireshark-dev:arm64
network_mode: "host"
devices: ["/dev/ttyUSB0:/dev/ttyUSB0"]注意radius容器加了NET_ADMIN能力——这是因为它要动态配置iptables规则来转发EAP报文；而sniffer容器直接用了host网络模式，方便抓取物理网卡上的802.11帧；portal则走桥接，对外只暴露8080。三种网络隔离策略混用，全靠容器运行时灵活控制。
隔离不是万能，但能减少“重启大法”
有次某商场WiFi突然断连，排查发现是认证页面的JS脚本触发了nginx容器内存泄漏，RSS涨到1.2GB。运维直接docker restart portal，3秒恢复，其他两个服务毫发无损。要是所有功能都跑在systemd下，可能就得整个服务reload，连带中断正在握手的终端。
当然，容器隔离不能替代代码健壮性。比如sniffer容器如果误读了USB设备的固件版本，照样会让/dev/ttyUSB0变不可用——这时候得靠设备节点的cgroup限制I/O权重，而不是光靠namespace。
现在不少新出的AC设备管理平台，底层已经默认用containerd拉起各模块。你看到的“一键升级策略引擎”，背后可能只是替换了某个容器镜像并重启对应service，连内核都不用动。