RSSH 解决现代容器编排环境的动态连接痛点

背景

传统 SSH 客户端长期服务于静态服务器环境：云服务器 IP 固定、连接配置可手动维护一套静态 profile。随着容器化与 Kubernetes 的普及，生产环境转变为 Docker 容器部署、K8s 弹性 Pod 等动态基础设施，容器的生命周期短、IP 频繁变化，传统 SSH 工具难以适应这种流动性。尽管市面上存在大量 SSH 工具，但它们普遍未针对容器和 Pod 的动态发现进行适配，就像它们“集体忽略了命令块的抽象”一样。这种缺失导致开发者在日常调试、排查问题时需要在 SSH 客户端与容器 CLI 之间频繁切换，效率低下。

核心内容

RSSH 针对上述痛点提出解决方案，其核心机制是：

1. 本地 CLI 检测：RSSH 会主动检测开发者本地电脑是否安装了 docker 或 kubectl 命令行工具。
2. 动态发现容器与 Pod：通过 docker 和 kubectl CLI 实时获取当前运行中的容器列表和 Kubernetes Pod 列表，并将它们作为与静态 profile 平级的连接目标呈现给用户。
3. Context 配置支持：允许用户通过自定义 context 来指定连接测试环境或生产环境的容器 / Pod，从而支持多环境切换。

RSSH 并非重新实现 SSH 协议或终端功能，而是专注于解决“动态资产发现”这一缺失环节，将容器/Pod 纳入 SSH 工具的统一管理界面，避免重复造轮子。

关键要点

• 动态环境（Docker 容器、K8s 弹性 Pod）使传统静态 SSH profile 维护方式失效。
• 现有 SSH 工具普遍忽略了容器/Pod 的动态发现能力。
• RSSH 通过检测本地 docker / kubectl CLI 来实现容器和 Pod 的自动发现。
• 静态 profile 与动态发现的容器/Pod 在 RSSH 中以平级方式展示，用户无需切换工具。
• 支持通过 context 配置筛选和连接不同环境（如测试、生产）的容器或 Pod。
• RSSH 的设计原则是“不造轮子”，即不重复实现 SSH 协议功能，只做连接发现层的增强。

意义与影响

RSSH 填补了传统 SSH 工具与现代容器编排生态之间的衔接空白。它降低了开发者在云原生场景下进行远程调试、日志查看、故障排查时的认知负担和操作步骤。通过将容器和 Pod 直接作为 SSH 连接的一等公民，RSSH 使开发者能够沿用熟悉的 SSH 工作流来处理动态基础设施。这种思路对其他终端管理类工具也具有启发意义——未来更多 SSH 工具或终端模拟器可能会内建对 Docker / K8s 的动态感知能力，从而推动整个工具链向云原生范式对齐。