rkt 集成生态全景：容器编排、镜像分发、安全与监控的一体化对接指南

• 容器运行时
• 云原生
• 网络

rkt 是一个面向 Linux 的 pod 原生容器引擎，强调组合性（composable）、安全性（secure）与标准化（built on standards）。本指南围绕 Documentation/integrations.md 记录的官方集成清单，逐一展开 rkt 与 Kubernetes、Mesos、Nomad 等编排平台，dgr、Mulled、Quay.io 等镜像构建与分发工具，SELinux、cAdvisor 等安全与监控组件，以及主流 Linux 发行版生态的对接方式与底层实现。读完本文，你将掌握 rkt 在真实生产环境中的接入路径、关键配置参数，以及这些集成背后由 rkt API Service 与 App Container 标准 提供的技术支撑。

集成总览：rkt 生态版图

rkt 的设计目标之一是与既有基础设施友好协作，而非自成孤岛。根据官方集成清单，rkt 的集成对象可分为四类：

以下各节将分别深入每类集成，并结合仓库源码说明其底层工作方式。

与 Kubernetes 集成（rktnetes）

Kubernetes 默认使用 Docker 作为容器运行时，但自 1.3 版本起正式宣布支持 rkt 作为替代运行时。这一集成让 Kubernetes 集群可以直接利用 rkt 的 pod 原生模型与安全特性——在 rkt 中一个 pod 天然对应一组共享资源与命名空间的容器，这与 Kubernetes 的 pod 概念高度契合。

在 kubelet 层配置 rkt 运行时

容器运行时是在每个节点上的kubelet代理层配置的。kubelet 提供以下与 rkt 相关的启动参数：

• --container-runtime=rkt：将节点的容器运行时设为 rkt；
• --rkt-api-endpoint=HOST:PORT：指定 rkt API Service 的地址，默认值为localhost:15441（与rkt api-service的默认监听地址一致）；
• --rkt-path=PATH_TO_RKT_BINARY：指定 rkt 二进制的路径，留空时按$PATH查找；
• --rkt-stage1-image=STAGE1_NAME：指定 stage1 镜像名，例如coreos.com/rkt/stage1-coreos，未设置时使用默认的coreos.com/rkt/stage1-coreos。

其中--rkt-api-endpoint指向的正是 rkt 的 API Service：kubelet 通过该 gRPC 服务查询节点上的 pod 与镜像状态，进而完成容器生命周期管理。API Service 默认只读、无需 root 权限，并且是可选组件——它的启动、停止或崩溃都不会影响任何正在运行的 pod 或镜像，这一设计保证了 Kubernetes 集群中该组件故障时不影响业务容器。

通过部署工具快速搭建 rktnetes 集群

仓库文档Documentation/using-rkt-with-kubernetes.md还提供了两条快速落地路径：

• coreos-kubernetes：可用于在 AWS 或本地 Vagrant 环境拉起集群，常用配置方式是把环境变量CONTAINER_RUNTIME设为rkt；
• coreos-baremetal：面向裸机部署，支持开箱即用地把 rkt 配置为 Kubernetes 运行时。

对于本地开发体验，可以使用 Minikube 在虚拟机内启动单节点集群，并按官方 Quickstart 章节启用 rktnetes。需要说明的是，rkt 与 Kubernetes 集成期间已知的问题与使用建议记录在 rktnetes notes 中（即 kubernetes.io 的docs/getting-started-guides/rkt/notes页面）。

与 Apache Mesos 集成

Apache Mesos 将机器的 CPU、内存、存储等计算资源从物理机或虚拟机抽象出来，使容错、弹性的分布式系统能够被轻松构建与高效运行。rkt 作为 pod 原生引擎接入 Mesos 生态后，为 Mesos 框架提供了标准化容器执行能力：应用仍然以 ACI 形式分发与签名校验，而资源隔离与调度仍由 Mesos 统一管理。

这一集成方向体现了 rkt 的"组合性"设计哲学：rkt 不试图取代调度器，而是作为标准化的执行后端，让上层编排系统专注于调度决策。需要注意的是，仓库内并未提供 Mesos 驱动配置的专属文档，实际接入方式以 Mesos 1.0.0 发布说明所公布的支持能力为准。

与 HashiCorp Nomad 集成

Nomad 是一个主打易用性的分布式调度器，支持使用多种后端来执行task。自 Nomad v0.2.0 版本起，Nomad 加入了基于 rkt 的实验性任务执行驱动（rkt driver）。

