rkt 容器引擎全解析：pod 原生架构、安全特性与标准兼容性-平芜编程栈

容器运行时
云原生
网络

【免费下载链接】rkt

[Project ended] rkt is a pod-native container engine for Linux. It is composable, secure, and built on standards.

项目地址：https://gitcode.com/gh_mirrors/rk/rkt

rkt（发音同 "rocket"）是 Linux 平台上一款 pod 原生（pod-native）的容器引擎命令行工具，以"安全优先（secure-by-default）"为设计原则，支持 SELinux、TPM 度量与硬件隔离的 KVM 虚拟机运行，并面向 systemd、Kubernetes、Nomad 等编排与初始化系统提供一流集成。本文以仓库 README.md 为主线，结合架构文档与仓库源码，完整剖析 rkt 的核心理念、pod 模型、阶段式执行架构、安全机制、镜像体系及实操上手路径，帮助你掌握其设计思想与工程实现。

重要声明：该开源项目已宣布结束（End of project），所有开发与维护活动已停止（见 README.md 顶部的警示）。仓库虽已归档，但代码与文档仍完整保留，可用于学习容器引擎设计与 App Container 规范实现。rkt v1.x 系列承诺提供命令行界面与磁盘数据结构层面的稳定性。

一、rkt 是什么：pod 原生容器引擎

rkt 是一个用于在 Linux 上运行应用容器的 CLI 工具，其设计目标可归纳为四个关键词：

Pod 原生（Pod-native）：rkt 的基本执行单元是 pod。pod 将资源与用户应用链接在一个自包含环境中，对应 Kubernetes 中的 pod 概念。见 app-container 文档中对 pod 的完整定义。
安全性（Security）：坚持"安全优先"原则，内置 SELinux、TPM 度量、硬件隔离的 KVM 虚拟机等安全能力。
可组合性（Composability）：与初始化系统（如 systemd、upstart）及集群编排工具（如 Kubernetes、Nomad）提供一流的集成，并支持可替换的执行引擎。
开放标准与兼容性：实现 appc 规范，支持 CNI（Container Networking Interface）规范，并能运行 Docker 镜像与 OCI 镜像。

项目定位与现状

rkt v1.x 系列对外承诺命令行用户界面（CLI）与磁盘数据结构（on-disk data structure）的稳定性，任何重大变更都会明确沟通，并对退役特性执行正式弃用流程。项目路线图详见 ROADMAP.md。

二、核心概念：ACI 镜像与 pod 执行单元

rkt 的原生镜像格式与运行时环境均由 appc（App Container）规范定义，rkt 是其参考实现。这是理解 rkt 一切设计的基础，详见 app-container 文档。

ACI：应用容器镜像

ACI（Application Container Image）是 appc 定义的镜像格式，构成非常简单：

一个 rootfs 打包的 tarball，内含执行应用所需的全部文件；
一个 Image Manifest（镜像清单），声明默认执行参数、默认资源约束等元数据。

镜像可以通过acbuild、actool或goaci等工具构建。Docker 镜像可经docker2aci转换，但 rkt 在运行时也会自动完成该转换。镜像中定义的大部分参数都能在运行时被 rkt 覆盖——例如rkt run允许用户为镜像提供自定义的 exec 参数。

Pod：基本执行单元

pod 是一个或多个应用镜像（ACI）的分组，外加可选的 pod 级元数据。例如，资源约束可以施加在 pod 级别，成为 pod 内所有应用的"外边界"。pod 内的镜像共享执行上下文，包括网络。rkt 中的 pod 与 Kubernetes 中定义的 pod 概念一致。

验证 rkt 作为 appc 实现

rkt 实现了 appc 规范的两个运行时组件：Application Container Executor（ACE）与Metadata Service，并直接使用上游 appc/spec 仓库的 schema 与代码来操作 ACI、处理镜像与 pod 清单、执行镜像发现。

使用官方验证 ACI 可验证 ACE 实现：

# rkt metadata-service & # 确保 metadata service 正在运行 # rkt --insecure-options=image run \ --mds-register \ --volume=database,kind=host,source=/tmp \ https://github.com/appc/spec/releases/download/v0.8.11/ace-validator-main.aci \ https://github.com/appc/spec/releases/download/v0.8.11/ace-validator-sidekick.aci

