Kata Containers Runtime-rs 中的 Passthrough-FD IO：Dragonball VMM 直通式进程 IO 优化实战

云原生容器运行时【免费下载链接】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点击查看免费下载Passthrough-FDpass-fd是 Kata Containers 为优化容器进程 IO 性能引入的一项关键技术它让 Dragonball VMM 的 hybrid-vsock 直接接收并传递宿主机文件描述符从而绕过 kata-shim 的中转缓冲层显著降低 IO 延迟与 CPU 开销。本文以 docs/how-to/how-to-use-passthroughfd-io-within-runtime-rs.md 为骨架结合 runtime-rs 与 kata-agent 的源码实现完整讲解其工作原理、端到端数据流以及配置启用方法读者读完后可掌握该特性的适用边界、底层调用链与实际配置方式。重要限制仅 Dragonball VMM 支持在深入技术细节之前必须先明确该特性的适用范围专属支持 Dragonball VMMPassthrough-FD 目前只在 Kata Containers 内置 VMM——Dragonball 上实现并生效不支持的 VMMQEMU、Cloud HypervisorCLH、Firecracker 等其他 VMM 当前均不支持该特性。从源码结构看这一点与 runtime-rs 的 hypervisor 抽象设计一致虽然 hypervisor 接口 中定义了get_passfd_listener_addr()方法QEMU、CLH、Firecracker、OpenVMM、Remote 等实现均有对应桩实现但真正完整落实 FD 直通链路的只有 Dragonball 路径。runtime-rs 在创建 hypervisor 实例时也仅在匹配到 Dragonball 且开启了use_passfd_io的情况下才会调用set_passfd_listener_port()注入监听端口参见 lib.rs。背景传统 IO 路径的瓶颈在引入 Passthrough-FD 之前Kata 的容器进程 IO 流stdin/stdout/stderr是通过ttrpc virtio-vsock实现的数据流如下这一路径的核心问题在于 kata-shim 扮演了中间人角色kata-shimcontainerd-shim-kata-v2通过 shimv2 接口打开 containerd 提供的 FIFO 管道得到 stdin、stdout、stderr 三个 FDkata-shim 为这三条流分别管理三个独立线程每个线程都必须先把数据从 FD 读入 shim 内部缓冲区再通过 ttrpc 经 vsock 转发到 guest 内的 kata-agent最终才到达容器进程。多线程代理加上三层缓冲FD → shim buffer → ttrpc/vsock → agent导致数据路径过长、效率低下。原文档给出的一个直观例子是复制 10GB 文件可能耗时长达 10 分钟。这一痛点正是 Kata AC 成员 lifupan 与 frezcirno 引入 passthrough-fd 技术优化的动因。什么是 Passthrough-FDPassthrough-FD 的核心思想是让 VMM 直接处理文件描述符。它增强了 Dragonball VMM 的 hybrid-vsock 实现使其支持 recv-fd接收带 FD 的报文从而把宿主机上的 FD 直接穿透到 kata-agent而不是让 kata-shim 先把数据读进自己的缓冲区再转发。启用后的数据流变为对比传统路径可以发现kata-shim 的缓冲代理层被整体移除。hybrid-vsock 模块可以直接从 Host 接收文件描述符系统将 Host 的 FD 直通给 kata-agentIO 流在 guest 环境中被直接接通消除了 kata-shim 中的代理逻辑。端到端工作原理整个过程的完整时序如下整个过程分为六个关键步骤Agent 初始化kata-agent 启动一个服务器监听passfd_listener_port指定的端口。对应实现见 main.rs当配置的passfd_listener_port ! 0时调用passfd_io::start_listen(port)。FD 传输在容器创建阶段kata-shim 通过 sendfd 机制将 stdin、stdout、stderr 三个 FD 发送给 Dragonball hybrid-vsock 模块。连接建立借助 hybrid-vsock这些 FD 连接到第 1 步中 agent 启动的服务器。标识与保存agent 的服务器调用accept()获得连接 FD 及其对应的 host-port并以 host-port 作为唯一标识保存连接。此时 agent 持有三条已建立连接分别由 stdin-port、stdout-port、stderr-port 标识。RPC 映射kata-shim 调用create_containerRPC 时把这三个端口标识一并放入请求。最终绑定agent 收到 RPC 后根据传入的端口从保存的连接中取出对应连接直接绑定到容器进程的标准 IO 流上。源码印证kata-agent 侧的实现细节kata-agent 侧的完整逻辑集中在 passfd_io.rsstart_listen(port)通过VsockListener::bind(libc::VMADDR_CID_ANY, port)绑定到 guest 内任意 CID 的指定端口循环accept()并把(peer port → VsockStream)立即插入全局映射HVSOCK_STREAMS注释明确说明尽快插入映射以最小化竞态风险take_io_streams(stdin_port, stdout_port, stderr_port)按端口从映射中取出流端口为0时返回None表示该流未启用直通回退到常规路径若流已被 accept 但尚未插入映射会最多重试 3 次、每次间隔 100ms最终组装成rustjail::process::ProcessIo供容器进程使用。调用点位于 rpc.rsdo_create_container在创建容器伊始即调用take_io_streams且注释强调先创建 proc_io若后续出错可确保 IO 流被正确关闭。源码印证runtime-rs 侧与配置的传递链路runtime-rs 侧的配置传递链路完整闭环从配置到内核参数再到 RPC 请求配置解析后runtime-rs 在创建 hypervisor 时仅 Dragonball 且use_passfd_io true调用set_passfd_listener_port()见 lib.rsDragonball 启动时将该端口以内核参数agent.passfd_listener_portport的形式注入 guest见 inner.rskata-shimruntime-rs 容器创建路径通过get_passfd_listener_addr()拿到 hybrid-vsock 的 UDS 路径与监听端口见 inner_hypervisor.rs容器创建时调用init_process.passfd_io_init(hvsock_uds_path, port)建立三条直通连接并把stdin_port、stdout_port、stderr_port填入CreateContainerRequest发给 agent见 container.rs。如何启用 Passthrough-FD IOPassthrough-FD 由 Kata 配置文件中的两个参数控制参数含义默认值use_passfd_io布尔开关启用/禁用 Passthrough-FD IO 特性falsepassfd_listener_portkata-agent 监听 FD 连接的端口1027在 runtime-rs 的 Dragonball 配置模板 configuration-dragonball.toml.in 中该特性默认即为开启状态配置写法如下... # If enabled, the runtime will attempt to use fd passthrough feature for process io. # Note: this feature is only supported by the Dragonball hypervisor. use_passfd_io true # If fd passthrough io is enabled, the runtime will attempt to use the specified port instead of the default port. passfd_listener_port 1027启用步骤与注意事项确保使用 Dragonball VMMruntime-rs 的configuration-dragonball.toml.in对应配置将use_passfd_io设为true按需调整passfd_listener_port默认1027该端口会同时配置给 runtime-rs 与 kata-agent若passfd_listener_port配置为0kata-agent 将不会启动 passfd 监听见 main.rs此时即便use_passfd_io true也无法生效需保持非 0 值。配置项的源码映射runtime-rs 侧use_passfd_io与passfd_listener_port定义在 runtime.rs其中passfd_listener_port带默认值函数default_passfd_listener_port()即1027agent 侧对应配置项为agent.passfd_listener_port定义在 agent.rs其解析逻辑位于 config.rs并通过agent.passfd_listener_port内核参数注入常量定义见 mod.rs。这种一份配置、两端生效的设计确保了 runtime-rs 与 kata-agent 对监听端口理解一致是直通链路能够正确建立的前提。迁移视角Go runtime 与 Runtime-rs 的配置对应若读者正在从传统 Go runtime 迁移到 runtime-rs可在 migrating-config-go-runtime-to-runtime-rs.md 中找到两个配置项的对应关系passfd_listener_port在两套 runtime 中均表示 fd-passthrough IO 特性所用端口agent 侧迁移时注意核对端口取值与use_passfd_io开关是否一致。总结Passthrough-FD 通过FD 直通重构了 Kata 容器进程 IO 的数据通路kata-shim 不再充当数据搬运工hybrid-vsock 直接接收宿主机 FDkata-agent 以端口为索引完成流与容器标准 IO 的绑定。这一设计从根源上消除了多线程代理与缓冲拷贝带来的开销是 Kata Containers 针对 IO 性能优化的重要实践。其完整链路在仓库中均可验证从 configuration-dragonball.toml.in 的配置入口到 runtime-rs 侧 container.rs 的端口注入再到 kata-agent 侧 passfd_io.rs 的监听与流管理形成了清晰可追踪的实现闭环。使用前请务必确认 VMM 为 Dragonball并保持use_passfd_io true与passfd_listener_port非 0 的配置前提。赞分享云原生容器运行时【免费下载链接】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点击查看免费下载上一篇终极直播录制解决方案40平台自动监控与智能录制完整指南下一篇如何用开源工具实现40平台7×24小时直播自动录制DouyinLiveRecorder深度解析创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考