容器运行时云原生网络【免费下载链接】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 run是 rkt一款面向 Linux 的 pod 原生容器引擎的核心子命令用于将 App Container 镜像ACI或 Docker 镜像以 pod 为单位一次性拉起并在同一个 pod 内运行多个应用。本文基于 Documentation/subcommands/run.md 编写完整覆盖镜像寻址、多应用编排、应用属性覆盖、环境变量、卷挂载、网络配置、自定义 stage1 等全部能力并结合 rkt/run.go、stage0/run.go 等源码说明其底层执行流程帮助读者从命令行实操到内部原理全面掌握rkt run。镜像寻址四种方式引用要运行的镜像rkt run的 IMAGE 参数支持四种引用形式镜像名称、镜像哈希、显式传输地址URL、Docker Registry 地址。如果镜像不在本地 store 中rkt 会自动执行发现与拉取具体策略可参考 image-fetching-behavior.md。按名称运行镜像名称采用 URL 风格命名rkt 会通过 App Container 规范定义的元数据发现机制解析并拉取# rkt run coreos.com/etcd:v2.0.0按哈希运行镜像被拉取后会以内容寻址的方式存放在本地 store 中哈希以sha512-为前缀可以直接用哈希精确引用# rkt run sha512-fa1cb92dc276b0f9bedf87981e61ecde按 ACI 地址运行直接给出 ACI 文件的 HTTP/HTTPS URLrkt 会下载该文件并运行# rkt run https://github.com/coreos/etcd/releases/download/v2.0.0/etcd-v2.0.0-linux-amd64.aci从 Docker Registry 运行使用docker://传输地址即可直接运行 Docker 镜像。由于 Docker 镜像的签名机制与 ACI 不同通常需要配合--insecure-optionsimage关闭签名校验# rkt --insecure-optionsimage run docker://quay.io/coreos/etcd:v2.0.0从源码角度上述寻址逻辑由image.Finder见 rkt/run.go完成它综合了 store 状态、认证信息、--insecure-options全局标志与--pull-policy拉取策略WithDeps: true表示会连同依赖镜像一并解析。在同一个 Pod 中运行多个应用pod 是 rkt 的核心抽象多个应用共享同一个 pod 的生命周期、网络命名空间、卷与资源边界。在一条命令中传入多个镜像即可让它们同 pod 运行# rkt run example.com/app1 example.com/app2底层实现中命令行里每个镜像会被构造成一个apps.App条目见 common/apps/apps.go包含镜像引用、exec 覆盖、卷、资源隔离器等字段随后在generatePodManifest见 stage0/run.go中逐应用生成运行时配置组装成完整的 PodManifest。使用运行时 Manifest--pod-manifest--pod-manifest允许直接传入一个运行时 manifestruntime manifest来定义整个 pod。此时 pod 中应用对应的镜像 manifest 配置会被覆盖镜像中声明的配置项将被忽略。# rkt run --pod-manifest/path/to/pod-manifest.json运行时 manifest 完全决定了 pod 的启动方式适合将复杂 pod 的配置写入文件、纳入版本控制避免每次敲冗长的命令行。推荐的工作流是先用 CLI 运行一次 pod再用rkt cat-manifest UUID导出生成好的 manifest编辑后复用$ sudo rkt run coreos.com/etcd:v2.0.10 --- kinvolk.io/aci/busybox:1.24 -- -c while true; do date; sleep 1; done $ rkt cat-manifest 07f1cfdc pod-manifest.json $ # 编辑 pod-manifest.json例如为 etcd 添加 memory 隔离器 $ sudo rkt run --pod-manifestpod-manifest.json需要注意使用--pod-manifest时镜像必须已存在于本地 storerkt 不会执行发现或拉取。源码中该路径走validatePodManifest见 stage0/run.go它要求每个 app 都带有明确的 image ID并校验 app 名称唯一性与端口转发合法性。同时 rkt/run.go 明确拒绝与--pod-manifest同时指定 app、volume、mount、port、pull-policy 等冲突参数。完整的 manifest 编写指南参见 pod-manifest.md。覆盖应用的默认属性rkt 允许在启动时按“前置镜像”preceding image逐个覆盖 ACI 中声明的应用配置这是最常用的定制手段。覆盖应用名称--name默认情况下镜像名称会被用作应用名称。当需要让同一镜像在 pod 内以多个不同实例运行时可用--name区分# rkt --insecure-optionsimage run docker://busybox --namebusybox1 docker://busybox --namebusybox2源码中appName.Set见 rkt/cli_apps.go将该值写入当前 app 条目若未指定generatePodManifest会通过common.ImageNameToAppName从镜像名转换出应用名见 stage0/run.go并拒绝同名应用。覆盖要启动的可执行文件--execACI 的 app 段包含exec字段指定入口可执行文件可用--exec覆盖# rkt --insecure-optionsimage run docker://busybox --exec /bin/date若镜像本身没有 app 段则必须提供--exec否则准备阶段会直接报错见 stage0/run.go。同类覆盖还有--working-dir工作目录与--readonly-rootfs将根文件系统只读挂载。覆盖隔离器--cpu / --memoryACI 可声明 per-app 隔离器其中部分可在命令行覆盖。资源单位遵循 Kubernetes 资源模型CPU 用m表示毫核milli-cores内存用M/G/Mi等后缀# rkt run coreos.com/etcd:v2.0.0 --cpu750m --memory128M--memory的解析在 rkt/cli_apps.go 中完成代码特意拒绝低于 4096 字节的取值防止用户误把--memory16m毫字节当成 16MB 传入。这些隔离器最终由prepareIsolators见 stage0/run.go合并进应用的 isolator 列表。同类隔离器覆盖还包括--cpu-shares、--caps-remove、--caps-retain、--seccomp、--oom-score-adjust。覆盖 User/Group--user / --group镜像 manifest 必须声明应用运行所用的用户名/组或 UID/GID可用--user与--group覆盖# rkt --insecure-optionsimage run docker://busybox --user1000 --group100 --exec id两个 flag 都接受 uid/gid 数字、用户名/组名或文件路径三种形式--group默认值为rootGID 0。如需补充附属组可用--supplementary-gids# rkt run example.com/app --supplementary-gids1024,2048向各个应用传递参数多应用场景下需要为不同应用分别传递不同的启动参数。语法为image1 -- [image1 flags] --- image2 -- [image2 flags]--开启前一个镜像的应用参数段---结束该段并恢复参数解析# rkt run example.com/worker -- --loglevel verbose --- example.com/syncer -- --interval 30s该语法可以跟--exec等覆盖组合使用# rkt run example.com/worker --exec /bin/ov -- --loglevel verbose --- example.com/syncer --exec /bin/syncer2 -- --interval 30s参数解析实现在 rkt/cli_apps.go 的parseApps中它通过flags.SetInterspersed(false)关闭参数穿插见 rkt/run.go在--与---之间的所有参数原样追加到当前应用的Args列表并在generatePodManifest中写入对应 app 的exec数组。添加用户注解与用户标签--user-annotation和--user-label可向应用追加自定义注解与标签它们会出现在 pod manifest 对应 app 的UserAnnotations与UserLabels字段中# rkt run example.com/example --user-annotationfoobar --user-labelhelloworld两者都要求keyvalue格式见 rkt/cli_apps.go 与 rkt/cli_apps.go。注意还有一个--annotationflag其写入的是 app 的Annotations字段语义上区别于用户注解。影响环境变量的四种方式与优先级rkt 提供了多级环境变量注入能力可以全部继承父进程环境、为所有应用统一设置、从文件批量加载也可以为每个应用单独设置--inherit-env继承父进程的全部环境变量--set-env-file从文件为所有应用设置环境变量格式为每行VAR_NAMEVALUE空行以及#、;开头的注释行会被忽略格式错误的行直接报错解析实现见 rkt/run.go--set-env在命令行上为所有应用设置环境变量--environment为单个应用前置镜像单独设置环境变量。优先级从低到高如下后项会覆盖前项的相同变量名父进程环境--inherit-env应用镜像自带环境--set-env-file文件中的变量--set-env命令行变量--environment单应用变量注意--inherit-env继承的环境不会覆盖镜像自带环境而第 35 级都会强制覆盖。这正对应 stage0/run.go 中mergeEnvs的override参数继承环境调用时传false其余统一调用时传true。示例一继承 全应用统一设置# export EXAMPLE_ENVhello # export EXAMPLE_OVERRIDEunder # rkt run --inherit-env --set-envFOObar --set-envEXAMPLE_OVERRIDEover example.com/env-printer EXAMPLE_ENVhello FOObar EXAMPLE_OVERRIDEover示例二单应用变量覆盖全应用变量# export EXAMPLE_ENVhello # export EXAMPLE_OVERRIDEunder # rkt run --inherit-env --set-envFOObar --set-envEXAMPLE_OVERRIDEover example.com/env-printer --environmentEXAMPLE_OVERRIDEride EXAMPLE_ENVhello FOObar EXAMPLE_OVERRIDEride控制镜像签名验证默认情况下 rkt 会校验镜像签名。在测试环境或运行来源可信的镜像时可通过全局标志--insecure-optionsimage关闭该校验# rkt --insecure-optionsimage run coreos.com/etcd:v2.0.0 rkt: searching for app image coreos.com/etcd:v2.0.0 rkt: fetching image from https://github.com/coreos/etcd/releases/download/v2.0.0/etcd-v2.0.0-linux-amd64.aci rkt: warning: signature verification has been disabled ...--insecure-options是全局标志默认值为none即全部安全特性开启除image外还支持http、tls、pubkey、capabilities、paths、seccomp、all-fetch、all-run、all等取值完整说明见 commands.md。更安全的做法是配合 trust 子命令预先信任发布者的公钥让签名验证在无需关闭的情况下完成。将卷挂载进 PodACI 可以在镜像 manifest 中声明期待外部数据挂载的挂载点mountPoints。下例声明了名为data的挂载点{ acKind: ImageManifest, name: example.com/app1, ... app: { ... mountPoints: [ { name: data, path: /var/data, readOnly: false, recursive: true } ] } ... }卷Volume与挂载点Mount Point的匹配规则卷通过名称与挂载点绑定同名即匹配。rkt 提供两种卷host 卷将宿主机上的一个目录或文件暴露给 podempty 卷初始化一块 pod 内可访问的空存储pod 被垃圾回收时随之删除。未匹配到任何挂载点或--mount的卷会被静默忽略反过来如果镜像声明了挂载点但没有匹配的卷rkt 会自动创建一个隐式empty卷来满足它。卷校验逻辑见 common/apps/apps.go它逐挂载点检查引用的卷是否真实存在防止出现“悬空挂载”。Host 卷--volume--volume语法--volume NAME,kindhost,sourceSOURCE_PATH,readOnlyBOOL,recursiveBOOL其中卷名与宿主机路径为必填项readOnly默认为falserecursive默认为truecoreos 与 KVM stage1 发行版fly stage1 默认false。将宿主机的/srv/data挂到 app1 的/var/data# rkt run --volume data,kindhost,source/srv/data,readOnlyfalse example.com/app1设置recursivefalse可以避免把/srv/data内部后续出现的挂载暴露给容器# rkt run --volume data,kindhost,source/srv/data,readOnlyfalse,recursivefalse example.com/app1如果想在容器内使用宿主机设备只需把 source 指向该设备节点即可更多示例见 block-devices.md。Empty 卷--volume不需要持久化、只想让 pod 内多个应用共享一块数据时使用empty卷# rkt run --volume data,kindempty,readOnlyfalse example.com/app1empty卷的语法为--volume NAME,kindempty,modeMODE,uidUID,gidGID卷名必填mode默认0755UID/GID 默认0# rkt run --volume data,kindempty,mode0700,uid0,gid0注意该例省略了 app 参数实际使用时应像前面示例一样在其后跟上目标镜像。卷字符串由types.VolumeFromString解析对应 rkt/cli_apps.go 中appsVolume.Set的实现。无挂载点时的卷挂载--mount如果 ACI 没有声明挂载点仍可用--mount把卷绑定到应用的指定路径。--mount是位置敏感的放在镜像名之后只作用于最近的前置镜像放在所有镜像之前则作用于所有应用且 per-app 挂载会优先于全局挂载合并逻辑见 stage0/run.go 的MergeMounts与deduplicateMPs。语法为--mount volumeNAME,targetPATH。下例把同一卷logs挂到不同应用的不同路径# rkt run --volume logs,kindhost,source/srv/logs \ example.com/app1 --mount volumelogs,target/var/log \ example.com/app2 --mount volumelogs,target/opt/log若把--mount放在镜像名之前则对所有应用生效app1 与 app2 都会在/var/log看到/srv/logs# rkt run --volume logs,kindhost,source/srv/logs \ --mount volumedata,target/var/log \ example.com/app1 example.com/app2MapReduce 实战示例设想读取宿主目录/opt/tenant1/work驱动一个 MapReduce 风格的计算 workerexample.com/reduce-worker并让同 pod 中的备份应用example.com/worker-backup只读访问同一份数据。两个应用各自在镜像 manifest 中声明同名挂载点work{ acKind: ImageManifest, name: example.com/reduce-worker, ... app: { ... mountPoints: [ { name: work, path: /var/lib/work, readOnly: false } ], ... } ... }{ acKind: ImageManifest, name: example.com/worker-backup, ... app: { ... mountPoints: [ { name: work, path: /backup, readOnly: true } ], ... } ... }两个应用都用抽象卷名work引用数据而不关心具体宿主路径因此同一镜像可以在不同的宿主机上复用而无需耦合文件系统布局。启动时用--volume提供真实来源即可# rkt run --volumework,kindhost,source/opt/tenant1/work \ example.com/reduce-worker \ example.com/worker-backup如果镜像没有挂载点可用--mount达到类似效果注意两者此时都是读写挂载# rkt run --volumework,kindhost,source/opt/tenant1/work \ example.com/reduce-worker --mount volumework,target/var/lib/work \ example.com/worker-backup --mount volumework,target/backuppod 运行后两个应用将在各自期望的路径上看到宿主机/opt/tenant1/work的内容。启用元数据服务注册--mds-register默认情况下rkt run不会把 pod 注册到元数据服务metadata service。需要时通过--mds-register开启# rkt run --mds-register coreos.com/etcd:v2.0.0注册要求 pod 与宿主机之间有网络连通性--net必须为default、default-restricted或host。源码中stage0.Run在MDSRegister为真时会调用registerPod获取 mds token 并作为--mds-token传给 stage1 init见 stage0/run.go且 rkt/run.go 明确禁止与--netnone组合。元数据服务的作用与部署方式见 metadata-service.md。Pod 网络配置--netrun子命令通过--net配置 pod 网络其实现依赖 CNIContainer Network Interface插件体系详见 networking/overview.md。默认 contained 网络不传--net时自动假定为--netdefault加载内建的 default 网络loopback vethpod 从172.16.28.0/24分配 IPv4设置默认路由并在宿主机开启 IP 伪装。宿主机网络--nethost# rkt run --nethost coreos.com/etcd:v2.0.0--nethost使 pod 内应用与调用进程共享网络命名空间。严格来说只有rkt run直接在宿主机上调用时才等于“与宿主机共享网络栈与网卡”因为实际继承的是发起rkt run的进程所在命名空间。共享 host 命名空间意味着 pod 内服务能访问宿主机的 IP、路由、iptables 规则乃至抽象 socket如 X11、D-Bus需谨慎评估安全边界。其他网络选项--netnonepod 置于只有 loopback 的网络命名空间完全隔离--netnet1,net2,...加入一组自定义网络配置文件位于/etc/rkt/net.d按文件名字典序执行--netall加载所有已配置网络通过--portNAME:HOSTPORT将 pod 内端口映射到宿主机例如--port80-tcp:8080要求使用 contained 网络见 networking/overview.md。将 rkt 作为守护进程运行rkt 本身不提供内置 daemon 化能力但它是一个普通进程可借助 init 系统达到同样的效果。使用 systemd 的宿主机可以直接用systemd-run拉起参见 using-rkt-with-systemd.md不使用 systemd 时也可以用经典的daemon工具包装。更典型的做法是把rkt run封装成 systemd unit让 systemd 接管其生命周期、日志与重启策略。使用自定义 Stage1--stage1-*rkt 采用分阶段staged架构stage0 是rkt二进制本身stage1 是承载 pod 运行环境的初始化镜像。得益于这种模块化设计可以通过--stage1-{url,path,name,hash,from-dir}五个 flag 指定自定义 stage1# rkt --stage1-path/tmp/stage1.aci run coreos.com/etcd:v2.0.0rkt 默认要求 stage1 镜像已签名但以下情况例外使用默认 stage1 且该镜像与 rkt 二进制位于同一目录使用--stage1-name/--stage1-hash且镜像已在 store 中使用--stage1-url/--stage1-path/--stage1-from-dir且镜像位于构建时配置的默认目录。各 flag 的差异--stage1-url支持 HTTP/HTTPS/File/Docker URL--stage1-name会在镜像不在 store 时执行发现--stage1-hash要求镜像必须已在 store 中--stage1-from-dir在默认 stage1 镜像目录中按名字查找。架构细节见 architecture.mdstage1 的构建与调试方法见 hacking.md实现指南见 stage1-implementors-guide.md。禁用 Overlay--no-overlayrkt 默认使用 overlayfs 运行应用容器带来显著性能与效率收益大容器启动更快多个共享同一镜像的 pod 占用更少磁盘空间且能共享 page cache。若底层文件系统不支持 overlayfs该特性会自动禁用rkt/run.go 中PathSupportsOverlay探测失败时会打印disabling overlay support并回退到ovlOkfalse也可显式关闭# rkt run --no-overlaytrue --insecure-optionsimage coreos.com/etcd:v2.0.0overlay 是否启用最终由useOverlay : !flagNoOverlay ovlOk决定并一路传递给stage0.Prepare/stage0.Run。注意overlay 与 user namespace 目前不能同时使用见 stage0/run.go 的报错提示需要私有用户时请配合--no-overlay。完整 Options 参考以下表格汇总了rkt run的全部选项默认值、取值与说明供实际使用与脚本化调用时查阅。Flag默认值取值说明--caps-removenone要移除的 capability如--caps-removeCAP_SYS_CHROOT,CAP_MKNOD从进程 capability bounding set 中移除其余默认集合中的 capability 保留--caps-retainnone要保留的 capability如--caps-retainCAP_SYS_ADMIN,CAP_NET_ADMIN在进程 capability bounding set 中仅保留所列项其余全部移除--cpunoneCPU 单位如--cpu500m前置镜像的 CPU 限制Kubernetes 资源模型格式--dnsnone逗号分隔的 IP、host或none写入/etc/resolv.conf的 nameserver可重复指定host使用宿主机 resolv.confnone忽略 CNI DNS 配置--dns-domainnoneDNS 域名如--dns-domainexample.com写入/etc/resolv.conf的 domain--dns-optnoneDNS 选项写入/etc/resolv.conf的 resolv.conf(5) 选项可重复指定--dns-searchnone域名写入/etc/resolv.conf的搜索域可重复指定--environmentnone环境变量如--environmentfoobar设置前置镜像单应用的环境变量--execnone可执行文件路径覆盖前置镜像的 exec 命令--grouprootgid、组名或文件路径如--groupcore前置镜像的 group 覆盖--hosts-entrynone/etc/hosts条目如--hosts-entry10.2.1.42db向 pod 级/etc/hosts追加条目传host使用宿主机/etc/hosts--hostnamerkt-$PODUUID主机名设置 pod 的主机名--inherit-envfalsetrue或false继承应用未设置的所有环境变量--interactivefalsetrue或false交互式运行 pod为真时只能提供一个镜像--ipcautoauto、private或parent是否停留于宿主机 IPC 命名空间--mds-registerfalsetrue或false将 pod 注册到元数据服务需要与宿主机有网络连通--net为default、default-restricted或host--memorynone内存单位如--memory50M前置镜像的内存限制Kubernetes 资源模型格式低于 4096 字节会被拒绝--mountnone挂载语法如--mount volumeNAME,targetPATH将卷绑定到应用内路径位置敏感见上文无挂载点时的卷挂载--namenone应用名设置应用名如--namefoo未设置时默认为镜像名--netdefault逗号分隔的网络列表如--net[n[:args], ...]配置 pod 网络可传自定义网络列表及对应参数--no-overlayfalsetrue或false禁用 overlay 文件系统--oom-score-adjustnone调整/proc/$pid/oom_score_adjoom-score-adj 隔离器覆盖--pod-manifestnone文件路径pod manifest 路径非空时仅--net、--no-overlay、--interactive生效--portnone端口名与主机端口对通过主机端口暴露容器端口需要 contained 网络。语法--portNAME:HOSTPORTNAME 为 ACI 中声明的端口名Docker 镜像约定以端口号-协议命名如--port80-tcp:8080--private-usersfalsetrue或false在 user namespace 中运行--pull-policynewnever、new或update镜像拉取策略见 image-fetching-behavior.md--readonly-rootfsnone布尔值如--readonly-rootfstrue为真时应用 rootfs 只读挂载--seccompnone过滤器覆盖如--seccomp moderetain,errnoEPERM,chmod,chownseccomp 过滤器覆盖--set-envnone环境变量如--set-envNAMEVALUE为所有应用设置的环境变量--set-env-filenone环境变量文件路径如--set-env-file/path/to/env/file为所有应用从文件加载环境变量--signaturenone文件路径校验前置镜像时使用的本地签名文件--stage1-from-dirnone镜像名如--stage1-namecoreos.com/rkt/stage1-coreos在默认 stage1 镜像目录中按文件名查找--stage1-hashnone镜像哈希如--stage1-hashsha512-dedce9f5ea50stage1 镜像哈希镜像必须已在 store 中--stage1-namenone镜像名如--stage1-namecoreos.com/rkt/stage1-coreosstage1 镜像名不在 store 中时执行发现--stage1-pathnone绝对或相对路径stage1 镜像路径--stage1-urlnone带协议的 URLstage1 镜像 URL支持 HTTP/HTTPS/File/Docker--supplementary-gidsnone附属组 ID如--supplementary-gids1024,2048前置镜像的附属组 ID 覆盖--usernoneuid、用户名或文件路径如--usercore前置镜像的用户覆盖--user-annotationnone注解如--user-annotationfoobar写入 app 的UserAnnotations字段--user-labelnone标签如--user-labelfoobar写入 app 的UserLabels字段--uuid-file-savenone文件路径将 pod UUID 写入指定文件--volumenone卷语法如--volume NAME,kindKIND,sourcePATH,readOnlyBOOL定义 pod 内可用卷见上文将卷挂载进 Pod--working-dirnone目录如--working-dir/tmp/bar覆盖前置镜像的工作目录每应用选项与全局选项每应用选项--stdin、--stdout、--stderr为 per-app 选项控制每个应用的 I/O 流向该组 flag 在 attach 实验特性启用时可见见 rkt/run.go。Flag默认值取值说明--stdinnullnull、tty、stream该应用的标准输入模式--stdoutlognull、tty、stream、log该应用的标准输出模式--stderrlognull、tty、stream、log该应用的标准错误模式I/O 模式的合法取值由 rkt/cli_apps.go 中的白名单映射严格校验非法值会直接报错。模式语义定义在 common/apps/apps.gonull表示丢弃、log表示仅记录日志、stream表示可附加attachable的流、tty表示 TTY 上的 I/O。全局选项rkt run还接受rkt的全局选项例如--insecure-options、--debug、--dir、--local-config、--system-config、--trust-keys-from-https等完整表格见 commands.md。底层执行流程从命令行到 Pod 运行理解rkt run的内部流程有助于排查问题与二次开发参数解析parseAppsrkt/cli_apps.go将命令行拆解为应用列表镜像 per-app flag --/---参数段并做合法性校验如--interactive只能配一个镜像、--pod-manifest不能与其他 app 相关 flag 混用镜像解析打开 imagestore 与 treestore通过image.Finder依据--pull-policy解析并拉取所有镜像rkt/run.go创建 PodpkgPod.NewPod创建新 pod若指定了--uuid-file-save则提前写出 UUID 以便异常时可被rkt rm清理rkt/run.gooverlay 探测调用common.PathSupportsOverlay检测数据目录所在文件系统确定useOverlayrkt/run.goPrepare 阶段stage0.Preparestage0/run.go渲染 stage1 镜像与应用镜像、生成或校验 pod manifest 并写入磁盘期间对持PrepareLock的共享锁保护并发Run 阶段p.ToRun()将 pod 状态切到 running然后stage0.Runstage0/run.go装载 overlay 文件系统、生成 resolv.conf 与 hosts、设置锁 fd 与 SELinux 标签等环境最终通过syscall.Exec直接 exec 到 stage1 的 init 入口不会返回。值得一提的是 rkt/run_prepared.go 展示了rkt preparerkt run-prepared的两段式路径prepare只完成第 5 步并输出 UUIDrun-prepared接过 UUID 完成第 6 步。二者的 RunConfig 组装逻辑高度一致这也是把耗时准备与即时启动分离的推荐用法。小结rkt run把“一个 pod、多个应用、共享卷与网络”的编排模型浓缩进一条命令镜像寻址覆盖 ACI 与 Docker 两种生态per-app 覆盖机制让同一镜像可以差异化定制卷与--mount提供了从抽象命名到具体宿主路径的完整挂载体系而--net、--mds-register、--stage1-*等选项则把网络、服务发现与 stage1 可替换性纳入掌控。配合本文的 Options 参考表与源码线索rkt/run.go、rkt/cli_apps.go、stage0/run.go即可在实际环境中熟练编排 rkt pod并进一步向prepare/run-prepared、pod manifest 等进阶用法延伸。赞分享容器运行时云原生网络【免费下载链接】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点击查看免费下载相关推荐网盘直链下载助手用不了6 个卡点一次排清网盘直链下载助手用不了6 个卡点一次排清 网盘直链下载助手是个把百度网盘、阿里云盘、夸克网盘等九大网盘里的文件变成真实直链的浏览器脚本拿到直链交给 IDM、前端Cycle.js RxJS Run 指南使用 cycle/rxjs-run 以 RxJS 运行 Cycle.js 应用Cycle.js RxJS Run 指南使用 cycle/rxjs run 以 RxJS 运行 Cycle.js 应用 cycle/rxjs run 是前端Web框架rkt KVM stage1 运行指南用 LKVM/QEMU 虚拟化隔离运行 Podrkt KVM stage1 运行指南用 LKVM/QEMU 虚拟化隔离运行 Pod rktRocket是一个面向 Linux 的 pod 原生容器引擎。容器运行时云原生网络上一篇《Second-Brain》项目安装与配置指南下一篇如何快速配置ROS移动机器人轨迹优化TEB Local Planner完整指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考