三、无守护进程的阶段式执行架构

rkt 的核心架构特征是：主接口是一个命令行工具rkt，不需要常驻后台守护进程。这一设计带来两个关键优势（见架构文档）：

rkt 可原地升级而不影响正在运行的应用容器；
不同操作的权限级别可以分离。

所有 rkt 状态都通过文件系统传递，并使用文件锁（file-locking）来保证并发调用rkt命令时的协作与互斥。

三个执行阶段

1. invoking process -> stage0: 调用进程通过自身机制调用 rkt 二进制（stage0） 2. stage0 -> stage1: 通过 exec(3) 将 stage0 替换为 stage1 入口点 3. stage1 -> stage2: stage1 入口点调用 stage2 应用可执行文件

三个阶段的具体职责如下：

Stage 0：即rkt二进制本身。负责拉取指定 ACI（包括--stage1-{url,path,name,hash,from-dir}指定的 stage1 ACI）、生成 pod UUID、生成 pod manifest、创建 pod 文件系统、设置 stage1/stage2 目录、解包 stage1 ACI 到 pod 文件系统、解包 ACI 并复制每个应用到 stage2 目录。
Stage 1：用户信任的二进制，负责读取镜像与 pod 清单、搭建隔离环境（称为 "stage1 flavor"）。
Stage 2：应用实际运行的环境，由 stage1 启动。

三种 stage1 flavor

Flavor	隔离机制	适用场景
fly	仅 chroot	最简单的单进程环境
systemd/nspawn	cgroup + namespace，基于 systemd 与 systemd-nspawn	默认的完整隔离环境
kvm	硬件虚拟化虚拟机	强隔离场景，详见 KVM 文档

以rkt run app1.aci app2.aci为例，stage0 生成的 pod 文件系统结构为：

/pod /stage1 /stage1/manifest /stage1/rootfs/init /stage1/rootfs/opt /stage1/rootfs/opt/stage2/${app1-name} /stage1/rootfs/opt/stage2/${app2-name}

其中pod是 pod manifest 文件，stage1是 stage1 ACI 的安全读写副本，stage1/rootfs/init是实际执行的 stage1 二进制（路径依 stage1 ACI 的coreos.com/rkt/stage1/run注解而定），stage1/rootfs/opt/stage2是解包后的 ACI 副本。stage0 最终以exec调用/stage1/rootfs/init，并将当前工作目录设为新文件系统的根。

systemd/nspawn 类 flavor 的执行链是：ld-linux-*.so.*（加载器）→systemd-nspawn（--boot参数启动容器）→systemd（容器内 supervisor，fork+exec启动应用进程）。在架构文档中可以查看对应的进程树实例。

不可变与可变的 pod 运行时

rkt 支持两种 pod 运行时环境：

不可变（immutable）：默认模式，即所有rkt prepare/rkt run创建的 pod。创建后无法修改。
可变（mutable）：实验特性，允许在 pod 启动后增删、启停应用。目前仅存在于实验性的rkt app子命令家族中，详见 pod 生命周期文档。

两种环境都由容器内 systemd 基于自定义依赖图监督，其服务单元行为差异可参阅架构文档中的对照表。

四、安全特性全景

rkt 以"安全优先"为默认原则，并内置了多层安全机制。以下是 README 强调的三项核心安全特性及其实现细节。

SELinux 支持

rkt 使用 SELinux SVirt 机制运行容器。启动时，rkt 尝试读取/etc/selinux/(policy)/contexts/lxc_contexts；若文件不存在则不做任何 SELinux 转换；若存在，则为每个实例生成独立的 context——所有实例挂载使用lxc_contexts中定义的文件 context 创建，实例进程运行在派生自其中进程 context 的上下文。处于这些上下文中的进程即使以相同用户运行，也无法与其他实例上下文中的进程或文件交互。典型的lxc_contexts示例见 selinux 文档。

TPM 可信度量

通过./configure --enable-tpm=yes构建可启用 TPM 功能。rkt 通过 go-tspi 项目的tpmd可执行程序访问 TPM，该守护进程监听 12041 端口。度量事件记录到PCR 15，事件类型为0x1000，每个事件包含：

