在云原生基础设施已经高度成熟的 2026 年，当我们回望容器技术的发展历程，Docker 和 RKT（Rocket）的较量依然是一段极具启发性的技术往事。作为在这个行业摸爬滚打多年的开发者，我们见证了 Docker 如何通过“一站式”体验统一了世界，也目睹了 RKT 如何以极其严谨的“默认安全”哲学影响了一代架构设计。虽然 RKT 的维护状态已不如往昔，但它所代表的模块化、无守护进程理念在现代容器运行时中得到了重生。今天，让我们像技术侦探一样，深入解构这两种技术的核心差异，并结合 2026 年的先进开发理念，探讨它们如何塑造了我们现在的工程实践。
目录
1. 深入理解 RKT (Rocket)：不仅是运行时，更是哲学
1.1 什么是 RKT？
RKT（发音为 "rocket"）曾经是 CoreOS（现 RedHat 的一部分）推出的拳头产品。与我们熟悉的 Docker 不同，RKT 从设计的第一天起就不是一个“平台”，而是一个纯粹的“容器运行时”。它的核心设计哲学深受 Unix “做一件事并做好”的影响：专注于安全地执行容器，而不构建庞大的周边生态。
为什么在 2026 年我们还要讨论 RKT？
虽然你可能更多听到的是 Podman 或 Containerd，但 RKT 的影子无处不在。例如，RKT 首创的 Pod 概念（一组共享网络命名空间的容器）直接被 Kubernetes 采纳；它的 无守护进程 架构成为了 Podman 的核心设计基石。理解 RKT，实际上是在理解现代容器运行时安全演进的历史。
1.2 RKT 的核心特性：模块化与安全
RKT 最迷人的地方在于其“Stage 1”架构。不同于 Docker 将所有逻辑塞进一个巨大的守护进程，RKT 启动容器时，首先会加载一个极简的“Stage 1”用户空间。
让我们通过一个具体的代码示例来看看 RKT 的工作流。
实战示例 1：运行一个经过签名验证的 Nginx 容器
假设我们在一个对安全性要求极高的金融级生产环境中，我们需要确保运行的镜像未被篡改。RKT 原生支持镜像签名验证。
# 1. 准备环境：下载信任根文件（模拟环境）
echo "Preparing trusted keys..."
# 2. 使用 rkt 运行容器
# --net=host: 使用宿主机网络栈，减少 NAT 性能损耗
# --insecure-options=image: 仅用于演示跳过在线签名验证（生产环境务必开启全链路验证）
# docker://nginx: RKT 能够直接识别并运行 Docker 镜像格式
sudo rkt run --net=host --insecure-options=image docker://nginx
# 代码原理解析：
# 当你输入这个命令时，并没有一个名为 dockerd 的后台进程在监听。
# rkt 二进制文件直接调用 Linux 内核接口（Clone, Unshare, Setns）来创建命名空间。
# 这意味着攻击者无法通过攻击一个长期存在的守护进程来控制宿主机。
2026 年的视角：无守护进程的胜利
在当时，Docker 的守护进程架构常常被诟病为“上帝进程”。如果 Docker 守护进程挂掉，所有容器管理都会受影响。而在今天，当我们使用 Podman 或 rootless Podman 时，我们实际上是在享受 RKT 当年倡导的架构红利：进程直接管理，没有中间商赚差价。
2. 深入理解 Docker：构建云原生的通用语言
2.1 Docker 的生态统治力
Docker 的成功不在于它是最安全的，而在于它定义了“分发标准”。Docker 引入了 镜像分层 的概念，彻底改变了软件交付的方式。在 2026 年，尽管底层运行时已经高度碎片化，但 Docker 镜像格式依然是“通货”。
2.2 Docker 的实战体验
对于应用开发者来说，Docker 提供的开发者体验（DX）依然是无可匹敌的。特别是当我们结合 Vibe Coding（氛围编程） 和 AI 辅助开发 时，Docker 的标准化接口让 AI 能够更容易地理解我们的构建意图。
实战示例 2：构建一个现代化的 Python 微服务
让我们看一个符合 2026 年开发标准的 Dockerfile。我们不仅要运行代码，还要确保非 Root 用户运行（遵循安全左移原则），并优化层缓存以配合 AI 辅助构建。
# 引入极简基础镜像，减少攻击面
FROM python:3.13-slim as builder
# 设置环境变量，防止 Python 生成 .pyc 文件并让日志直接输出到 stdout
ENV PYTHONDONTWRITEBYTECODE=1 \
PYTHONUNBUFFERED=1
# 模拟现代工作流：利用虚拟环境隔离依赖
WORKDIR /app
# 在实际项目中，我们通常先复制依赖文件以利用 Docker 缓存
COPY requirements.txt .
# 安装依赖
# --no-cache-dir 确保镜像体积最小化
RUN pip install --no-cache-dir -r requirements.txt
# 阶段二：运行环境
# 创建非 root 用户 ‘appuser‘，这是现代容器安全的关键一步
FROM python:3.13-slim
WORKDIR /app
# 从构建阶段复制依赖
COPY --from=builder /usr/local/lib/python3.13/site-packages /usr/local/lib/python3.13/site-packages
COPY --from=builder /usr/local/bin /usr/local/bin
# 复制应用代码
COPY . .
# 切换到非 root 用户
# 这一步至关重要，它防止了容器逃逸后直接获得宿主机 root 权限
USER appuser
# 健康检查：2026 年的标准配置，让 K8s 或 Swarm 知道服务是否存活
HEALTHCHECK --interval=30s --timeout=3s \
CMD curl -f http://localhost:5000/health || exit 1
# 执行入口点
CMD ["python", "app.py"]
2.3 Docker 的双刃剑：守护进程的安全困境
尽管 Docker 引入了 Rootless 模式，但在许多传统架构中，Docker Daemon 依然以 Root 身份运行。这意味着如果你将宿主机的 /var/run/docker.sock 挂载进容器（例如为了让 Jenkins 构建 Docker 镜像），你实际上给了该容器控制整个宿主机的权限。
常见的错误场景（2026 年依然常见）：
开发者为了方便，在 CI/CD 流程中直接挂载 Docker Socket。
# 危险操作示例！
docker run -v /var/run/docker.sock:/var/run/docker.sock my-ci-tool build
这种做法的隐患：一旦 CI 工具所在的容器被攻破，攻击者就可以发送指令给 Docker Daemon，在宿主机上启动任意恶意容器，甚至挂载宿主机的根目录。
解决方案：使用 Kaniko 或 Buildah 等不需要 Docker Daemon 的构建工具，这正是 RKT 理念在现代 CI/CD 中的体现：不要依赖一个庞大的守护进程来做构建这件事。
3. RKT 与 Docker 的核心维度深度对比
在 2026 年的技术选型中，我们不再简单地说“RKT 好”还是“Docker 好”，而是根据具体的场景需求来权衡。让我们从几个关键维度进行对比。
3.1 架构哲学：Monolith vs Micro-kernel
- Docker (Monolith)：倾向于提供一个庞大的平台，包含构建、运行、编排、网络、卷管理。这种“大礼包”模式在早期极大地降低了容器技术的门槛，但也带来了沉重的技术债务。
- RKT (Micro-kernel)：只负责运行容器。网络由 CNI 插件处理，镜像由其他工具拉取。这种可组合性 正是 Kubernetes 之所以流行的原因。
3.2 安全性：Default Safe vs Secure by Config
这是两者最大的区别，也是 RKT 至今仍被提及的原因。
对比点 1：Root 权限
- Docker: 早期版本默认以 Root 运行容器进程。虽然现在可以通过
userns-remap配置，但配置复杂，且很多旧镜像不兼容（因为镜像里习惯了 Root）。 - RKT: 天生支持非 Root 运行。它在设计中尽量避免直接使用 Root 权限，而是利用更细粒度的 Linux Capabilities。
对比点 2：镜像验证
- Docker: 依赖镜像仓库（如 Docker Hub）的 HTTPS 传输。虽然现在有 Content Trust，但并非所有开发者都开启。
- RKT: 强制执行镜像签名验证。它不信任网络传输，只信任本地导入的密钥。这种零信任 的网络架构在当时是超前的。
3.3 Pod 概念的起源
你可能不知道，Kubernetes 中的 Pod 概念最早就是 RKT 提出来的。在 Docker 中，早期的概念是单个容器。要连接多个容器（比如 Web 容器和 Log 容器），你需要用 --link 或者复杂的网络配置。
而 RKT 认为：“应用不是一个容器，而是一组协同工作的容器集合。”
代码示例 3：模拟 RKT 的 Pod 清单
// 这是一个概念性的 RKT Pod 清单
// 它展示了如何在单一隔离单元中运行 Nginx 和其日志收集器
{
"acVersion": "0.8.1",
"acKind": "PodManifest",
"apps": [
{
"name": "nginx",
"image": { "id": "docker://nginx" },
"annotations": [
{ "name": "app", "value": "web" }
]
},
{
"name": "log-collector",
"image": { "id": "docker://logstash" },
"annotations": [
{ "name": "app", "value": "logging" }
]
}
]
}
在这个结构中，Nginx 和 LogCollector 共享同一个网络命名空间。它们可以通过 localhost 直接通信。这种设计后来被 Kubernetes 直接吸收，成为了我们今天部署微服务的标准方式。
4. 2026 年的技术展望：当容器遇上 AI 与边缘计算
现在，让我们把目光投向未来。在 2026 年，我们不仅是在比较 RKT 和 Docker，更是在探讨如何在边缘计算和AI 原生应用中利用它们的遗产。
4.1 边缘计算与容器体积
当我们把应用部署到资源受限的边缘设备（如智能网关或自动驾驶汽车）时，RKT 的理念变得尤为重要。
- Docker 带来的全套工具链（CLI, Daemon, API）对于边缘设备来说太重了。
- RKT 的遗产：我们倾向于使用轻量级运行时，如 CRI-O 或 kata Containers（基于虚拟机的隔离）。这些工具继承了 RKT 的“小即是美”的理念。
实战建议：如果你正在开发物联网软件，不要安装完整的 Docker Engine。考虑使用 containerd 的精简版，或者直接使用嵌入式容器运行时。
4.2 AI 辅助开发与标准化
在 Agentic AI 时代，我们的 IDE（如 Cursor 或 Windsurf）经常自动生成构建脚本。
- Docker 的优势：由于 Dockerfile 是事实标准，AI 模型有海量的训练数据。当我们要求 AI “把这个 Node.js 应用容器化”时，它几乎总是生成 Dockerfile。
- RKT 的启示：虽然 RKT 的格式对 AI 来说较少见，但它的“声明式配置”思想影响了 Kubernetes YAML 的生成。未来，随着 AI 开始直接操作基础设施，像 RKT 这样显式声明意图、无隐式副作用的设计，更容易被 AI 代理理解和验证。
5. 我们的最佳实践与总结
在我们最近的一个大型重构项目中，我们需要将遗留的单体应用迁移到微服务架构，并满足银行级别的安全审计要求。这是我们做出的决策：
- 开发环境：继续使用 Docker。因为开发人员需要快速迭代，利用 Docker Compose 可以在本地完美模拟微服务环境。而且，GitHub Copilot 对 Docker 支持最好。
- 构建阶段：放弃了 Docker 守护进程构建，转而使用 Buildah。这与 RKT 的理念一致：不需要 Root 权限，不需要守护进程，构建出来的镜像兼容 OCI 标准。
- 生产运行时：在生产集群中，底层的运行时不再是 Docker Engine，而是 containerd。它继承了 RKT 的专注性，只负责运行容器，更加稳定高效。
最终建议
- 如果你是一名刚入门的开发者，请从 Docker 开始。它是行业标准，资料最丰富，也是你接触云原生的敲门砖。
- 如果你是一名高级架构师或安全工程师，请务必研究 RKT 的设计理念。理解它为什么反对守护进程，为什么坚持 Pod 概念，这将帮助你理解 Kubernetes 的本质，并让你在处理高安全级别的场景时有更深入的思考。
容器技术已经从“简单的打包工具”进化为“分布式计算的操作系统”。在这个演进过程中，Docker 铺平了道路，而 RKT 树立了路标。让我们感谢这两者的共存与竞争，正是它们推动了技术的边界不断向前。