Kata Containers 网络架构深度解析：veth 与 TAP 的桥接模型、TC-Filter 原理与网络热插拔机制

云原生容器运行时【免费下载链接】kata-containersKata Containers is an open source project and community working to build a standard implementation of lightweight Virtual Machines (VMs) that feel and perform like containers, but provide the workload isolation and security advantages of VMs. https://katacontainers.io/项目地址https://gitcode.com/gh_mirrors/ka/kata-containers点击查看免费下载导读本文以 Kata Containers 架构文档 docs/design/architecture/networking.md 为骨架系统讲解 Kata 如何把容器引擎期望的veth网络模型与虚拟机所需的TAP设备模型衔接起来覆盖 TC-Filter、MACVTAP、实验性 L3 转发三种互联模型以及 add/remove/list 接口与路由表操作构成的热插拔 API 体系。读完本文你将理解 Kata 默认网络路径veth → tc filter → tap0_kata → 虚拟机 virtio-net的完整数据流掌握internetworking_model、disable_new_netns等核心配置项并能够对照源码定位每条链路的具体实现。背景容器网络命名空间与 VM 的不兼容问题标准容器如runc容器通常存活在自己的、且可能被多个容器共享的网络命名空间中。容器生命周期中的某个阶段容器引擎会配置该命名空间把容器接入一个与主机网络隔离的网络。容器引擎配置网络时会调用网络插件CNI/CNM。网络插件通常创建一对虚拟以太网设备vethpair一端放入容器的网络命名空间另一端放入主机的网络命名空间通常是网桥如docker0或 CNI 网桥。这种模式是强命名空间导向的。但很多 hypervisor 或 VMM例如virt-manager无法直接处理veth接口——VM 的网络连接通常使用 TAP 设备。于是在容器引擎期望的 veth 模型与虚拟机需要的 TAP 模型之间就需要一种互联网联internetworking模型来弥合差异。Kata Containers 为此实现了三种模型TC-Filter默认、MACVTAP早期实现、L3 Forwarding实验性。TC-Filter默认的 veth 与 TAP 桥接模型Kata Containers 使用 Linux 内核的 Traffic Controltc 机制将veth接口与TAP接口透明地连接起来。下图展示了这一数据通路图中可见容器网络命名空间中的eth0与 VM 的虚拟网卡所对应的tap0_kata之间由两条 TC 重定向规则tc rules串接一条把eth0的 ingress 流量导向tap0_kata的 egress另一条把tap0_kata的 ingress 流量导向eth0的 egress。工作流程以 CNI 插件放置的 eth0 为例网络插件在容器的网络命名空间中放置一个设备eth0即veth对的一端Kata 为 VM 创建一个 TAP 设备tap0_kataKata 设置第一条 TC 重定向过滤器把来自eth0ingress的流量重定向到tap0_kata的egressKata 设置第二条 TC 重定向过滤器把来自tap0_kataingress的流量重定向到eth0的egress。通过这两条规则容器侧与 VM 侧在数据链路层被无缝打通容器发出的包经eth0→ TC 过滤器 →tap0_kata进入 VMVM 回应的包反向经tap0_kata→ TC 过滤器 →eth0回到容器网络。源码实现setupTCFiltering 的完整数据通路在 src/runtime/virtcontainers/network_linux.go 中setupTCFiltering()完整实现了上述流程创建 TAP 设备调用createLink()以netlink.Tuntap类型创建名为tap0_kata的 TAP 接口并取得文件描述符netPair.VMFds供 hypervisor 后端使用创建 vhost-net fd若未禁用 vhost-netdisableVhostNet false调用createVhostFds()同文件 L913-L915打开/dev/vhost-net获得 vhost fd用于把数据面卸载到内核加速继承 veth 的 MAC 地址将 veth 端口的 MAC 地址复制给 TAPnetPair.TAPIface.HardAddr attrs.HardwareAddr.String()注释明确指出该 MAC 地址必须是 VM 内的那个地址以避免防火墙问题主机侧网络插件创建的网桥期望看到来自该 MAC 的流量同步 MTU 并启用 TAPLinkSetMTU使 TAP 与 veth MTU 一致LinkSetUp将 TAP 置为 up添加 ingress qdisc对 TAP 与 veth 两端分别执行addQdiscIngress()等价于tc qdisc add dev eth0 ingress见 L1162-L1163 的注释qdisc 通常不作用于 ingress这是把 ingress 当作入站分组备用根的特殊 qdisc添加双向重定向过滤器addRedirectTCFilter(attrs.Index, tapAttrs.Index)与addRedirectTCFilter(tapAttrs.Index, attrs.Index)分别建立两个方向的转发。该函数L1186-L1215等价于执行tc filter add dev source parent ffff: protocol all u32 match u8 0 0 action mirred egress redirect dev dest即使用u32分类器匹配全部协议并通过mirred egress redirect动作把源设备流量重定向到目标设备过滤器挂在父句柄ffff:ingress qdisc上动作语义为TC_ACT_STOLEN流量被拦截、不再走源设备的正常发送路径。与之对称removeTCFiltering()L1311 起在删除端点时通过removeRedirectTCFilter()L1217-L1241枚举并删除挂在ffff:句柄上的全部 u32 过滤器再移除 ingress qdisc完成双向规则的清理。为什么 TC-Filter 是默认方案相比 MACVTAPTC-Filter 的优势在 docs/design/architecture/networking.md 中有明确交代配置更简单不依赖内核 macvtap/macvlan 链路直接作用于 veth 与 TAP 两个既有设备CNI 插件兼容性更好对插件创建的 veth 设备形态不敏感任何以 veth 为核心的插件bridge、ipvlan、macvlan 等都可透明工作性能与 MACVTAP 相当且可结合 vhost-net 进一步卸载。网络互联模型的代码抽象在 src/runtime/virtcontainers/network.go 中模型被抽象为NetInterworkingModel枚举源码注释与默认值清晰可查| 枚举值 | 字符串值配置写法 | 语义 | |-|-|-| |NetXConnectDefaultModel|default| 使用DefaultNetInterworkingModel| |NetXConnectMacVtapModel|macvtap| 用 macvtap 桥接容器网络接口 | |NetXConnectTCFilterModel|tcfilter| 用 TC filter 把插件提供的网络接口流量重定向到连接 VM 的 TAP 接口对 ipvlan 和 macvlan 同样有效 | |NetXConnectNoneModel|none| VM 位于主机网络命名空间时使用 | |NetXConnectInvalidModel| — | 哨兵值用于IsValid()校验 |默认模型定义在 network.go L183var DefaultNetInterworkingModel NetXConnectTCFilterModel即默认使用 TC-Filter。GetModel()/SetModel()L146-L178负责字符串与枚举互转供配置解析调用。在connectVMToNetwork()的分发逻辑中network_linux.go L874-L877case NetXConnectTCFilterModel: networkLogger().Info(connect TCFilter to VM network) err setupTCFiltering(ctx, endpoint, queues, disableVhostNet)MACVTAP 模型则走tapNetworkPair()L987 起其中包含macvtapWorkaround常量L946——源码注释说明内核存在限制导致 macvtap/macvlan 链路无法在不删除 veth 的前提下被干净地拆除因此 Kata 用 workaround 方式处理。配置文件中的开关Kata 运行时配置文件.toml.in模板安装时由 Makefile 替换占位符中src/runtime/config/configuration-qemu.toml.in L591-L607 给出了internetworking_model的完整说明# Internetworking model # Determines how the VM should be connected to the # the container network interface # Options: # # - macvtap # Used when the Container network interface can be bridged using # macvtap. # # - none # Used when customize network. Only creates a tap device. No veth pair. # # - tcfilter # Uses tc filter rules to redirect traffic from the network interface # provided by plugin to a tap interface connected to the VM. # internetworking_model DEFNETWORKMODEL_QEMUDEFNETWORKMODEL_QEMU在构建时展开为各 hypervisor 的默认值QEMU/CH 等配置模板中的DEFNETWORKMODEL_QEMU、DEFNETWORKMODEL_CLH、DEFNETWORKMODEL_FC分别对应不同 hypervisor见 configuration-clh.toml.in L370-L386 等同构段落。与之配套的disable_new_netnsconfiguration-qemu.toml.in L645-L650# If enabled, the runtime will not create a network namespace for shim and hypervisor processes. # This option may have some potential impacts to your host. It should only be used when you know what youre doing. # disable_new_netns only works with internetworking_modelnone. The tap device will be in the host network namespace and can connect to a bridge # (like OVS) directly. # (default: false) disable_new_netns false要点disable_new_netns true仅在与internetworking_model none配合时有效——此时不再为 shim/hypervisor 进程新建网络命名空间TAP 设备直接位于主机网络命名空间可直连 OVS 等网桥。该配置默认关闭开启需谨慎评估对主机的影响。对应地network.go L198 中的NetworkConfig.DisableNewNetwork字段承载该语义并在 sandbox.go L1157 的createNetwork()中直接短路返回。MACVTAP早期实现与现状Kata Containers 保留了对MACVTAP的支持它曾是 Kata 早期使用的实现方式Kata 创建一个 MACVTAP 设备直接连接到eth0设备上。MACVTAP 在数据路径上更短不经 TC 过滤器但因下述原因不再作为默认配置复杂度更高对 CNI 插件形态更敏感内核在 macvtap/macvlan 拆除上有已知限制见前文macvtapWorkaround。此外文档明确说明Kata Containers 已弃用对 bridge 模型的支持原因是其性能相对 TC-Filter 和 MACVTAP 均有差距。L3 Forwarding实验性为服务网格而生的路由模型文档中标注为Experimental实验性的 L3 转发模型思路与二层重定向完全不同在主机侧网络命名空间修改路由表把发往 Pod IP 的流量通过 TAP 设备路由出去用途场景与Istio Ambient这类服务网格集成。此类场景中CNI 会在主机侧命名空间配置 iptables 规则node proxy节点代理监听主机侧网络命名空间——这意味着流量必须在主机侧可见、可被 iptables 劫持而不是像 TC-Filter 那样在二层直接被重定向进 VM限制仅支持 IPv4且每个 Pod 只能有一个 IP 地址。该模型在文档中处于实验状态选择时需对照上述限制评估适用性。网络管理面CNM 与 CNIKata Containers 同时支持两种网络管理模型CNMContainer Network ModelDocker/libnetwork 生态使用CNIContainer Network InterfaceKubernetes/containerd/CRI-O 生态使用。二者都是通过调用外部网络插件完成命名空间、veth、IP 的布置Kata 运行时随后在 virtcontainers 层把布置结果NetworkInfo接口、地址、路由、邻居转换为 VM 内的接口与路由。转换逻辑见 network.go 的 generateVCNetworkStructures()它遍历每个 endpoint跳过回环地址区分 IPv4/IPv6 地址族过滤无效的 guest 路由与邻居validGuestRoute/validGuestNeighbor最终生成 agent 协议所需的Interface、Route、ARPNeighbor结构。网络热插拔接口与路由的运行时动态管理除了 Pod 创建时的静态网络搭建Kata Containers 还提供了一组网络子命令与 API用于在运行时添加hotplug、列出和移除 guest 网络端点以及操作 guest 路由表。下图展示了完整的交互时序六个核心操作及底层调用链根据 UML 源文件 docs/design/arch-images/kata-containers-network-hotplug-uml.txt用户侧 CLIkata-runtime与 virtcontainers 库、QEMU、guest agent 的交互如下network add-interface添加接口CLI → virtcontainers.AddInterface → QEMU (QMP hot-add network) agent (UpdateInterface)。 最终返回err, interface detail。UML 注释提醒agent 的UpdateInterface代码需要为网络设备出现增加超时/等待即要等待 QMP 热插完成。network del-interface删除接口CLI → virtcontainers.DeleteInterface → QEMU (QMP hot-delete network)。 注释明确这里不调用 agent依赖 guest 内核清理与接口关联的任何状态。network list-interface列出接口CLI → virtcontainers.ListInterfaces → agent (ListInterfaces)返回接口详情列表。network update-routes更新路由CLI → virtcontainers.UpdateRoutes → agent (UpdateRoutes)。 注释说明路由以one shot方式处理一次性设置全部路由应在接口添加之后调用也应在接口移除之后调用若已知全部结果路由直接以完整列表调用 set routes 即可。network list-routes列出路由CLI → virtcontainers.ListRoutes → agent (ListRoutes)返回路由列表。Sandbox 层 API 实现这些操作在 virtcontainers 的 sandbox.go L1252-L1322 中均有实现与 UML 一一对应AddInterface(ctx, inf)L1253-L1288先generateNetInfo()生成网络信息经s.network.AddEndpoints()把新端点加入 sandbox随后inf.DevicePath endpoints[0].PciPath().String()填充 PCI 路径并调用s.agent.updateInterface(ctx, inf)让 guest 感知新网卡最后s.Save()持久化。注意其失败回滚若后续步骤出错defer会删除刚添加的端点rollback hot attaching endpoint failed保证失败不残留半挂状态RemoveInterface(ctx, inf)L1291-L1307按硬件地址HwAddr匹配端点并RemoveEndpoints热摘除随后Save()正如 UML 所示此路径不通知 agentguest 内核自行清理ListInterfaces(ctx)L1310-L1312直接转发给s.agent.listInterfaces(ctx)UpdateRoutes(ctx, routes)L1315-L1317转发给s.agent.updateRoutes(ctx, routes)注释点明用途例如 portmapping 支持ListRoutes(ctx)L1320-L1322转发给s.agent.listRoutes(ctx)。热插拔能力的前置检查并非所有 hypervisor 都支持网络设备热插拔。在createNetwork()sandbox.go L1156-L1189中caps : s.hypervisor.Capabilities(ctx) if !caps.IsNetworkDeviceHotplugSupported() { spec : s.GetPatchedOCISpec() if utils.IsDockerContainer(spec) { return errors.New(docker container needs network device hotplug but the configured hypervisor does not support it) } }即Docker 容器依赖 hypervisor 的网络热插拔能力Docker 在 Create 与 Start 之间通过 prestart hook 配置容器 netns接口可能尚未就绪若所选 hypervisor 不支持将直接报错拒绝。这一约束也从侧面解释了为何网络互联模型的选择必须与 hypervisor 能力QMP 热插网络、virtio-net 多队列、vhost-net 等一起考量。运行时网络重扫描RescanNetwork为适配 Docker 26 这类Create 之后、Start 之前才配置 veth 与 IP的引擎sandbox.go L333-L362 提供了RescanNetwork()当DisableNewNetwork关闭、当前无任何端点时以 50ms 间隔轮询、最多等待 5 秒等待网络命名空间中的接口出现一旦发现新端点就通知 guest agent 对应的接口与路由使 VM 内网络立即生效。这是热插拔体系在启动期动态网络场景下的补充。实战配置建议综合文档与源码将配置要点归纳如下默认无需改动internetworking_model默认展开为tcfilter对绝大多数 CNIbridge、ipvlan、macvlan场景开箱即用OVS/自管理网络如需让 TAP 直接出现在主机网络命名空间并连接 OVS可设置internetworking_model none并disable_new_netns true但需评估主机网络命名空间被直接暴露的影响MACVTAP 遗留场景仅在确有 MACVTAP 需求时改为macvtap并接受其内核拆除限制见macvtapWorkaround服务网格Istio Ambient需主机侧可见流量的场景评估实验性 L3 转发模型并确认满足仅 IPv4、单 IP/Pod限制运行时网络变更通过kata-runtime network系列子命令add/delete/list-interface、update/list-routes实现热插拔路由更新按一次性全量设置语义使用。延伸阅读架构总览docs/design/architecture/README.mdNetworking 一节指向本文存储与数据面docs/design/architecture/storage.mdKubernetes 集成docs/design/architecture/kubernetes.md网络热插拔时序图源文件docs/design/arch-images/kata-containers-network-hotplug-uml.txt网络核心实现src/runtime/virtcontainers/network.go、src/runtime/virtcontainers/network_linux.go运行时配置模板src/runtime/config/configuration-qemu.toml.in含各 hypervisor 的同构模板赞分享云原生容器运行时【免费下载链接】kata-containersKata Containers is an open source project and community working to build a standard implementation of lightweight Virtual Machines (VMs) that feel and perform like containers, but provide the workload isolation and security advantages of VMs. https://katacontainers.io/项目地址https://gitcode.com/gh_mirrors/ka/kata-containers点击查看免费下载相关推荐Kata Containers Dragonball VMM 设备模型深解析dbs-device 的 MMIO/PIO 陷阱处理、IO 分发与热插拔机制Kata Containers Dragonball VMM 设备模型深解析dbs device 的 MMIO/PIO 陷阱处理、IO 分发与热插拔机制 本篇云原生容器运行时Kata Containers 3.0 runtime-rs 虚拟 CPU 容量规划与热插拔处理机制全解析Kata Containers 3.0 runtime rs 虚拟 CPU 容量规划与热插拔处理机制全解析 导读 本文基于 Kata Containers 仓库云原生容器运行时Moby网络架构容器网络模型与实现原理Moby网络架构容器网络模型与实现原理 在容器化部署中网络通信是连接多个容器、服务与外部世界的关键桥梁。Moby作为容器生态系统的核心项目其网络架构设计直云原生容器运行时虚拟化容器编排上一篇Perspec图像透视校正5个常见问题快速解决方案指南下一篇OpenWorker GUI 的 Playwright E2E 测试体系hermetic Mock 架构与 Live Smoke 实战指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考