容器根文件系统哈希；
容器清单数据内容的哈希；
传递给stage1的参数哈希。

这为节点上执行的容器（含其配置）提供了密码学上可验证的审计日志。详见 TPM 文档。

KVM 硬件隔离

rkt 可选用 KVM 虚拟机（LKVM 或 QEMU）作为 stage1，让 pod 运行在拥有独立操作系统内核、受虚拟机监控器隔离的虚拟机中，而非仅用 cgroups 和 namespaces 创建容器。前提是硬件支持虚拟化且内核已加载 KVM 模块：

sudo rkt run --debug --insecure-options=image --stage1-name=coreos.com/rkt/stage1-kvm:1.30.0 docker://redis

KVM stage1 的内存分配规则为"各应用所需内存之和 + 系统额外 128MB"；若某应用未指定内存则默认按 128MB 计算。还可通过环境变量RKT_HYPERVISOR_EXTRA_KERNEL_PARAMS传递额外内核命令行参数。构建 KVM stage1 的命令为：

$ ./autogen.sh && ./configure --with-stage1-flavors=kvm --with-stage1-kvm-hypervisors=lkvm,qemu && make

详细内容见 KVM stage1 文档。

通用安全最佳实践

security 文档给出了系统性的运行安全建议：

不要让应用以 root 运行：使用镜像中的 user/group 字段或运行时的--user、--groupCLI 参数；
非必要不关闭安全特性：除非确实需要，否则不要使用--insecure-options=标志；
尽量收缩 capabilities：只授予应用真正需要的权限，见 capabilities 指南；
不要直接禁用 seccomp：默认 seccomp 配置文件可能过严，应微调而非禁用，见 seccomp 指南；
尽可能使用 user namespaces（若不受其当前限制影响）；
不要使用 host networking，否则容器内应用可访问主机网络接口并连接主机上监听的任意应用（含抽象 Unix socket）。

卷（volume）使用同样有专门建议：优先只读卷；Linux v4.2 及更早版本上避免共享目录（防止主机工具将文件移出目录造成整个主机文件系统暴露）；尽量共享完整文件系统而非文件系统中的单个目录；通常不建议向容器共享主机设备，如需共享可参考 block devices 文档。

此外，sd_notify 机制允许 pod 内 systemd 通知主机上 systemd pod 已就绪，涉及跨命名空间文件描述符传递，部署时也需留意 security 文档中的相关说明。

五、镜像生命周期：拉取、存储与渲染

rkt prepare与rkt run的第一步是拉取命令行中请求的全部镜像，并准备含应用内容的 stage2 目录，整个过程分为三个逻辑阶段（见架构文档）：

Fetch（拉取）：根据提供的镜像参数（镜像字符串/哈希/HTTPS URL/本地文件等）拉取镜像；
Store（存储）：将拉取的镜像保存到本地 Image Store，作为已拉取镜像及相关数据的缓存；
Render（渲染）：渲染器从 store 取出所需镜像并渲染为可直接用作 stage2 内容的形态。

渲染有两种方式：直接在 pod 内渲染 stage1-2 内容（占用更多磁盘、准备时间更长），或使用 treestore——渲染镜像的缓存，配合 overlayfs 将 treestore 渲染镜像作为 lower 目录挂载。treestore 缓存机制使 pod 与 treestore 之间形成硬连接。

rkt 目前内部实现 appc 格式，并会从其他容器镜像格式做转换以便兼容。未来（如 OCI 镜像规范支持）可沿用相同的拉取-存储-渲染基本框架，详见 OCI 提案文档与镜像拉取行为文档。

六、快速上手：构建并运行一个应用

入门指南提供了一个从零构建 Go 应用并用 rkt 运行的端到端示例。

编写并静态编译应用

package main import ( "log" "net/http" ) func main() { http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) { log.Printf("request from %v\n", r.RemoteAddr) w.Write([]byte("hello\n")) }) log.Fatal(http.ListenAndServe(":5000", nil)) }

使用静态链接编译（Go 1.9 及以上）：

$ CGO_ENABLED=0 go build -ldflags '-extldflags "-static"'

