MAC VLAN
本章重点： macvlan四种工作模式（Bridge\Private\VEPA\Passthru）理论与其它模型对比理论
来源： 豆包ai，Docker 三种网络驱动
MAC VLAN 是基于 Linux kernel 模块的网卡虚拟化技术，核心是在同一个物理以太网接口上虚拟出多个独立网络接口，实现容器与物理网络的直接对接，属于 Underlay 网络方案。
macvlan介绍
-
技术特性
- 虚拟接口具备独立标识：每个虚拟接口拥有唯一 MAC 地址，可按需配置专属 IP 地址，网络领域常称其为 "子接口"，在 MAC VLAN 场景中更常用 "上层 / 下层接口" 表述。
- 网络连接方式：无需依赖虚拟网桥、NAT 转换及端口映射，允许容器以虚拟接口形式直接连接物理接口，数据传输路径更简洁。
- 通信机制：二层网络通过 VLAN 实现同网段容器互联，三层网络需依赖外部网关打通不同 MAC VLAN 网段；数据包直接发送，无需额外封装操作。
-
核心优势
-
性能表现优异：省去网桥转发、报文封装等中间环节，直接接入物理网络，相比 Overlay 网络及 Bridge 模式，减少了 CPU 和网络开销，是性能优先场景的优选方案。
-
Overlay 与 Bridge 比较 逻辑图如下
-
macvlan工作模式
-
MAC VLAN 工作模式特性对比表
模式 工作原理 核心特点 适用场景 配置复杂度 通信能力（同网段容器） Bridge 模式 容器通过父物理网卡接入物理网络，基于 MAC 地址转发（类似物理交换机） 容器有独立 MAC/IP，外部可直接访问，跨网段依赖物理路由 常规场景、传统应用迁移、网络设备模拟、需独立网络身份的容器部署 低（默认模式） 可直接通信 Private 模式 同父网卡下的容器彼此隔离，流量仅能转发到外部网络，无法内部互访 隔离性极强，避免同父网卡容器间非法通信 多租户环境、不同业务模块隔离、需严格限制内部互访的场景 低 无法直接通信 VEPA 模式 容器流量先转发到物理交换机（需交换机支持 VEPA 功能），再由交换机转发目标 借助物理交换机实现流量监控、ACL 控制，需网络设备配合 企业级网络管控、需审计容器流量、依赖交换机策略的场景 中（需交换机配置） 可通信（需交换机转发） Passthru 模式 物理网卡直接绑定单个容器，容器独占父网卡，其他容器无法复用该网卡 性能最优（无转发开销），独占硬件资源 极致性能需求、容器需独占网卡、高性能数据传输、专业网络设备测试 中（需网卡独占） 无（仅单个容器使用） -
补充说明
- Bridge 模式是 MAC VLAN 的默认且首选模式，配置简单、兼容性强，覆盖 80% 以上的 MAC VLAN 使用场景。
- Passthru 模式下，父网卡会被容器独占，主机将无法使用该网卡，需提前规划网卡资源。
- VEPA 模式依赖物理交换机支持（如 Cisco、H3C 等企业级交换机），普通家用交换机可能不兼容。
-
MAC VLAN 的 Bridge 模式和 Passthru 模式 的对比表格
对比维度 Bridge 模式 Passthru 模式 连接与实例数量 同一物理接口可创建多个 MAC VLAN 虚拟子接口，基于虚拟网桥实现内部交互 仅允许单个虚拟子接口直接连接物理主接口，同一物理接口同一时间仅支持 1 个实例 通信机制 子接口间通过虚拟网桥直接转发 数据，无需依赖外部设备；默认无法与宿主物理网卡通信 数据通过物理接口直接收发（因独占接口）；虚拟网卡继承主接口 MAC 地址，需主接口工作在混杂模式 适用场景 Docker 容器唯一支持的 MAC VLAN 模式，适合多容器本地二层互通（如开发环境协同） 适配对物理接口独占性要求高的场景（如特殊 VLAN 、定制化网络调试），通用性弱 物理资源要求 无需物理接口特殊配置（加载 macvlan模块即可），可虚拟多子接口，无 MAC 地址独占限制要求物理主接口强制开启混杂模式（公有云等环境常禁用）；受限于单实例，物理网卡 MAC 地址上限影响大 与宿主交互性 子接口默认无法与宿主物理网卡通信（容器 ↔ 宿主需额外方案打通，如路由、端口映射） 因虚拟网卡直连物理接口，理论可与宿主通信（仅单个容器使用） 典型限制 虚拟网桥转发会带来少量 CPU 开销；Docker 场景外需手动配置虚拟网桥 依赖混杂模式，环境兼容性差；单实例限制导致多容器场景无法复用，仅适合特殊调试 / 定制化需求 -
Docker 默认 Bridge ，host 与 MAC VLAN Bridge 模式的核心区别对比表
对比维度 默认 Bridge 模式 默认 Host 模式 MAC VLAN Bridge 模式 网络隔离 中（独立网络命名空间，共享 docker0 网桥） 无（共享主机网络命名空间，端口 / 协议完全暴露） 高（独立 MAC/IP，与主机网络逻辑隔离，物理网络可见） 网络层级 网络层（L3，依赖 IP 路由和 NAT） 无额外层级（直接复用主机 L2-L7 协议栈） 数据链路层（L2，基于 MAC 地址转发，模拟物理网卡） IP 分配 Docker 自动分配私有 IP（如 172.17.x.x） 无独立 IP，共享主机 IP 与主机同网段独立 IP（需手动配置或 DHCP 分配） 端口映射 需手动配置 -p映射主机端口无需映射，直接使用主机端口（可能冲突） 无需映射，端口直接暴露在物理网络 通信路径 容器 → docker0 网桥 → 主机网卡（NAT 转换） 容器直接使用主机网卡和协议栈 容器 → 物理网卡（直接封装 MAC/IP 帧，无 NAT） 网络配置依赖 依赖 Docker 内置 docker0 网桥 完全依赖主机网络配置（如路由、防火墙） 依赖物理网卡（需指定父接口，如 eth0）和物理网络配置 外部网络访问 需端口映射或反向代理 直接通过主机 IP + 端口访问 外部可直接通过容器独立 IP 访问 容器间通信 通过 docker0 网桥转发，支持容器名解析 通过主机本地网络（如 lo 接口或主机 IP） 同网段直接通信（物理网络层转发），跨网段需物理路由支持 性能开销 中（网桥转发 + NAT 转换开销） 极低（无网络转发，直接复用主机协议栈） 低（接近物理网络，仅链路层封装开销） Docker 支持度 原生默认支持，无需额外配置 原生支持，仅需 --net=host启用原生支持，但需手动创建 macvlan 网络（ docker network create）隔离性细节 网络命名空间隔离，端口 / IP 独立，但依赖 Docker 网桥隔离 无网络命名空间隔离，与主机共享所有网络资源 网络命名空间隔离，且通过 MAC 地址与物理网络隔离，主机无法直接访问容器（需同网段路由） 适用场景 常规开发测试、多容器隔离部署 高性能需求（如高并发服务）、无端口冲突场景 模拟物理设备（如网络设备测试）、传统应用迁移（需独立网络身份）