Nomad 的 rkt driver 与 Kubernetes/Mesos 的接入方式不同：Nomad 以单个任务（task）为粒度，通过 driver 插件机制把任务派发给 rkt 执行。官方 Nomad 文档的docs/drivers/rkt.html页面详细描述了该 driver 的配置项（如image、command、args、mount等）。仓库侧的 Documentation/using-rkt-with-nomad.md 明确指出该支持当前为实验性质，因此在生产环境大规模使用前应充分评估其成熟度。

镜像构建与分发工具集成

dgr：面向 ACI 的构建与运行工具

dgr 是一个容器构建与运行工具，设计上偏好"约定优于配置"（convention over configuration）。它与 rkt 的对接点在于App Container Image（ACI）规范：dgr 负责把应用及其依赖打包为符合规范、可直接被 rkt 运行的 ACI。结合 Documentation/commands.md 可知，rkt 可以按名称、哈希、本地文件路径或 URL 执行 ACI；如果 ACI 尚未缓存在本地，rkt 会尝试通过 [meta discovery] 机制自动发现并下载。这一能力与 dgr 构建出的命名规范 ACI 天然衔接。

Mulled：生成最小容器镜像

Mulled 是一个用于生成最小容器镜像的工具，主要服务于生物信息学容器社区（BioContainers）。其核心思路是从大型镜像中裁剪出仅含目标工具及其依赖的精简镜像，从而减小镜像体积、缩短拉取时间并降低攻击面。Mulled 生成的精简镜像同样以 ACI/Docker 镜像形式供 rkt 使用。

Quay.io：企业级容器仓库托管

Quay.io 是一个企业级容器仓库，可以直接托管 rkt 镜像。rkt 对仓库生态的支持体现在两个层面：

1. ACI 的 meta discovery 分发：rkt 通过 appc 标准的 [ac-discovery 机制] 从任意 Web 主机发现 ACI 及其签名文件。在 Documentation/signing-and-verification-guide.md 中给出了完整的托管示例：在镜像站点放置ac-discovery与ac-discovery-pubkeys两个 HTML meta 标签后，执行rkt run example.com/hello:0.0.1会自动解析出 ACI 与.asc签名文件的模板 URL，并完成下载与签名验证；
2. Docker 镜像的原生拉取：借助 Documentation/running-docker-images.md 描述的docker://前缀，rkt 可以直接从任意 Docker Registry（包括 Quay.io）拉取并转换 Docker 镜像：

# 从默认 Docker Hub 拉取 redis # rkt --insecure-options=image run docker://redis # 从 quay.io 上的第三方仓库拉取 nginx # rkt --insecure-options=image fetch docker://quay.io/zanui/nginx sha512-c6d6efd98f506380ff128e473ca239ed

需要特别强调：由于 Docker 镜像不支持 appc 签名机制，拉取时必须显式使用--insecure-options=image关闭签名校验，rkt 会打印rkt: warning: image signature verification has been disabled警告。上面的sha512-...即为转换后 ACI 在本地镜像存储中的 ID，可用它直接运行：rkt --insecure-options=image run sha512-c6d6efd98f506380ff128e473ca239ed。

安全集成：rkt 与 SELinux（SVirt）

SELinux 是 rkt 清单中重要的安全集成对象。rkt 支持使用 SELinux 的 [SVirt] 机制运行容器，从 Documentation/selinux.md 可以还原其完整工作流程：

1. rkt 启动时会尝试读取/etc/selinux/(policy)/contexts/lxc_contexts；
2. 若该文件不存在，则不执行任何 SELinux 转换（transition）；
3. 若存在，则 rkt 会为每个实例生成独立的上下文（per-instance context）：实例的所有挂载点使用lxc_contexts中定义的file context，实例进程则运行在由其中process context派生出的上下文里。

示例的lxc_contexts内容：

# /etc/selinux/mcs/contexts/lxc_contexts process = "system_u:system_r:svirt_lxc_net_t:s0" content = "system_u:object_r:virt_var_lib_t:s0" file = "system_u:object_r:svirt_lxc_file_t:s0"

在这种机制下，即使进程以同一用户身份运行，不同实例上下文中的进程也无法相互访问对方的进程或文件，从而实现"pod 间强隔离"。例如，可以据此定义一个策略，禁止svirt_lxc_net_t上下文的成员写入 TCP 套接字。需要注意两点：

• 具体策略由发行版负责维护，示例仅用于说明，可能与实际发行版策略不同；
• 在 Fedora 生态中，Documentation/distributions.md 记录了一个已知兼容性限制：Fedora 24/25 随附的 SELinux 策略下 rkt 无法正常工作，临时解决方法是sudo setenforce Permissive，或永久修改/etc/selinux/config中SELINUX=permissive。

监控集成：cAdvisor