用file与ldd验证产物确为静态链接：

$ file hello hello: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, not stripped $ ldd hello not a dynamic executable

用 acbuild 构建 ACI 镜像

acbuild begin acbuild set-name example.com/hello acbuild copy hello /bin/hello acbuild set-exec /bin/hello acbuild port add www tcp 5000 acbuild label add version 0.0.1 acbuild label add arch amd64 acbuild label add os linux acbuild annotation add authors "Carly Container <carly@example.com>" acbuild write hello-0.0.1-linux-amd64.aci acbuild end

运行并验证

# rkt --insecure-options=image run hello-0.0.1-linux-amd64.aci

注意：默认情况下 rkt 期望镜像经过签名，因此本例需要--insecure-options=image。签名与验证的完整流程见签名与验证指南。

用rkt list查看容器被分配的 IP：

# rkt list UUID APP IMAGE NAME STATE NETWORKS 885876b0 hello example.com/hello:0.0.1 running default:ip4=172.16.28.2

然后curl该 IP 的 5000 端口：

$ curl 172.16.28.2:5000 hello

要停止容器，连续输入三个转义字符（^]^]^]，US 键盘上即Ctrl-]）。如需以守护进程方式运行 rkt，参见 run 子命令文档。

七、CLI 与子命令体系

rkt 的命令行基于 cobra 框架实现（见 rkt/run.go 中cmdRun的定义）。以run子命令为例，其使用格式为：

rkt run [--volume=name,kind=host,...] [--mount volume=VOL,target=PATH] IMAGE [-- image-args...[---]]...

镜像参数按"哈希 → 本地文件 → URL"顺序检查，首个匹配生效；
--volume通过 kind 绑定主机卷，--mount将卷绑定到镜像根内的目标路径；--mount是位置敏感的——出现在任何镜像之前则应用于所有镜像，出现在某个镜像之后则只作用于紧邻的前一个镜像，per-app 挂载优先于同名全局挂载；
单个--可抑制 rkt run 对后续参数的解析，这些参数将追加到紧邻前一个镜像应用的 exec 参数中；以单独---结束镜像参数以恢复参数解析。

从源码结构看，CLI 由 rkt/main.go 聚合run、prepare、list、gc、stop、status、fetch、image、app等众多子命令，每个子命令对应一个独立实现文件（如 rkt/run.go、rkt/list.go、rkt/fetch.go 等）。完整命令列表可参考 commands 文档。

八、生态集成与相关资料导航

systemd 集成：rkt 专为一等公民的 init 系统集成而设计，详见 using-rkt-with-systemd，支持 socket activation 与 socket-proxyd 特性；
Kubernetes 与 Nomad：作为容器运行时接入集群编排，见 Kubernetes 集成与 Nomad 集成；
网络：基于 CNI 规范，见 networking 概览与网络覆盖与默认值；
发行版支持：distributions 文档列出各 Linux 发行版对 rkt 的支持情况；
排障：遇到问题先查阅 troubleshooting 文档；
开发与构建：hacking 指南介绍如何编译并参与 rkt 开发，stage1 实现者指南面向希望实现自定义 stage1 的开发者；
集成方与生产用户：见 integrations 与 production-users。

九、许可证与安全披露

除特别注明外，rkt 仓库所有代码采用 Apache 2.0 许可证。部分代码源自其他采用不同许可证的项目，相应信息见对应源文件头部。

若发现 rkt 的安全漏洞，请勿直接提交 GitHub issue，而应发送邮件至 security@coreos.com，附上完整细节与复现步骤。

结语

rkt 是容器技术演进史中一个重要的工程样本：它以 pod 为执行单元、以无守护进程的阶段式架构实现可组合与可升级性，以 appc/CNI 等开放标准保证互操作，并将"安全优先"落实到 SELinux、TPM、KVM、user namespaces 等层层机制。虽然项目已宣布停止维护，但其文档与源码依然是学习 Linux 容器引擎设计、研究 pod 生命周期与 stage 化执行架构的优质参考。对于想要在历史环境中理解或迁移 rkt 部署的读者，建议从 getting-started-guide 入手，再结合 architecture 深入内核。