容器运行时云原生网络【免费下载链接】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 attach是 rktpod 原生容器引擎提供的将外部客户端连接到运行中应用 I/O 流的子命令允许用户在应用以交互模式启动后随时挂载到其终端或标准流。本文以 Documentation/subcommands/attach.md 为核心结合 stage1/iottymux/iottymux.go、stage1/init/common/units.go 等源码完整讲解 attach 的启用条件、五种附加模式、--app/--mode参数用法及底层实现原理帮助你掌握在 rkt pod 中实现可分离交互会话的实战技能。attach 的适用前提应用只有同时满足以下三个条件才可以通过rkt attach附加必须启用了可附加的 I/O 模式应用需要以交互方式启动即--stdin、--stdout、--stderr中至少一个被显式设置为tty或stream必须处于运行中的 pod 内attach 的目标必须是状态为 running 的 pod 中的应用应用必须支持对应的附加模式tty模式暴露 TTY 终端端点stream模式暴露 stdin/stdout/stderr 三个独立流端点。从源码层面看这三个条件都有对应的硬性检查。rkt/attach.go 中runAttach首先通过pkgPod.PodFromUUIDString定位 pod随后检查p.State() ! pkgPod.Running则报错退出返回码 254确保只有运行中的 pod 才能作为 attach 目标。而--stdin/--stdout/--stderr参数的合法取值在 rkt/cli_apps.go 的appStdin/appStdout/appStderr类型中定义stdin 允许null、stream、ttystdout/stderr 额外允许log。这意味着如果你以默认方式stdin 为null、stdout/stderr 为log启动应用则该应用不可 attach。遗留限制--interactive模式不可附加值得注意rkt 早期提供的--interactive标志虽然也将流接到父终端但它不支持 attach且只能用于单应用 pod、运行时与父终端生命周期绑定。这与tty/stream模式存在本质区别——后者分配独立资源、支持外部附加/分离、支持单 pod 多应用且不将 pod 生命周期与父终端绑定。详见设计文档 Documentation/devel/log-attach-design.md 中的 Runtime modes 一节。快速上手两种典型附加场景场景一TTY 模式——专用终端附加以tty模式启动应用为其分配一个专属伪终端随后用--mode tty双向附加# rkt run quay.io/coreos/alpine-sh --stdin tty --stdout tty --stderr tty# rkt attach --mode tty ${UUID} / # hostname rkt-911afe8e-992f-4089-8666-4a4c957a1964 / # tty /rkt/iottymux/alpine-sh/pts ^C可以看到附加后tty命令输出/rkt/iottymux/alpine-sh/pts这正是 iottymux 在 stage1 中创建的伪终端从设备路径印证了 TTY 由ttymux组件提供并绑定挂载在/rkt/iottymux/app/stage2-pts对应 stage1/iottymux/iottymux.go 中actionTTYMux的实现。场景二Stream 模式——分离的标准流附加不使用 TTY而是让 stdin/stdout/stderr 各自独立可附加# rkt run quay.io/coreos/alpine-sh --stdin stream --stdout stream --stderr stream# rkt attach --mode stdin,stdout,stderr ${UUID} hostname rkt-846c35db-6728-471a-ad50-66d3a8d7ff9c tty not a tty ^C由于没有分配终端应用内执行tty会得到 not a tty这正是 stream 模式与 tty 模式的直观区别。--mode附加模式详解--mode是 attach 的核心参数源码中由 rkt/attach.go 的createStage1AttachFlags函数解析为 stage1 attach 入口的 action 与端点标志。其取值及行为如下取值行为对应 stage1 actionlist列出应用可用的附加端点不实际附加立即返回--actionlistauto自动发现并附加到所有可用端点默认值--actionauto-attachtty双向附加到应用终端输入 输出--actioncustom-attachtty-in/tty-out 均为 truetty-in/tty-out单向附加仅输入或仅输出--actioncustom-attachstdin,stdout,stderr附加到指定的一个或多个标准流未指定的流不附加--actioncustom-attach需要注意custom-attach模式下存在两条源码级校验规则见createStage1AttachFlags至少指定一个端点若--mode解析后没有任何端点被选中返回错误mode must specify at least one endpoint to attachTTY 与流互斥不能同时附加 TTY 和标准流否则报incompatible endpoints ... cannot simultaneously attach TTY and streams。因此--mode tty,stdin这类组合是非法的。此外createStage1AttachFlags只接受上述枚举值遇到其他字符串会返回unknown endpoint错误并导致 attach 失败。多应用 pod用--app指定目标当 pod 内含多个应用时--app APPNAME指定要附加的应用--mode list可先列出端点。stage0 会把解析出的应用名作为--appname传给 stage1 入口再由 iottymux 从/rkt/iottymux/appname/endpoints状态文件中读取该应用的端点。实战进阶高级选项与管道以下示例展示复杂场景下的用法应用仍以--stdin stream --stdout stream --stderr stream启动通过管道向 stdin 注入命令、并用--mode控制要附加哪些流# rkt attach --app alpine-sh --mode list 846c35db stdin stdout stderr # echo hostname; fakecmd | ./rkt attach --app alpine-sh --mode auto ${UUID} rkt-846c35db-6728-471a-ad50-66d3a8d7ff9c /bin/sh: fakecmd: not found ^C # echo hostname; fakecmd | ./rkt attach --app alpine-sh --mode stdin,stdout ${UUID} rkt-846c35db-6728-471a-ad50-66d3a8d7ff9c ^C # echo hostname; fakecmd | ./rkt attach --app alpine-sh --mode stdin,stderr ${UUID} /bin/sh: fakecmd: not found ^C这个例子清晰展示了端点组合的效果--mode auto附加全部三个流stdin注入的hostname; fakecmd全部执行stdout 回显hostname的输出、stderr 回显fakecmd: not found报错--mode stdin,stdout仅附加 stdin 与 stdout因此 stderr 的报错被丢弃只看到 hostname 输出--mode stdin,stderr则只回显 stderr 报错stdout 的 hostname 输出被丢弃。从实现角度这种按流过滤的效果源于 stage1/iottymux/iottymux.go 的actionAttach它根据STAGE2_ATTACH_*系列环境变量决定为哪些端点启动io.Copy拷贝协程未选中的流对应的连接虽然建立但不会读写数据。命令参数速查attach 专有参数Flag默认值取值说明--app空应用名称指定 pod 内要附加的应用名--modeautolist、auto或 tty/stream 组合模式附加模式命令形式为rkt attach [--appAPPNAME] [--modeMODE] UUID其中UUID是运行中 pod 的 UUID可参考 Documentation/subcommands/list.md 查看 pod 列表与 UUID。注意cmdAttach在 rkt/attach.go 中通过ensureSuperuser(runWrapper(runAttach))包装需要 root 权限执行。全局参数rkt attach同样支持通用全局参数如--debug、--dir、--insecure-options等完整表格参见 Documentation/commands.md 中的 全局参数一览。其中--debug会被透传为 stage1 attach 的--debug标志控制iottymux的诊断日志输出。底层原理从 stage0 到 iottymux 的完整链路attach 功能横跨 stage0 与 stage1 两个层次理解这条调用链有助于排查问题stage0 CLI 层rkt attach命令在 rkt/attach.go 中实现。runAttach校验 pod 状态、获取 pod 的容器 PIDContainerPid1、解析--app默认取 pod 内唯一应用多应用时必须在--app中显式指定、获取 stage1 的 tree store rootfs然后调用createStage1AttachFlags把--mode翻译成 stage1 参数。跨层跳转stage0/attach.go 的Attach通过CrossingEntrypoint机制携带 pod 路径、pod PID、应用名和参数以Interactive: true模式穿越 stage0/stage1 边界。stage1 attach 入口stage1/attach/attach.go 解析--action与--app校验 action 合法性list/auto-attach/custom-attach并通过PrepareEnterCmd进入 stage1 上下文最终以环境变量STAGE2_ATTACH_TTYIN/TTYOUT/STDIN/STDOUT/STDERR携带自定义端点选择执行/iottymux。iottymux 核心stage1/iottymux/iottymux.go 按--action分发list→actionPrint读取并打印状态文件中的端点auto-attach/custom-attach→actionAttach读取/rkt/iottymux/app/endpoints中的 JSON 端点列表用net.Dialer连接各端点unix socket自动模式下附加全部端点自定义模式下依据STAGE2_ATTACH_*环境变量过滤端点随后用io.Copy在本地 stdin/stdout/stderr 与远端 socket 间双向搬运数据iomux/ttymux这是 pod 运行期间的守护动作由 systemd 服务单元在应用启动时拉起负责创建并维护可附加端点详见下文。端点状态文件附加的目录rkt attach的自动发现机制依赖状态文件/rkt/iottymux/appname/endpoints这是一个带版本号的 JSON 文档内容随应用 I/O 模式而变。例如一个三个流均可附加的应用其状态文件如下{ version: 1, targets: [ { name: stdin, domain: unix, address: /rkt/iottymux/alpine-sh/sock-stdin }, { name: stdout, domain: unix, address: /rkt/iottymux/alpine-sh/sock-stdout }, { name: stderr, domain: unix, address: /rkt/iottymux/alpine-sh/sock-stderr } ] }代码中的Endpoint结构体Name/Domain/Address与Targets容器VersionTargets正是对这一文档的建模见 stage1/iottymux/iottymux.go。TTY 模式下端点则变为单个tty条目地址为/rkt/iottymux/app/sock-tty。两个 sidecariomux 与 ttymux可附加端点由 pod 内两个 systemd 模板服务维护均位于 stage1/units/units/iomux.service流式复用应用为stream模式时引入应用侧单元文件写入StandardInputfd/Socketsapp-stdin.socket等属性Before依赖。其ExecStart/iottymux --actioniomux --app%istage1/units/units/iomux.service内部通过actionIOMux为每个启用的流打开 FIFO/rkt/iottymux/app/stage2-stream并创建 unix socket 监听再以bufferLine/muxOutput/muxInput等协程把 FIFO 数据多路复用到多个客户端。ttymux.serviceTTY 复用应用为tty模式时引入应用单元获得TTYPath/rkt/iottymux/app/stage2-ptsAfter依赖。其ExecStart/iottymux --actionttymux --app%istage1/units/units/ttymux.service内部通过actionTTYMux创建 PTY 主从对把从设备绑定挂载到固定路径stage2-pts供 systemdTTYPath使用通过 sd_notify 通知READY1后再开启sock-tty监听并写入端点状态文件。sidecar 的运行配置调试开关、启用的流集合、是否使用 TTY由 stage1/init/common/units.go 的SetupAppIO在应用单元生成时写入/rkt/iottymux/app/env环境文件两个服务单元均通过EnvironmentFile/rkt/iottymux/%i/env加载。这一整套注解驱动、systemd 服务单元 模板 sidecar的设计完整记载于 Documentation/devel/log-attach-design.md。systemd 版本与附加能力的约束可附加 I/O 依赖 systemd 的 socket 流重定向能力systemd PR #4179。SetupAppIO在生成应用单元时会检查 stage1 的 systemd 版本src/hostflavor 要求 ≥ 232coreos/kvmflavor 要求 ≥ 231若版本过旧且检测到 attachable I/O 注解会直接报错stage1 systemd %d does not support attachable I/O。这意味着在某些自定义 stage1 上使用 attach 前需要先确认其 systemd 版本满足要求。退出与信号处理rkt attach是阻塞式命令附加期间会一直把本地流与 pod 内应用端点相连。TTY 模式下按下^C会触发信号iottymux通过dispatchSig监听SIGTERM/SIGHUP/SIGINT并关闭停止通道进而终止代理进程、结束 attach 会话。actionAttach的退出时机也值得一提stdin/tty-in 的输入拷贝只能靠进程结束用户分离来取消而 stdout/stderr/tty-out 的输出拷贝会在远端 socket 出错时如应用退出通过错误通道-c立即返回因此当应用进程退出时attach 会自动随之结束。小结rkt attach通过 tty/streamI/O 模式 iottymux sidecar 端点状态文件三者配合为运行中的 pod 应用提供了终端级与流级两种可分离的交互通道。实操上只需记住启动时用--stdin/--stdout/--stderr显式开启tty或stream运行时用rkt attach --mode mode [--app name] UUID附加需要排障时先用--mode list检查可用端点。结合 Documentation/subcommands/run.md 的 I/O 参数表与 Documentation/devel/log-attach-design.md 的设计说明你可以在 rkt 场景中灵活构建可分离的交互式容器工作流。赞分享容器运行时云原生网络【免费下载链接】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点击查看免费下载相关推荐3个惊人改变让普通鼠标在macOS上超越苹果触控板的终极方案3个惊人改变让普通鼠标在macOS上超越苹果触控板的终极方案 你是否觉得在macOS上使用普通鼠标总是缺少那份流畅自然的触控板体验Mac Mouse Fix桌面应用系统编程CPython pdb 交互式调试器完全指南从 breakpoint() 到命令行、远程附加与双后端机制CPython pdb 交互式调试器完全指南从 breakpoint 到命令行、远程附加与双后端机制 本指南以 CPython 标准库文档 Doc/libra编程语言语言运行时解释器标准库CS-NotesSocket 五大 I/O 模型与 select、poll、epoll 多路复用机制详解CS NotesSocket 五大 I/O 模型与 select、poll、epoll 多路复用机制详解 本文基于 CS Notes 仓库中的 notes/S知识库文档教程上一篇doas配置文件深度解析10个实用示例教你精细控制权限下一篇Cranelift 代码生成器后端项目常见问题解决方案创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考