云原生容器运行时【免费下载链接】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 官方架构文档中的 历史篇 为核心骨架系统梳理项目从 Kata 1.x 到 2.x 的架构演进脉络为什么旧架构在多次调用 runtime、shim、proxy 时遭遇状态管理与性能瓶颈shimv2 又如何通过每个 VM 一个常驻 runtime 进程彻底解决这些问题。读完本文你将理解kata-runtime与containerd-shim-kata-v2两个二进制在前后两代架构中的角色差异并能在当前仓库中定位对应的入口实现与配置证据。从 Kata 1.x 说起经典 OCI runtime 架构在早期的 Kata 1.x 架构 中Kata 的 runtime 是一个名为kata-runtime的可执行文件。当容器管理器如 Docker、containerd、CRI-O要创建一个容器时每一次生命周期操作都会以不同的 OCI 命令行动词verb再次调用这个二进制。这种设计有两个天然的短板状态难以跨调用保持创建容器、启动容器、等待退出是多次独立的进程调用每次调用之间 runtime 无法天然共享内存中的状态只能依赖持久化或反复重建上下文。这种架构对普通命名空间容器尚可容忍但对创建虚拟机 引导 guest OS这种重量级操作来说状态处理成本被急剧放大。性能开销大每创建一个容器都要反复 spawn 新的 runtime 进程在没有 VSOCK 的系统上还需要额外拉起 Kata shimkata-shim二进制与 Kata proxykata-proxy进程进程数随容器数量线性增长启动延迟和资源占用都很高。注意这里的 Kata shim 指旧的kata-shim二进制不是2.x 时代的 shimv2 runtime 实例containerd-shim-kata-v2二进制两者名称相似但职责完全不同后文会进一步辨析。Kata 2.xshimv2 架构的诞生Kata 2.x 全面转向 containerd 定义的shimv2shim v2 API架构其核心思路记录在 架构文档的 shim v2 章节 中不再为每个容器多次调用 runtime 二进制而是运行一个常驻的 runtime 实例由它服务任意数量的容器容器管理器创建一个双向 socket 并传递给 shimv2 runtime双方通过gRPC 协议在同一个通道上发送 API 调用并返回结果每个 VM 对应一个 sandbox一个 VM 可以承载一个 Pod 内的多个容器从而天然支持 Kubernetes Pod 语义。这套设计同时解决了 1.x 的两大痛点| 问题 | Kata 1.x | Kata 2.x | |-|-|-| | Kata Runtime 进程调用次数 | 每个容器多次 | 每个 VM 1 次可承载任意数量容器 | | Kata shim 进程数 | 每个容器连接 1 个 | 0 | | Kata proxy 进程数若无 VSOCK | 1 | 0 |Notes:一个单独的 VM 可以承载一个或多个容器。Kata shim processes 一列指的是旧的 Kata shimkata-shim二进制不是新的 shimv2 runtime 实例containerd-shim-kata-v2二进制。从进程数量上看1.x 时代每创建一个容器至少涉及 runtime 多次调用 1 个 shim 1 个 proxy而 2.x 时代整个 Pod 只有一个常驻 shimv2 runtime 进程即使系统没有 VSOCK 也不再需要独立的kata-proxy进程。下面的示意图展示了 shimv2 引入后架构是如何被简化的仓库中的 shimv2 实现证据当前仓库中shimv2 runtime 的入口位于 src/runtime/cmd/containerd-shim-kata-v2/main.go。可以看到它通过shimapi.Run(types.DefaultKataRuntimeName, shim.New, shimConfig)将自身注册为 containerd 的 shimv2 插件types.DefaultKataRuntimeName即io.containerd.kata.v2——这正是 示例命令 中ctr run --runtime io.containerd.kata.v2所引用的 runtime 名称。runtime 服务端的核心实现在 src/runtime/pkg/containerd-shim-v2/service.go 中。从源码结构可以看到它实现了 shimv2 的生命周期 APICreate()service.go#L425创建容器/sandboxStart()service.go#L484启动容器Wait()service.go#L1097等待 workload 退出并回传退出状态Delete()service.go#L537删除容器并清理环境。同时该包还包含exec.go、create.go、start.go、delete.go、wait.go、metrics.go、stream.go等文件见 src/runtime/pkg/containerd-shim-v2共同构成一个完整的、与 OCI runtime 动词一一对应的 shimv2 服务。这印证了历史文档的结论shimv2 API 与 OCI runtime API 在生命周期拆分方式上高度相似只是从多次进程调用变成了单进程多方法调用。组件角色变迁kata-runtime的今昔理解两代架构差异的关键还在于认清kata-runtime的角色变化Kata 1.xkata-runtime就是主 runtime负责创建、启动、停止容器Kata 2.x主 runtime 变成了containerd-shim-kata-v2而kata-runtime退化为一个管理/运维工具程序提供一系列管理命令来查询和操作 Kata Containers 安装。从 src/runtime/cmd/kata-runtime 目录可以清楚看到它当前提供的命令集合execkata-exec.go允许管理员或开发者进入VM root 环境该环境对容器内的 workload 不可见。具体连接方式见 开发者指南的 debug console 章节。policy setkata-policy.go为指定 sandbox 设置 Kata Agent 访问策略从而通过策略启用/禁用 kata-agent API。用法为$ kata-runtime policy set policy.rego --sandbox-id XXXXXXXX从源码看该命令会校验 sandbox 是否存在katautils.VerifyContainerID、校验策略文件是否提供且存在然后通过 shim 客户端将策略文件内容以application/octet-stream的形式 PUT 到目标 sandboxkata-policy.go#L43-L68。policy.rego的生成方式可参考genpolicy工具文档策略本身的细节见 Policy Details。此外还有kata-check环境检查、kata-env打印 runtime 环境信息、factoryVM 模板/factory、metrics、volume、iptables等管理命令全部位于 src/runtime/cmd/kata-runtime 目录下。这些命令在 1.x 时代部分承担着 runtime 职责而在 2.x 架构中则纯粹是运维入口——这正是 架构文档 所强调的In Kata 1.x, this program also acted as the main runtime, but this is no longer required due to the improved shimv2 architecture.架构简化带来的收益综合上文从 1.x 到 2.x 的演进在实践层面带来三项直接收益状态处理问题被消除runtime 变成常驻进程VM 与容器的状态保存在进程内存与持久化目录中参见 persist 相关实现无需在多次进程调用之间反复搬运状态。性能显著改善不再为每个容器 spawn runtime、shim、proxy 进程也避免了无 VSOCK 环境下的额外代理开销。架构文档中的 进程概述表 展示了 2.x 下典型的进程布局主机侧只有containerd runtimecontainerd-shim-kata-v2virtiofsd hypervisorVM 内只有 agent容器环境内才是用户 workload。Kubernetes 集成更自然Kata 将一个 Kubelet Pod 表示为一个 VM见 Kubernetes 支持文档每个 Pod 只需一个 shimv2 runtime 进程而不是2N1个 shim且不需要独立的kata-proxy即使 VSOCK 不可用也是如此。CRI-O 会通过io.kubernetes.cri-o.ContainerType注解sandbox/container告知 runtime 是新建 VM 还是在已有 VM 内建容器见 架构文档的 OCI annotations 章节而在 Kubernetes 1.12 中更推荐直接通过RuntimeClass声明 Kata 运行时具体配置见 How to use Kata Containers and containerd。深入阅读历史篇是理解整个 架构文档 的起点后续可沿着以下线索继续深入背景概念background.md 解释 rootfs、容器镜像、OCI bundle 等前置知识环境模型架构文档的 Environments 章节 定义 Host、VM root、Container 三层环境的完整对照表Guest 资产guest-assets.md 说明 guest kernel 与 guest imagemini-OS/initrd的组成与启动链路网络与存储networking.md、storage.md跟踪与调试tracing.md、开发者指南。总结Kata Containers 从 1.x 到 2.x 的架构演进本质上是将进程级的多次调用替换为单实例常驻服务runtime 进程数从每容器多次降为每 VM 一次shim 与 proxy 进程从必需降为零。这一变化不仅解决了 VM 场景下的状态管理难题也大幅削减了进程启动开销并让 Kata 能以最简进程拓扑融入 Kubernetes 的 Pod 语义。kata-runtime从此退居管理工具之位而containerd-shim-kata-v2成为新架构的绝对核心——理解这段历史也就理解了当前仓库中两个二进制各自存在的原因。赞分享云原生容器运行时【免费下载链接】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 架构到 RuntimeClass 配置实战使用 Kata Containers 与 Containerd从 shimv2 架构到 RuntimeClass 配置实战 本文是《How to use Ka云原生容器运行时Kata Containers 与 Kubernetes 集成架构解析从 Kubelet/CRI 到 shimv2 的 Pod 即虚拟机实现Kata Containers 与 Kubernetes 集成架构解析从 Kubelet/CRI 到 shimv2 的 Pod 即虚拟机实现 Kubernet云原生容器运行时Kata Containers 4.0 架构深度解析基于 Rust 的异步单进程运行时Kata Containers 4.0 架构深度解析基于 Rust 的异步单进程运行时 Kata Containers 4.0 是一次跨越性的架构演进它用一云原生容器运行时创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考