云原生容器运行时【免费下载链接】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 以轻量级虚拟机VM的方式承载容器工作负载其架构文档中大量使用了 rootfs、容器镜像container image与 OCI Bundle 等术语。本篇技术指南完整解读这三组核心概念并结合仓库源码与示例命令说明容器管理器、运行时runtime与虚拟机之间如何通过这些概念协同工作。读完本文你将能够准确理解 Kata 架构文档的术语体系并掌握 OCI 兼容容器从镜像到根文件系统的完整转换链路。1. rootfs被挂载为 / 的根文件系统rootfs是root filesystem根文件系统的缩写指被挂载为顶层目录/即俗称的slash的文件系统。这是一个源自 Linux 启动与容器领域的通用术语而非 Kata Containers 专有概念。理解 rootfs 之所以重要是因为 Kata 的整体系统同时使用多个不同的 rootfs宿主机的 rootfs、虚拟机VM内部 guest 镜像的 rootfs以及容器内部由用户指定镜像产生的 rootfs。这些不同层级的 rootfs 共同构成了架构文档中的 Environments 概念具体对应关系如下| 环境类型 | rootfs 来源 | 说明 | |-|-|-| | Host宿主机 | 宿主机自身文件系统 | 容器管理器如 containerd运行的环境 | | VM rootGuest VM | guest image 内的 rootfs | 虚拟机第一层环境内核启动后挂载为/| | VM container rootContainer | 用户请求的容器镜像示例中为ubuntu | 虚拟机内创建的容器环境基于 OCI Bundle |术语提示这里 root 的含义是top level顶层与 rootfs 中 root 的用法一致。尽管系统理论上可以构建多层嵌套环境但标准 Kata Containers 环境不涉及因此架构文档中不展开讨论。2. Container image创建容器的模板而非容器本身在示例命令中用户通过容器镜像名称指定了要运行的容器类型$ sudo ctr run --runtime io.containerd.kata.v2 --rm -t quay.io/libpod/ubuntu:latest foo sh其中quay.io/libpod/ubuntu:latest这个镜像名称对应一个container image可以用来创建一个具有 Ubuntu Linux 环境的容器。在示例中sh(1)命令将运行在一个拥有 Ubuntu rootfs 的容器内部。重要澄清源自原文档 Notecontainer image这个术语具有迷惑性——镜像本身并不是一个容器它只是一组文件an image用来创建容器。更准确的叫法应当是container template容器模板但container image是业界通用术语因此本文沿用标准叫法。从镜像到容器的完整流转过程如下容器管理器通常会从远端站点pull下载容器镜像并在本地保存一份副本本地镜像被容器管理器用来创建OCI Bundle它将构成容器运行的环境创建完 OCI Bundle 后容器管理器启动一个符合 OCI 规范的 runtime在 Kata 场景下即containerd-shim-kata-v2由 runtime 基于该 Bundle 创建容器。2.1 Guest image 与容器镜像的区别需要特别强调的是Kata 架构中还存在一个guest image它与用户请求的容器镜像完全无关。guest image 是用于引导虚拟机的最小根文件系统mini O/S承载 agent 进程由 osbuilder 工具构建支持 initrd 与 rootfs 两种形态。举例说明即使用户创建的是一个运行 BusyBox 镜像的容器其 shell 会运行在 BusyBox 环境中但虚拟机内部用于承载该 BusyBox 的 guest image 可能基于 Ubuntu、Fedora 或其他任何发行版。细节可参阅 guest-assets.md。3. OCI BundleOCI 容器的标准载体要理解后续架构内容需要了解 OCIOpen Containers Initiative兼容容器的高层创建方式一个 OCI 兼容容器由容器镜像转换而来将镜像内嵌的 rootfs 转换为 OCI rootfs bundle即OCI Bundle。OCI Bundle 是一个tar(1)归档通常由容器管理器创建被传递给 OCI runtime由 runtime 将其转换为完整的容器 rootfs。Bundle 包含两个资产3.1 资产一容器镜像的 rootfs这是一个文件目录用来表示容器的 rootfs。对于示例命令该目录包含创建最小 Ubuntu 根文件系统所需的全部文件。3.2 资产二OCI 配置文件config.json这是一个名为config.json的 JSON 文件由容器管理器创建其核心职责包括root.path设置为指定容器 rootfs 的完整路径。在示例中该值为ubuntu。process.args指定用户希望运行的命令列表即 workload工作负载。在示例中workload 为sh(1)。从源码层面看virtcontainers 的 compatoci 包正是围绕这份config.json展开工作的其中ConfigPath()函数将 bundle 路径与config.json文件名拼接得到配置路径ParseConfigJSON()函数则负责将该 JSON 文件反序列化为 OCI 运行时规范对象供 Kata runtime 后续创建沙箱sandbox与容器使用。这也印证了原文档所述OCI 配置是容器管理器与 runtime 之间传递容器定义的标准接口。4. 从 OCI Bundle 到 Kata 虚拟机的落地理解 rootfs、容器镜像与 OCI Bundle 三个概念后再看 Kata 如何将它们落到实处以 containerd 为例的高层流程用户运行示例命令请求创建容器容器管理器守护进程运行单个Kata runtime 实例containerd-shim-kata-v2Kata runtime 加载其配置文件容器管理器通过一组 shimv2 API 调用 runtimeruntime 启动配置的 hypervisorhypervisor 借助 guest assetsguest kernel guest image创建并启动虚拟机通过 DAX 将 guest image 共享进 VM挂载为 VM rootfs/dev/pmem*形成VM root 环境通过 virtio-fs 将 OCI Bundle 挂载到 VM rootfs 内的容器专属目录形成容器环境container rootfsagent 作为 VM 启动的一部分被拉起runtime 调用 agent 的CreateSandboxAPIagent 在容器专属目录中创建容器环境并派生 workload 进程容器管理器将容器控制权交还给运行ctr命令的用户。4.1 多 rootfs 共享virtio-fs 与 virtio-scsi根据存储配置的不同OCI Bundle 的 rootfs 进入虚拟机的方式有两种详见存储文档virtio-fs默认方式。runtime 为每个 VM 启动一个virtiofsd守护进程运行在宿主机上下文通过 VIRTIO 覆盖文件系统挂载点将 workload 镜像共享进 VMagent 以该挂载点作为容器进程的 rootfsvirtio-scsi当配置了块设备类 graph driver 时通过virtio-scsi共享镜像使用 devicemapper snapshotter 时甚至可以直接挂载底层块设备容器内可见为/dev/vda获得优于 virtio-fs 的 I/O 性能。4.2 容器环境的隔离意义Kata 之所以要在 VM 内部再次容器化 workload原因有三点来自架构文档将 workload 与 VM 环境完全隔离为 pod 内多个容器之间提供更好的隔离使 workload 可以通过 cgroup 约束进行管理和监控。容器环境由 agent 在 guest 内核中创建 Linux cgroups 与 namespace 来实现这与runcOCI runtime 创建容器环境的方式等价——只不过这次运行在虚拟机内部。5. 概念速查与常见误区| 概念 | 一句话定义 | 常见误区 | |-|-|-| | rootfs | 被挂载为/的根文件系统 | 误以为系统只有一个 rootfs实际上 host / VM / container 各有各的 rootfs | | container image | 用于创建容器的文件集合 | 误以为镜像就是容器 | | OCI Bundle | 由容器镜像 rootfs config.json组成的归档 | 误以为 Bundle 可以直接运行实际上它需要 runtime 转换 | | guest image | 引导 VM 的最小系统镜像 | 与用户容器镜像混淆 |关键记忆点一个 VM 承载多个容器shimv2 架构下runtime 二进制每个 VM 只运行一次而非每个容器一次这是 Kata 2.x 相比 1.x 的重大改进。config.json 是契约root.path决定容器 rootfs 位置process.args决定 workloadKata runtime 通过 compatoci 解析它再通过 ttRPC 协议驱动 agent 完成容器生命周期管理。镜像与 guest 相互独立用户镜像决定容器内部环境guest image 决定 VM 环境两者互不干预。6. 延伸阅读Kata Containers 架构文档本文所讲概念的完整应用场景示例命令解析贯穿架构文档的ctr run示例Guest assetsguest kernel 与 guest imageVM rootfs 的具体构成存储设计virtio-fs / virtio-scsi / devicemapperOCI Bundle rootfs 进入 VM 的底层机制运行时配置说明configuration.toml如何影响镜像共享与 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点击查看免费下载相关推荐YOLOv8-Face实战教程5分钟实现实时人脸关键点追踪YOLOv8 Face实战教程5分钟实现实时人脸关键点追踪 想要在Python项目中快速实现精准的人脸检测和关键点追踪吗YOLOv8 Face为你提供了一个云原生容器运行时如何快速构建Kata Containers自定义镜像rootfs和initrd完整指南如何快速构建Kata Containers自定义镜像rootfs和initrd完整指南 想要为Kata Containers创建完全自定义的rootfs和in云原生容器运行时OCI镜像清单深度解析如何构建可移植的多架构容器镜像OCI镜像清单深度解析如何构建可移植的多架构容器镜像 OCI镜像清单是构建现代容器化应用的核心技术它定义了容器镜像的标准化格式确保镜像在不同平台和架构间的云原生存储上一篇揭秘AI如何识破伪造图片Fake Image Detector深度解析下一篇Gqrx核心功能解析AM/FM/SSB解调与FFT频谱分析创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考