企业官网建设流程全解析

• 云原生
• 容器运行时

本篇以 Kata Containers 官方入门文档docs/index.md为核心，完整覆盖其"如何工作"的架构原理、安装后系统的实际变更，以及通过 Kubernetes（CRI）与 containerd（ctr）两条路径拉起 Kata 容器的完整操作。结合 Rust shim 入口 与 shim 核心执行器 等源码，你将能够理解 Kata 如何用硬件虚拟化实现"像容器一样体验、像虚拟机一样隔离"，并能独立完成 runtime 类配置与容器启动验证。

一、Kata Containers 是什么：用轻量虚拟机承载容器工作负载

Kata Containers 是一个致力于构建安全容器运行时的开源社区：它构建"感觉和表现像标准 Linux 容器"的轻量级虚拟机（VM），但借助硬件虚拟化技术，把 VM 作为第二层防线，提供比传统容器更强的工作负载隔离。

一句话概括其定位：容器的使用体验（接口、生命周期管理方式不变）+ 虚拟机的隔离能力（独立 guest kernel、硬件虚拟化边界）。

二、它如何工作：runc 与 Kata 的启动流程对比

Kata 实现了 Open Containers Runtime Specification（OCI Runtime Spec），更具体地说，它实现了一个containerd shim，负责按 containerd 预期的接口管理容器生命周期。要理解 Kata 的差异，先看默认runc的启动方式：

当 containerd 收到创建容器的请求后，它拉取容器镜像，然后调用 runc shim（通常位于/usr/local/bin/containerd-shim-runc-v2）。runc 会创建一系列进程隔离资源——Linux 命名空间（网络、PID、挂载等）、seccomp 过滤器、Linux capability 缩减——再在这些资源内部拉起容器进程。该进程直接运行在宿主机内核上，隔离边界完全依赖宿主内核的 namespace/cgroup/seccomp 机制。

Kata 的启动方式则不同：

containerd 调用 Kata shim（即containerd-shim-kata-v2二进制），shim 创建一台轻量虚拟机；虚拟机内部运行Kata Agent，由 Agent 负责在 guest 内核中真正创建并运行容器进程。容器进程运行在 VM 内，使 guest kernel 与宿主机系统彻底隔离——这正是 Kata 实现隔离边界的基本原理：即使 guest 内的进程逃逸出容器边界，面对的也是一台隔离的 VM，而非宿主机内核。

两条流程的关键差异对比：

三、shim 的源码级实现：containerd-shim-kata-v2 做了什么

原文档指出 Kata 的核心是"实现一个 containerd shim"。仓库中 Rust 版 runtime 的 shim 组件位于 shim crate，其[[bin]]定义明确产出的二进制名就是containerd-shim-kata-v2（Cargo.toml）。Go 版 runtime 同样提供同名入口 containerd-shim-kata-v2。

从 shim 入口 main.rs 的源码结构看，shim 遵循 containerd shim v2 协议约定：

• 参数解析（parse_args）：支持-address（containerd 的 gRPC 地址）、-bundle（OCI bundle 路径）、-id（task id）、-namespace、-publish-binary等标准 shim v2 标志，另有start/delete子命令，以及供 containerd 2.x 使用的-info（输出 protobuf 格式的 RuntimeInfo）。
• 动作分发：Action::Run会先调用setup_mnt()——通过unshare(CLONE_NEWNS)获得私有 mount 命名空间，并把根文件系统设置为 slave 再设为 shared，保证 shim 的挂载操作不会污染宿主机全局挂载传播；随后构建 tokio 多线程运行时（默认 2 个 worker 线程，可用环境变量TOKIO_RUNTIME_WORKER_THREADS调整）并阻塞执行shim.run()。
• 信号处理：入口main()显式忽略SIGTERM——当使用 systemd cgroup driver 且启用 sandbox cgroup only 时，shim 处于 systemd unit 之下，unit 停止时 systemd 发 SIGTERM；shim 必须先完成清理工作（Kata 默认在 300 秒窗口内完成，超时后 systemd 才发SIGKILL）。
• 通信寻址：ShimExecutor::socket_address 对address/namespace/sandbox_id做 SHA256 生成 socket 路径unix:///run/containerd/s/<hash>，与 containerd 侧的寻址算法保持一致，这是 shim 与 containerd 建立 gRPC 通信的前提；同时它负责把address、shim.pid写回 bundle 目录，供后续start/delete定位同一沙箱。

也就是说，ctr/containerd 看到的"一个容器"，在 Kata 内部实际展开为"shim 进程 → hypervisor 启动 VM → guest 内 Kata Agent → 容器进程"这条调用链。

四、安装后的系统变更：containerd 配置如何接入 Kata

Kata 安装到系统后，会铺设一组 artifacts，并修改 containerd 的配置文件。/etc/containerd/config.toml会被加上 import 行：

