容器间不能共享同一veth-pair，因其为点对点虚拟链路，一端属某容器命名空间，另一端在宿主机，强行共享会触发内核拒绝、地址冲突与路由混乱；推荐方案是共用自定义网桥或复用网络命名空间。
容器间不能直接共享同一个 veth-pair 设备，因为每个 veth-pair 是成对出现的网络接口，一端绑定到一个网络命名空间（如某个容器），另一端通常在宿主机上作为桥接端口；Docker 的默认设计也不允许两个容器挂载同一对 veth 接口——这会引发命名空间冲突、MAC/IP 地址冲突和路由混乱。
为什么不能“共享”veth-pair？
veth-pair 本质是一条点对点虚拟链路：一端（如 vethabc123）属于容器 A 的网络命名空间，另一端（如 vethxyz789）位于宿主机的 init 命名空间（常接入 docker0 或自定义网桥）。若强行将同一对 veth 接口同时加入两个容器命名空间，Linux 内核会拒绝（Operation not permitted），且违背网络隔离原则。
替代方案：实现容器间低开销、高带宽通信
真正需要的是容器间高效互通，而非“共享设备”。以下是推荐做法：
- 共用同一用户定义网桥（推荐）：创建自定义 bridge 网络，让多个容器接入同一子网。Docker 自动为每个容器分配独立 veth-pair 并连接到该网桥，容器间通过二层交换直通，延迟低、无需 NAT。
-
使用 network=container 模式复用网络栈：启动容器 B 时指定
--network=container:A，使其与容器 A 共享全部网络命名空间（含所有接口、IP、端口、路由表）。此时两者如同运行在同一网络上下文中，相当于“逻辑上共享 veth”。 -
手动构建多容器共享命名空间（高级）：先运行一个基础容器（如
alpine sleep inf），再用--net=container:xxx、--ipc=container:xxx等参数让其他容器复用其命名空间。注意：所有容器需协调好服务端口和进程管理，适合紧密耦合组件（如 sidecar 模式）。
不建议的手动操作（仅供理解原理）
有人尝试用 ip link 和 nsenter 把宿主机上的 veth 端移入另一个容器命名空间，这会导致原容器网络中断、ARP 表错乱、iptables 规则失效，且重启后状态不可恢复。Docker 的守护进程无法感知此类变更，后续 docker network disconnect 等操作会失败。
本质上，Docker 的网络模型基于“每个容器独占一套网络设备 + 统一网桥转发”，追求的是可预测性与隔离性。想获得类似“共享 veth”的效果，应转向语义等价的协作模式，而非绕过内核约束硬改设备归属。