cAdvisor 是一个监控守护进程，负责收集运行中容器的资源使用与性能数据。rkt 为其提供数据的方式是通过rkt API Service——cAdvisor 这类监控组件通过 gRPC 查询 pod 与镜像的实时状态。API Service 的实现位于 rkt/api_service.go，其接口定义在 api/v1alpha/api.proto 中，主要包括：

• Image与ImageFormat：描述镜像的格式（appc/docker/oci）、ID、名称、版本、导入时间、清单、大小、注解与标签；
• Pod、App、Network：描述 pod 内应用的状态（RUNNING/EXITED）、退出码、网络地址等信息；
• ListPods()/InspectPod()/ListImages()/InspectImage()等 RPC 方法。

从 rkt/api_service.go 源码可以确认该服务基于 gRPC 实现，并内置了 pod 与 image 两层 LRU 缓存（默认大小均为 512）以降低查询开销，支持 systemd socket activation，同时按接口定义明确为只读、无需 root 权限。默认监听地址为localhost:15441（等价于rkt api-service --listen=localhost:15441），通过--listen=0.0.0.0可监听所有接口。运行方式通常是一个 systemd unit file。

仓库内还提供了可直接参考的客户端示例 api/v1alpha/client_example.go，展示如何在 Go 程序中通过生成的 protobuf 客户端与 API Service 交互——这正是 cAdvisor 等监控/管理组件对接 rkt 的典型编码范式。

操作系统集成：主流 Linux 发行版打包

rkt 被 Red Hat、Ubuntu 等众多 Linux 发行版的包管理器内置收录，这是其生态覆盖面的直接体现。Documentation/distributions.md 记录了各发行版的安装方式：

除发行版自带软件包外，rkt 项目自身也会随构建产出 rpm 与 deb 包（适用于需要最新版本或发行版未收录的场景），且上游不维护自有仓库、需手动升级。rpm 系安装流程为：先导入发布签名公钥gpg --recv-key 18AD5014C99EF7E3BA5F6CE950BDD3E0FC8A365E，下载.rpm与.asc校验文件并gpg --verify，最后sudo rpm -Uvh rkt-*.rpm；deb 系同理，最后执行sudo dpkg -i rkt_*.deb。

此外，Fedora 环境还有一个网络相关的已知限制：rkt 尚未与 firewalld 完全集成，默认防火墙规则可能干扰 pod 网络连通性，可通过sudo firewall-cmd --add-source=172.16.28.0/24 --zone=trusted放行默认 pod 网络（172.16.28.0/24为 Documentation/networking/overview.md 中所述默认网络子网；配置了其他网络时需相应调整）。

集成生态的公共底座：安全模型与 API 契约

透过以上各集成可以看出，rkt 生态的各个集成对象共享两个公共底座：

1. 基于 ACI 与签名的标准分发模型。无论是 dgr/Mulled 构建的镜像、Quay.io 托管的镜像，还是各发行版打包的 rkt 本体，都遵循 App Container 规范。默认情况下 rkt 要求 ACI 使用 gpg 分离签名，信任通过 rkt trust 写入 keystore（默认目录为/etc/rkt/trustedkeys/root.d、/etc/rkt/trustedkeys/prefix.d及/usr/lib/rkt下对应目录）。集成方（如编排平台）若关闭校验，需显式指定 Documentation/commands.md 中定义的--insecure-options（包括image、tls、http、pubkey、capabilities、paths、seccomp等），且必须清楚了解每种选项对应的安全风险。

2. 标准化的 API 契约。Kubernetes kubelet、cAdvisor 等外部系统统一通过 rkt API Service 的 gRPC 接口（api/v1alpha/api.proto）获取 pod 与镜像信息，接口版本目前为1.0.0-alpha（见 rkt/api_service.go 中supportedAPIVersion），属于实验性接口。这种"运行时与编排/监控解耦"的设计，正是 rkt 得以同时被 Kubernetes、Mesos、Nomad 和 cAdvisor 等多个上层系统接入的原因。

小结

rkt 的集成生态可以概括为"一个标准、两个底座、四类伙伴"：以 App Container 标准为镜像分发基础，以 rkt API Service 与安全/签名模型为公共底座，分别对接了编排调度（Kubernetes、Mesos、Nomad）、镜像构建分发（dgr、Mulled、Quay.io）、安全监控（SELinux、cAdvisor）与操作系统（各大 Linux 发行版）四类生态伙伴。无论你是要在 Kubernetes 中启用 rktnetes，用 Nomad 的 rkt driver 调度任务，还是通过 API Service 把 rkt 的 pod/镜像数据接入自有监控平台，都可以以此为路线图，并结合仓库内 Documentation/using-rkt-with-kubernetes.md、Documentation/running-docker-images.md、Documentation/selinux.md 等文档继续深入。

• 容器运行时
• 云原生
• 网络