17、docker-macvlan-1-理论

MAC VLAN

本章重点： macvlan四种工作模式（Bridge\Private\VEPA\Passthru）理论与其它模型对比理论

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 地址与物理网络隔离，主机无法直接访问容器（需同网段路由）
适用场景	常规开发测试、多容器隔离部署	高性能需求（如高并发服务）、无端口冲突场景	模拟物理设备（如网络设备测试）、传统应用迁移（需独立网络身份）