云原生容器运行时【免费下载链接】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来运行容器工作负载而支撑这个 VM 启动的两大客机资产Guest Assets——Guest Kernel客户机内核与Guest Image客户机镜像——是理解其隔离架构的关键。本文以官方架构文档 guest-assets.md 为骨架结合 osbuilder 构建工具链与 versions.yaml 版本数据库的源码实现系统讲解两种镜像形态rootfs 镜像与 initrd 镜像的差异、VM 内部的启动流程、默认发行版选择依据并给出可复现的构建命令与配置要点。什么是 Guest AssetsKata Containers 创建 VM 的方式是启动一个 hypervisor虚拟机监视器 来生成 VM。hypervisor 完成这项任务需要两类资产Guest Kernel传给 hypervisor、用于引导 VM 的 Linux 内核Guest Image提供最小化根文件系统rootfs的镜像文件供 Guest Kernel 引导 VM 并承载 Kata Container。这两个资产共同构成了 VM 内部的第一层运行环境即架构文档中的 VM root environment。理解它们的关键在于Guest Image 与用户容器工作负载使用的容器镜像完全是两回事。当用户通过ctr run启动一个 BusyBox 容器时BusyBox 是容器环境内的根文件系统而 VM 内部用于承载这个 BusyBox 的 Guest Image则可能运行着 Ubuntu、Fedora 或其他发行版。二者位于不同的隔离层级互不干扰。Guest Kernel为容器负载量身定制的最小内核Guest Kernel 由 Kata Containers 社区维护其默认版本经过高度优化专注于两个核心指标极快的内核启动时间minimal boot time极小的内存占用minimal memory footprint。它只提供容器工作负载所需的必要服务剔除了普通桌面/服务器发行版内核中大量用不到的驱动与子系统。该内核基于最新的 LinuxLTSLong Term Support长期支持内核版本构建在获得稳定安全支持的同时维持 Kata 特有的性能特征。内核打包所需的补丁、配置与构建脚本均存放于仓库的 tools/packaging/kernel 目录含 81 个.conf内核配置与 67 个.patch补丁文件展示了对不同架构与 hypervisor 场景的细粒度裁剪。Guest Image两种形态的最小根文件系统Kata Containers 支持两种基于最小根文件系统的 Guest Image 形态rootfs 镜像disk image与initrd 镜像initramfs。两者都由 osbuilder 工具链构建且官方安装包会同时提供 image 与 initrd 两种产物。注意事项尽管 initrd 与 rootfs 两种镜像都被支持但并非所有 hypervisor 都同时支持这两种形态选用前需确认目标 hypervisor 的能力Guest Image 与容器工作负载使用的镜像无关二者属于不同的隔离层级使用 打包安装的 Kata Containers 时可以以root身份运行kata-collect-data.sh脚本在输出的 Image details 一节查看当前安装的镜像详细信息。Rootfs 镜像mini O/S默认打包的 rootfs 镜像又被称为mini O/S迷你操作系统是一个高度优化的容器引导系统。当在配置文件中配置了该镜像类型后用户执行示例命令sudo ctr run --runtime io.containerd.kata.v2 --rm -t quay.io/libpod/ubuntu:latest foo sh时启动过程如下runtime 启动配置好的 hypervisorhypervisor 使用 Guest Kernel 引导 mini-OS 镜像内核在 VM 根环境中启动 PID 1 的 init 守护进程systemdsystemd在 mini-OS 上下文中、以 VM 根上下文启动 agentagent 创建新的容器环境将其根文件系统设置为用户请求的内容示例中为 Ubuntuagent 在新容器内执行用户命令示例中为sh(1)。下表总结了默认 mini O/S 中创建的环境、各环境中运行的服务覆盖所有平台以及每个服务使用的根文件系统| Process | Environment | systemd service? | rootfs | User accessible | Notes | |-|-|-|-|-|-| | systemd | VM root | n/a | VM guest image | debug console | The init daemon, running as PID 1 | | Agent | VM root | yes | VM guest image | debug console | Runs as a systemd service | |chronyd| VM root | yes | VM guest image | debug console | Used to synchronise the time with the host | | container workload示例中为sh(1) | VM container | no | User specified示例中为 Ubuntu | exec command | Managed by the agent |表格解读User accessible 列说明管理员如何进入对应环境VM 根环境通过 debug console调试控制台访问容器环境通过exec命令访问容器工作负载运行在完整的容器环境中而该容器环境本身又运行在 VM 环境之内——这就是 Kata 提供的双层隔离chronyd服务用于与主机同步 VM 内的时间说明 mini-OS 内置了基础的时间同步能力除 Intel x86_64 外其他平台的默认发行版细节可查看 osbuilder 的 rootfs-builder 配置文件。Initrd 镜像initrd 镜像是从 rootfs 构建的压缩cpio(1)归档。在内核启动过程中它被加载到内存并被内核解包到一个特殊的tmpfs挂载中成为初始根文件系统。配置 initrd 镜像类型时同样的示例命令会经历如下流程runtime 启动配置好的 hypervisorhypervisor 使用 Guest Kernel 引导 mini-OS 镜像内核在 VM 根环境中启动 PID 1 的 init 守护进程——这里直接就是 agentinitrd 形态下 agent 即 init无需 systemd 中转agent 创建新的容器环境将根文件系统设置为用户请求的内容示例中为ubuntuagent 在新容器内执行用户命令示例中为sh(1)。对应地initrd 形态下的环境与进程总结如下| Process | Environment | rootfs | User accessible | Notes | |-|-|-|-|-| | Agent | VM root | VM guest image | debug console | Runs as the init daemon (PID 1) | | container workload | VM container | User specified示例中为 Ubuntu | exec command | Managed by the agent |两种形态的对比要点rootfs 镜像的 PID 1 是systemdagent 由 systemd 作为服务拉起initrd 镜像的 PID 1 直接是 agent官方文档指出如果确实需要initrd 镜像同样可以使用 systemd 等标准 init 守护进程——这一选择权由构建时的配置决定两条启动链路共同的本质是agent 始终是容器生命周期创建环境、设置 rootfs、执行命令的管理者。Image summary默认发行版的选择逻辑| Image type | Default distro | Init daemon | Reason | Notes | |-|-|-|-|-| | image | Ubuntux86_64 系统 | systemd | 在 CI 中经过完整测试 | systemd 提供了灵活性 | | initrd | Alpine Linux | Kata agent因无 systemd 支持 | 安全加固且 C 库极小 | |选择逻辑值得注意rootfs 镜像选择 Ubuntu systemd是因为 systemd 的灵活性经过了 CI 的完整验证initrd 镜像选择 Alpine是因为其安全加固特性与极小的 C 库musl非常适合内存中的最小启动镜像且 Alpine 不使用 systemd因此 initrd 形态下 agent 直接充当 init 守护进程。源码层面的证据versions.yaml 与 osbuilder默认镜像由版本数据库统一声明文档引用的default-image-name与default-initrd-name选项在仓库中落实为 versions.yaml 的assets.image与assets.initrd两个条目见 versions.yaml。该文件按架构aarch64、ppc64le、s390x、x86_64分别声明默认发行版与版本。以当前仓库为例x86_64 架构下 image 的默认配置为x86_64: name: ubuntu version: resolute # 26.04 LTS confidential: name: ubuntu version: resolute # 26.04 LTS mariner: name: cbl-mariner version: 3.0从源码结构可以推断默认发行版并非写死的单一值而是按架构、按特性场景confidential 机密计算、nvidia-gpu、mariner 等提供可选组合initrd 条目采用同样的声明结构。这为不同架构与部署形态的差异化构建提供了统一的版本管理入口。osbuilder构建 Guest Image 的工具链所有默认镜像类型都由 osbuilder 构建。其顶层 Makefile 提供了一条命令从 rootfs 到 initrd/image 的完整流水线内部按distro发行版专用命令如debootstrap、yum与dracut发行版无关两种构建方法实现。常用构建命令如下均需要 root 权限可通过USE_DOCKERtrue或USE_PODMANtrue在容器内构建# 构建 rootfs默认 UbuntuAGENT_INITyes 时 agent 作为 init $ sudo -E PATH$PATH make USE_DOCKERtrue rootfs $ sudo -E PATH$PATH make USE_DOCKERtrue AGENT_INITyes rootfs # 由 rootfs 构建镜像 $ sudo -E PATH$PATH make USE_DOCKERtrue image # 由 rootfs 构建 initrd $ sudo -E PATH$PATH make AGENT_INITyes initrd从 rootfs-builder 的目录结构alpine/、cbl-mariner/、centos/、debian/、ubuntu/等与源码可见每个发行版通过config.sh描述其特性。例如 ubuntu/config.sh 声明OS_NAMEubuntu PACKAGESchrony iptables dbus # cryptsetup-bin 与 e2fsprogs 无条件安装 # - cryptsetup-bin 供 CDH 机密客体的安全存储加密卷使用 # - e2fsprogs (mke2fs/mkfs.ext4) 供 CDH 安全存储与普通临时存储功能使用 PACKAGES cryptsetup-bin e2fsprogs这印证了 mini O/S 表格中chronyd对应chrony包作为系统服务的来源而 alpine/config.sh 则声明OS_NAMEAlpine OS_VERSION${OS_VERSION:-3.18} BASE_PACKAGESalpine-base PACKAGESbash iptables ip6tables # Init process must be one of {systemd,kata-agent} INIT_PROCESSkata-agentINIT_PROCESSkata-agent正是 initrd 表格中agent 充当 PID 1 init 守护进程这一事实的构建期来源。此外rootfs-builder/README.md 还明确了 rootfs 的硬性要求必须包含/bin/kata-agentKata agent与/sbin/initinit 系统当AGENT_INITyes时 agent 被放置为/sbin/init且Alpine 发行版必须使用AGENT_INITyes因为它不使用 systemd。镜像制作由 image-builder 的image_builder.sh完成它接收rootfs.sh生成的 rootfs 目录并产出最终磁盘镜像$ sudo ./image_builder.sh path/to/rootfs其用法包括镜像尺寸调整可通过./image_builder.sh -h查看。扩展与调试如何验证你的 Guest Assets查看已安装镜像的详细信息以root运行kata-collect-data.sh在输出的 Image details 一节查看 Guest Image 与 initrd 的名称、发行版与版本等细节这是排查镜像与内核版本是否匹配的首选手段进入 VM 根环境调试管理员可通过 debug console 进入 VM root 环境直接观察 systemd、agent、chronyd等进程的实际运行状态构建自定义镜像osbuilder 支持EXTRA_PKGS环境变量注入额外软件包例如EXTRA_PKGSvim emacs ./rootfs-builder/rootfs.sh -r ${PWD}/myrootfs debian或在config.sh中修改PACKAGES变量满足站点特定的定制需求。小结Guest Assets 是 Kata Containers 双层隔离架构的物理基础Guest Kernel 提供极速启动的最小内核Guest Imagerootfs 镜像或 initrd 镜像提供承载 agent 的最小根文件系统。通过 osbuilder 工具链两个资产从config.sh定义的发行版配置出发经 rootfs → image/initrd 的流水线产出versions.yaml 则按架构与场景统一声明默认发行版。理解这套机制无论是排查镜像问题、构建自定义镜像还是深入 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点击查看免费下载相关推荐如何使用 rdf-reindex-benchmark.sh 测量 OpenMetadata 完整 RDF 重建的性能如何使用 rdf reindex benchmark.sh 测量 OpenMetadata 完整 RDF 重建的性能 OpenMetadata 把 RDF 知识云原生容器运行时Kata Containers 在虚拟机 Guest 内拉取容器镜像Guest Image Pull实战指南Kata Containers 在虚拟机 Guest 内拉取容器镜像Guest Image Pull实战指南 Kata Containers 自 3.3.0云原生容器运行时Kata Containers Tracing 全解析基于 OpenTelemetry 实现 Runtime 与 Guest Agent 的全链路追踪Kata Containers Tracing 全解析基于 OpenTelemetry 实现 Runtime 与 Guest Agent 的全链路追踪 Kat云原生容器运行时创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考