深入解析 Kata Containers 的 containerd 示例命令：从 `ctr run` 到 shimv2 虚拟机工作负载

云原生容器运行时【免费下载链接】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 中并非只启动一个容器进程而是触发了一条完整链路containerd 拉起 shimv2 运行时、运行时加载配置并启动 hypervisor、hypervisor 创建并引导一台轻量虚拟机VM、VM 内的 kata-agent 接收请求后在用户指定的 rootfs 中孵化出工作负载进程。本文以 Kata Containers 架构文档 全文反复引用的示例命令为骨架逐参数拆解其语义并结合仓库源码与containerd 集成指南讲解该命令背后的 shimv2 架构、环境模型、容器创建与退出流程以及在实际部署中如何落地执行。读完本文你将能准确理解这条命令的每一个字面含义并具备在 containerd 环境中排查与复现 Kata 容器行为的基础能力。一、示例命令总览example-command.md 给出的完整命令如下$ sudo ctr run --runtime io.containerd.kata.v2 --rm -t quay.io/libpod/ubuntu:latest foo sh这条命令请求 containerd 完成以下工作| 命令片段 | 含义 | |-|-| |ctr run| 创建一个容器并运行它create start | |--runtime io.containerd.kata.v2| 使用 Kata 的 shimv2 运行时 | |--rm| 容器退出后自动删除 | |-t| 分配伪终端并把容器附着到用户终端 | |quay.io/libpod/ubuntu:latest| 容器镜像用于生成容器的 rootfs | |foo| 容器名称 | |sh| 在 Ubuntu rootfs 容器环境中执行的命令即工作负载workload |注意为简化说明架构文档假设用户是在主机环境host environment中执行这条命令。事实上这条命令贯穿了整个架构文档用于解释工作负载、环境模型、容器创建、存储与进程分布等各个概念。二、--runtime io.containerd.kata.v2shimv2 运行时2.1 shimv2 是什么Kata Containers 提供的运行时是一个兼容 containerdshim v2 API简称 shimv2的运行时。在 shimv2 架构下containerd 不再为每个新容器多次调用 runtime 二进制而是只运行 runtime 二进制的一个实例可为任意数量的容器服务从而提升性能并解决状态处理问题。shimv2 API 与 OCI runtime API 类似将容器生命周期拆分为不同的动词。containerd 创建一个 socket 并传给 shimv2 运行时该 socket 是基于 gRPC 的双向通信通道容器管理器通过它向运行时发送 API 调用运行时再沿同一通道返回结果。正是这种架构让 Kata 支持一个 VM 里运行多个容器从而满足容器引擎在一个 Pod 内运行多个容器的需求Kubernetes 每 Pod 只需一个 runtime shim而不再需要每个容器一个containerd-shim加一个kata-shim即不再需要2N1个 shim即使没有 VSOCK 也无需独立的kata-proxy进程。2.2 源码中的运行时注册io.containerd.kata.v2不是随意写的字符串。在源码中该字符串被定义为运行时默认名称src/runtime/pkg/types/types.go 中DefaultKataRuntimeName io.containerd.kata.v2。src/runtime/cmd/containerd-shim-kata-v2/main.go 中程序入口通过shimapi.Run(types.DefaultKataRuntimeName, shim.New, shimConfig)以 shimv2 模式启动其中shim.New来自 src/runtime/pkg/containerd-shim-v2 包。containerd 会将形如io.containerd.kata.v2的点连接字符串翻译为二进制名containerd-shim-kata-v2该二进制默认安装于/usr/local/bin/。运行时二进制即containerd-shim-kata-v2它同时是容器运行时与shim v2 API 实现这也是它有时被直接称为 Kata shim 的原因。三、环境模型三层环境要理解这条命令的作用域需要先建立环境environments的概念。Kata 系统存在三层环境| 类型 | 名称 | 虚拟化 | 容器化 | rootfs | Rootfs 设备类型 | 挂载类型 | |-|-|-|-|-|-|-| | 主机 | Host | 否 | 否 | 主机相关 | 主机相关 | 主机相关 | | VM 根 | Guest VM | 是 | 否 | 客户机镜像内的 rootfs | hypervisor 相关 |ext4| | VM 容器根 | Container | 是 | 是 | 用户请求的 rootfs示例中为ubuntu |kataShared| virtio FS |其中Host标准的、物理非虚拟化系统提供的环境为简化文档假定主机运行在物理硬件上。Guest VMVM root主机上创建的第一层 VM 环境rootfs 位于客户机镜像guest image内部。ContainerVM 容器根VM 内部创建的第一层容器环境基于 OCI bundle 创建。root 一词在此表示顶层与 rootfs 的语义一致第一层前缀意味着理论上可以构建多层系统但多层系统不属于标准 Kata 环境不在本文讨论范围。3.1 为何要在 VM 内再做容器化将工作负载隔离在 VM 内的容器环境中原因有三将工作负载与 VM 环境完全隔离提供 Pod 内容器之间更好的隔离通过 cgroup 约束对工作负载进行管理与监控。四、工作负载与容器镜像4.1 什么是 workload工作负载是用户请求在容器中运行的命令记录在 OCI bundle 的配置文件中。在本示例中工作负载就是sh(1)命令。一个 OCI 兼容容器是这样被创建的容器管理器将容器镜像内嵌的 rootfs 转换为 OCI rootfs bundle即tar(1)归档内含两部分资产容器镜像 rootfs一个目录包含用于表示容器根文件系统的文件示例中即构建最小 Ubuntu 根文件系统所需的文件。OCI 配置文件名为config.json的 JSON 文件。其中root.path被设置为指定容器 rootfs 的完整路径示例中为ubuntuprocess.args数组指定用户要运行的命令列表即工作负载示例中为sh(1)。4.2 容器镜像 ≠ 容器background.md 特别提醒容器镜像并不是容器它只是一组文件一个镜像可用于创建容器更准确的叫法或许是容器模板但行业习惯沿用容器镜像这一标准术语。正常情况下容器管理器会从远端拉取pull镜像并本地保存再用本地镜像创建 OCI bundle最后启动 runtime 依据 bundle 创建容器。五、容器创建流程一条命令背后的完整链路在 containerd 容器管理器下一条ctr run命令触发的高层流程如下见 README.md 的 Container creation 小节用户执行类似示例命令的命令请求创建容器。容器管理器守护进程运行 Kata runtime 的单个实例。Kata runtime 加载其配置文件。容器管理器在 runtime 上调用一组 shimv2 API 函数。Kata runtime 启动配置的 hypervisor。hypervisor 使用客户机资产guest assets创建并引导 VMhypervisor 通过 DAX 将客户机镜像共享进 VM 成为 VM 的 rootfs挂载在/dev/pmem*设备上即VM root 环境hypervisor 使用 virtio FS 将 OCI bundle 挂载进 VM rootfs 内的容器专用目录该目录将成为容器 rootfs容器环境。agent 作为 VM 启动的一部分被启动。runtime 调用 agent 的CreateSandboxAPI 请求创建容器agent 在包含容器 rootfs 的容器专用目录中创建容器环境该环境在容器 rootfs 目录中托管工作负载agent 在容器环境内孵化工作负载进程。容器管理器将容器控制权交还给执行ctr命令的用户。注意agent 创建的容器环境等价于runcOCI runtime 创建的容器环境Linux cgroups 与 namespace 由客户机内核在 VM 内创建用于将工作负载与容器所在的 VM 环境隔离。此时容器已在运行工作负载示例中的sh(1)运行在容器环境中用户可通过示例中的ctr命令与之交互VM 内的 agent 正在监控工作负载进程runtime 正在等待 agent 的WaitProcessAPI 调用完成。5.1 客户机资产与 mini-OShypervisor 创建 VM 需要两样资产一个 Linux 内核和一个用于引导 VM 的小型根文件系统镜像见 guest-assets.md客户机内核guest kernelKata 默认提供的内核针对引导时间与最小内存占用做了高度优化仅提供容器工作负载所需的服务基于最新 Linux LTS 内核。客户机镜像guest image提供最小 rootfs 的镜像文件支持 initrd 与 rootfs 两种形态均由 osbuilder 工具构建。注意客户机镜像与容器工作负载使用的镜像无关——即使用户跑的是 BusyBox 容器承载它的 VM 内运行的 mini-OS 可能是 Ubuntu、Fedora 或其它发行版。当用户运行示例命令且配置为 rootfs 镜像mini-OS时runtime 启动 hypervisor → hypervisor 用客户机内核引导 mini-OS → 内核以 PID 1 启动 init 守护进程systemd→systemd在 VM 根环境启动 agent → agent 创建新的容器环境并把 rootfs 设为用户请求的镜像示例为 Ubuntu→ agent 在容器内执行sh(1)。该模式下 VM 根环境还运行chronyd用于与主机同步时间。若配置为 initrd 镜像则内核直接以 agent 作为 PID 1 启动流程类似。六、容器退出与关闭容器环境有两种终止方式见 README.md 的 Container shutdown 小节工作负载退出标准/优雅关闭agent 检测到工作负载进程退出捕获其退出状态参见wait(2)并通过WaitProcessagent API 调用的响应返回给 runtimeruntime 再通过Waitshimv2 API 调用把值传回容器管理器。工作负载完全退出后 VM 不再需要runtime 清理环境包括终止 hypervisor 进程。这也是--rm参数生效的时机——容器退出即被删除。容器管理器强制删除runtime 向 agent 发送DestroySandboxttRPC API 请求。注意当启用 agent 追踪时关闭行为会有所不同。七、运行时、agent 与进程分布7.1 runtime 与 agent 的职责runtime即containerd-shim-kata-v2二进制src/runtime/cmd/containerd-shim-kata-v2重度使用 virtcontainers 包一个通用的、与 runtime 规范无关的硬件虚拟化容器库。它负责启动 hypervisor 及其 VM并通过 VSOCK socket 上的 ttRPC 协议与 agent 通信该协议既用于发送容器管理命令也承载容器与容器管理器CRI-O / containerd之间的标准 I/O 流stdout、stderr、stdin。agentkata-agent用 Rust 编写的长驻进程运行在 VM 内作为容器的监督者管理容器及其中的工作负载每个 VM 只运行一个 agent。源码位于 src/agent。7.2 进程总览执行示例命令后各环境中的主要进程分布如下见 README.md 的 Process overview 小节| 描述 | Host | VM root 环境 | VM 容器环境 | |-|-|-|-| | 容器管理器 |containerd| | | | Kata Containers | runtime、virtiofsd、hypervisor | agent | | | 用户工作负载 | | |ubuntu sh|其中virtiofsd是 runtime 为每个 VM 启动的一个 host 上下文守护进程用于 virtio-fs 共享见 storage.md。八、如何真实运行这条命令8.1 containerd 注册 Kata 运行时在 containerd 集成指南中要在 containerd 里注册 Kata 运行时以 containerd 2.x 为例version 3 [plugins.io.containerd.cri.v1.runtime.containerd] [plugins.io.containerd.cri.v1.runtime.containerd.runtimes] [plugins.io.containerd.cri.v1.runtime.containerd.runtimes.runc] runtime_type io.containerd.runc.v2 [plugins.io.containerd.cri.v1.runtime.containerd.runtimes.kata] runtime_type io.containerd.kata.v2 [plugins.io.containerd.cri.v1.runtime.containerd.runtimes.kata.options] ConfigPath /opt/kata/share/defaults/kata-containers/configuration.tomlcontainerd 1.7.x 的配置类似仅需将io.containerd.cri.v1.runtime替换为io.containerd.grpc.v1.cri。ConfigPath可选若不指定shimv2 会依次尝试环境变量KATA_CONF_FILE出于安全仅接受 Kata 自带默认配置文件之一以及默认路径/etc/kata-containers/configuration.toml、/usr/share/defaults/kata-containers/configuration.toml、/opt/kata/share/defaults/kata-containers/configuration.toml。8.2 用ctr实际运行与架构文档示例命令最接近的真实用法见 containerd-kata.md 的 Run 小节$ sudo ctr image pull docker.io/library/busybox:latest $ CONFIG_PATH/opt/kata/share/defaults/kata-containers/configuration-qemu.toml $ sudo ctr run --cni --runtime io.containerd.kata.v2 --runtime-config-path $CONFIG_PATH -t --rm docker.io/library/busybox:latest hello sh差异与要点ctr命令行不支持 containerd 配置中的ConfigPath需用--runtime-config-path显式指定否则使用默认配置。--cni启用 CNI 网络不加该标志则容器只有 loopback 接口。--rm使容器退出即删除-t分配终端并附着。架构文档示例quay.io/libpod/ubuntu:latest强调 Ubuntu rootfs 这一概念sh(1)将运行在 Ubuntu 环境内而真实部署中镜像名称可自由替换为任意镜像镜像与 VM 内承载它的 mini-OS 相互独立。8.3 以 rootfs bundle 方式运行不依赖镜像拉取时可手工构造 OCI bundle用ctr i pull/ctr i export导出 rootfs 并解包到 bundle 目录用runc spec生成config.json并把root.path改为 rootfs 的绝对路径最后执行CONFIG_PATH/opt/kata/share/defaults/kata-containers/configuration-qemu.toml sudo ctr run -d --runtime io.containerd.kata.v2 --runtime-config-path $CONFIG_PATH --config bundle/config.json hello sudo ctr t exec --exec-id ${ID} -t hello sh这正是OCI bundle 中的process.args即工作负载这一文档概念的可执行化验证第二条命令通过ctr t exec在已创建容器中执行sh第一条命令创建的容器则承载后续工作负载。8.4 Kubernetes / CRI 场景在 Kubernetes 中Kata 通过RuntimeClass选择运行时每个 Pod 一个 shim 即可承载 Pod 内所有容器。此外CRI-O 会向config.json添加io.kubernetes.cri-o.ContainerType注解取值为sandbox或containerKata 据此判断是创建新 VM还是在既有 Pod 的 VM 内创建容器见 README.md 的 OCI annotations 小节。九、调试与延伸阅读调试控制台kata-runtime exec命令允许管理员进入 VM root 环境工作负载无法访问详见 开发者指南kata-runtime policy set policy.rego --sandbox-id XXXXXXXX可用于通过策略启用/禁用 kata-agent API策略文件可用 genpolicy 工具生成。agent 控制工具agent-ctl 是测试与开发工具可向 agent 发送任意 ttRPC 命令是理解 agent 通信协议的实践入口。存储与网络镜像共享机制virtio-scsi / virtio-fs / devicemapper详见 storage.md网络模型TC-Filter、MACVTAP、L3 forwarding、网络热插拔详见 networking.md。术语表环境、rootfs、工作负载等术语的完整定义参见项目术语表。十、小结sudo ctr run --runtime io.containerd.kata.v2 --rm -t quay.io/libpod/ubuntu:latest foo sh表面上是普通的 containerd 命令实则是理解 Kata Containers 架构的最佳入口--runtime选择 shimv2 运行时并触发 VM 创建链路镜像参数决定容器 rootfs 环境sh即工作负载--rm对应工作负载退出后的优雅关闭流程。结合 src/runtime 与 src/agent 源码、containerd 集成指南及架构文档你可以从这条命令出发逐步掌握 Kata 的三层环境模型、agent/runtime 通信协议与完整的容器生命周期管理。赞分享云原生容器运行时【免费下载链接】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点击查看免费下载相关推荐终极指南如何将B站缓存视频合并为完整MP4文件终极指南如何将B站缓存视频合并为完整MP4文件 还在为B站缓存的分段视频无法离线观看而烦恼吗今天我要为你介绍一款强大的Android工具——Bilibili云原生容器运行时使用 Kata Containers 与 Containerd从 shimv2 架构到 RuntimeClass 配置实战使用 Kata Containers 与 Containerd从 shimv2 架构到 RuntimeClass 配置实战 本文是《How to use Ka云原生容器运行时Kata Containers Dragonball Sandbox面向容器负载的轻量级 KVM 虚拟机管理器Kata Containers Dragonball Sandbox面向容器负载的轻量级 KVM 虚拟机管理器 Dragonball Sandbox 是 Ka云原生容器运行时上一篇如何理解PHP差异计算中的Line类3种状态的核心设计理念下一篇Process Ghosting完全指南从基础原理到实战演示的终极教程创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考