容器化设备接入与管理是很多团队在把传统应用迁移到容器平台时绕不开的话题。应用跑在容器里，可串口设备、GPU显卡、摄像头、加密狗这些硬件却实实在在插在宿主机上，容器内的进程默认看不到它们，更别提直接读写。要打通这层隔阂，靠的是Linux设备文件机制加上容器运行时提供的各种透传手段。本文从底层原理讲到实操配置，把Docker和Kubernetes两类环境下的设备接入方案、权限控制和常见坑点逐一梳理清楚。
一、先弄懂设备文件：容器为什么默认看不到硬件
Linux下一切皆文件，硬件设备也不例外。内核通过设备文件（通常位于/dev目录）向用户态暴露访问入口，比如/dev/ttyUSB0对应一个USB转串口设备，/dev/video0对应摄像头，/dev/nvidia0对应NVIDIA显卡。设备文件分字符设备和块设备两类，前者按字节流读写（串口、终端），后者按块随机读写（磁盘）。
容器之所以看不到这些设备，是因为容器有自己的独立挂载命名空间和设备cgroup限制。容器启动时，运行时会为它创建一个精简的/dev目录，里面只有/dev/null、/dev/zero、/dev/random等基础设备节点，宿主机上的其他设备文件不会自动出现。即使你通过卷挂载把宿主机的/dev目录整个挂进去，设备cgroup也会拦截容器内进程对未授权设备的mknod和open操作，导致权限被拒绝。
所以设备接入本质上要解决两件事：一是让设备文件在容器的挂载命名空间里可见，二是让设备cgroup允许容器访问对应的主次设备号。理解了这一点，后面各种配置手段的原理就都通了。
二、Docker环境下的设备透传方式
1. device参数：最标准的接入方式
docker run的--device参数是最推荐的设备接入方式，它会同时完成设备文件创建和cgroup授权两个动作。用法很直接：
# 将宿主机的串口设备透传给容器，容器内路径与宿主机一致 docker run -it --device=/dev/ttyUSB0:/dev/ttyUSB0 ubuntu /bin/bash # 透传多个设备，可以多次指定 --device docker run -it \ --device=/dev/ttyUSB0 \ --device=/dev/ttyUSB1 \ debian /bin/bash # 透传NVIDIA显卡设备 docker run --gpus all nvidia/cuda:12.2.0-base-ubuntu22.04 nvidia-smi
注意--device后面的路径必须是设备文件，不能是普通文件或目录，否则Docker会报错。如果目标设备是动态生成的（比如USB设备插拔后编号变化），可以配合udev规则固定设备名的软链接，再透传链接指向的真实设备。
2. privileged模式：省事但危险
--privileged会让容器获得宿主机几乎所有的内核能力，并把宿主机的/dev整个暴露进容器：
docker run -it --privileged ubuntu /bin/bash # 容器内可以直接看到宿主机全部设备 ls /dev | wc -l
这种方式配置最简单，很多老旧文档都这么写，但代价是安全边界基本消失：容器内root可以加载内核模块、修改宿主机文件、访问任意硬件。生产环境强烈不建议使用。如果只是需要部分特权，可以用--cap-add精确添加能力，比如访问串口通常只需要SYS_PTRACE之外的普通权限加上设备cgroup放行即可。
3. 卷挂载配合mknod：应急手段
还有一种做法是把宿主机的/dev挂载进容器，或者通过--volume /dev/ttyUSB0:/dev/ttyUSB0挂载设备文件。这种方式只解决了可见性问题，cgroup授权需要运行时支持或者手动调整。某些定制内核或特殊运行时组合下，这个方法反而比--device更灵活，值得了解但不要作为首选。
三、Kubernetes环境：设备插件机制详解
Kubernetes对设备的管理比单机Docker复杂得多，核心机制是Device Plugin框架。kubelet启动时会创建一个/var/lib/kubelet/device-plugins目录，设备插件守护进程以gRPC服务的形式向kubelet注册自己管理的设备资源，kubelet负责把设备分配信息写入容器的设备列表。
以GPU为例，NVIDIA的k8s-device-plugin会扫描节点上的显卡，把每块GPU注册为nvidia.com/gpu资源，Pod声明资源需求即可自动绑定设备：
apiVersion: v1
kind: Pod
metadata:
name: gpu-pod
spec:
containers:
- name: cuda-container
image: nvidia/cuda:12.2.0-base-ubuntu22.04
command: ["nvidia-smi"]
resources:
limits:
nvidia.com/gpu: 1 # 请求一块GPU，由设备插件调度分配
对于自定义硬件，比如工控机上的CAN卡、FPGA加速卡，可以自己实现设备插件，只需要实现ListAndWatch和Allocate两个gRPC接口，把设备健康状态上报给kubelet即可。社区里也有generic-device-plugin这类通用方案，通过配置文件把宿主机路径映射为自定义扩展资源，不用写代码就能接入简单设备。
四、权限控制与常见坑
设备透传之后经常遇到权限拒绝问题，根源通常是设备文件的属主和权限。比如串口设备默认属于dialout组，容器内进程如果不是以该组身份运行就会报Permission denied。解决办法有三种：在容器内以root运行并显式切换组、构建镜像时添加对应组ID，或者用--group-add参数在运行时附加组：
# 查看宿主机设备的属组GID stat -c %g /dev/ttyUSB0 # 运行容器时附加该组 docker run -it --device=/dev/ttyUSB0 --group-add=20 ubuntu /bin/bash
USB设备热插拔也是高频坑点。设备拔掉再插上，内核会重新分配设备号，容器里透传的旧设备文件就失效了。稳妥做法是用udev规则根据设备的序列号或厂商ID创建稳定的符号链接，容器内程序监听链接而不是原始设备路径。另外，容器内访问GPU还需要配套的驱动库，NVIDIA Container Toolkit就是在宿主机注入驱动和用户态库的桥接层，没装它光透传设备节点是跑不起来CUDA的。
最后是安全加固建议：优先用--device而非privileged，配合--cap-drop=ALL再加最小能力集；对可写设备设置只读挂载，减少误操作；在Kubernetes中通过ResourceQuota限制设备资源总量，防止单个团队占满全部硬件。设备接入做好最小权限原则，容器化硬件管理才能真正落地稳定。
容器化Docker设备接入设备管理修改时间：2026-09-03 03:51:01