title="/etc/containerd/config.toml" imports = ["/opt/kata/containerd/config.d/kata-deploy.toml"]

被导入的/opt/kata/containerd/config.d/kata-deploy.toml中包含各类 Kata runtime flavor 的定义。其中"原生 CPU"运行时（kata-deploy 生成的默认 QEMU 运行时）配置如下：

title="/opt/kata/containerd/config.d/kata-deploy.toml" [plugins."io.containerd.cri.v1.runtime".containerd.runtimes.kata-qemu] runtime_type = "io.containerd.kata-qemu.v2" runtime_path = "/opt/kata/bin/containerd-shim-kata-v2" privileged_without_host_devices = true pod_annotations = ["io.katacontainers.*"] [plugins."io.containerd.cri.v1.runtime".containerd.runtimes.kata-qemu.options] ConfigPath = "/opt/kata/share/defaults/kata-containers/configuration-qemu.toml"

逐项说明其含义与取值来源：

kata-deploy 组件按 hypervisor 类型生成不同 flavor（qemu、fc、clh 等），其 containerd 配置渲染逻辑可参见 kata-deploy 的 toml 生成与测试，测试用例中验证了runtime_type = "io.containerd.kata-qemu.v2"与io.containerd.kata-fc.v2等多套 runtime 段落的生成。

五、实战一：通过 Kubernetes 拉起 Kata Pod

由于 containerd 的 CRI 已感知 Kata 运行时，Kubernetes 用户只需在 Pod 中声明runtimeClassName即可让调度落到 Kata 上：

apiVersion: v1 kind: Pod metadata: name: test spec: runtimeClassName: kata-qemu containers: - name: test image: "quay.io/libpod/ubuntu:latest" command: ["/bin/bash", "-c"] args: ["echo hello"]

其中runtimeClassName: kata-qemu必须与第四节kata-deploy.toml中注册的 runtime 段名一致。CNI、调度器看到的仍是一个普通 Pod，但 kubelet → containerd CRI → Kata shim 的实际执行路径上，容器进程已经运行在一台带独立 guest kernel 的 VM 里。pod_annotations中声明的io.katacontainers.*可在此基础上按需覆盖 Kata 参数（完整 annotation 列表参见 docs/pod-annotations.md）。

六、实战二：绕过 CRI，用 ctr 直接向 containerd 提交 Kata 容器

不经过 Kubernetes，也可以直接向 containerd 发请求运行 Kata 容器：

$ ctr image pull quay.io/libpod/ubuntu:latest $ ctr run --runtime "io.containerd.kata.v2" --runtime-config-path /opt/kata/share/defaults/kata-containers/configuration-qemu.toml --rm -t "quay.io/libpod/ubuntu:latest" foo sh # echo hello hello

有两个官方提示必须理解，否则这条命令基本跑不通：

1. ctr不感知 CRI 配置。ctr不会读取/etc/containerd/config.toml中 CRI 注册的运行时（如kata-qemu段），因此必须用--runtime-config-path显式指定 Kata 运行时配置文件路径。
2. --runtime值会被转换为具体二进制名。io.containerd.kata.v2这类 runtime type 会被 containerd 转换为待查找的 shim 二进制名称，并在PATH中搜索。因此containerd-shim-kata-v2必须位于PATH可达的位置（默认安装路径/opt/kata/bin需已加入PATH，或使用runtime_path显式配置）。

七、可继续深入验证的仓库位置

• Go runtime 的 virtcontainers 层：VM 启动、endpoint 创建等核心逻辑位于 src/runtime/virtcontainers，sandbox.go/vm.go定义了沙箱与 VM 的生命周期。
• Rust runtime 的 hypervisor 抽象：src/runtime-rs/crates/hypervisor 实现了 QEMU、Firecracker、Dragonball 等 hypervisor 的统一起停接口。
• guest 内的 Kata Agent：src/agent 是运行在 VM 内的代理，负责容器创建、挂载、设备与网络配置，它是上文中"VM 内部由 Agent 拉起容器进程"的实现方。
• 端到端集成测试：tests/integration/cri-containerd 提供了经 CRI/containerd 运行 Kata 的集成脚本，可作为本文第五、六节操作链路的回归验证参考。

小结

Kata Containers 的隔离本质在于把容器进程从"宿主内核上的命名空间隔离"升级为"独立 guest kernel + 硬件虚拟化 VM"，而其工程上的关键一步是提供一个符合 containerd shim v2 协议的containerd-shim-kata-v2，使 CRI/Kubernetes 生态无需改动接入方式即可切换到 VM 隔离。掌握kata-deploy.toml中runtime_type/runtime_path/ConfigPath三者的关系，理解ctr与 CRI 在运行时发现机制上的差异，就能在裸机和 Kubernetes 两种场景下正确配置并验证 Kata 容器。

• 云原生
• 容器运行时