macvlan是让kubernetes容器直接接入物理网络的核心方案，通过为pod分配独立mac和同网段ip（如192.168.1.120），实现数据帧绕过宿主机协议栈、直通物理网卡，使局域网设备可直接访问。
要让 Kubernetes 容器直接接入线下物理网络（即获得与宿主机同网段的 IP、能被局域网内其他设备如 PC、IoT 设备、PLC 等直接访问），不能依赖默认的 CNI 插件（如 kube-proxy + iptables 或 CoreDNS 仅解决集群内 DNS），关键在于替换或增强底层网络插件，使其支持二层直通——核心方案是 macvlan 或 ipvlan CNI 插件。
用 macvlan CNI 实现物理网直连
macvlan 是最成熟、最贴近“容器变物理机”效果的方式。它为每个 Pod 分配独立 MAC 和局域网 IP（例如 192.168.1.120），数据帧绕过宿主机协议栈，直接从物理网卡进出，交换机可识别、局域网设备可直连。
- 需确保宿主机物理网卡（如 eth0）支持 macvlan（有线网卡基本都支持；Wi-Fi 网卡通常不支持，应避免）
- 安装 macvlan CNI 插件：将
macvlan二进制放入/opt/cni/bin/，并配置 CNI 配置文件（如/etc/cni/net.d/10-macvlan.conf） - 配置示例（指定网关、子网、父接口）：
{
"cniVersion": "0.4.0",
"name": "my-macvlan",
"type": "macvlan",
"master": "eth0",
"ipam": {
"type": "static",
"addresses": [{
"address": "192.168.1.120/24",
"gateway": "192.168.1.1"
}]
}
} - 通过
NetworkAttachmentDefinition（配合 Multus CNI）为指定 Pod 启用该网络，而非全局替换默认 CNI
用 ipvlan 替代 macvlan（适合受限环境）
当宿主机虚拟网卡（如云服务器弹性网卡）不支持 macvlan 时，ipvlan 是更轻量的替代方案。它复用宿主机 MAC 地址，只隔离 IP 层，同样可分配同网段 IP，且对交换机无特殊要求。
- ipvlan 支持 L2（广播可见）和 L3（路由模式）两种工作方式；L2 模式下局域网设备可直接 ping 通 Pod IP
- CNI 配置中将
"type": "macvlan"改为"type": "ipvlan"，并添加"mode": "l2" - 资源占用更低，适合高密度边缘节点或嵌入式 K8s（如 k3s）场景
关键注意事项与避坑点
这类直通方案不是开箱即用，需关注几个硬性前提：
- 物理交换机需开启混杂模式或关闭端口安全（部分企业交换机会丢弃未知源 MAC 的帧）
- 宿主机自身与 Pod 默认二层隔离；若需宿主机访问 Pod IP，需手动加路由（如
ip route add 192.168.1.120/32 via 192.168.1.100 dev eth0）或使用--parent=eth0@eth0变体 - 避免 IP 冲突：建议用静态 IPAM 或对接 DHCP 服务器；不要与现有物理设备 IP 段重叠
- 不推荐在笔记本 Wi-Fi 接口上部署；生产环境务必使用有线网卡并确认驱动兼容性
为什么不用 Flannel/Calico 默认模式？
Flannel（VXLAN 模式）、Calico（IPIP/BGP）等主流 CNI 均构建覆盖网络（Overlay），Pod IP 对物理网络不可见，流量必须经宿主机封装/解封装。这带来额外延迟与 CPU 开销，且局域网设备无法直接访问 Pod —— 这与“线下物理网络互通”的本质需求相悖。只有 macvlan/ipvlan 类型的 CNI 才真正实现“零 NAT、零隧道、帧级直通”。
