背景
在边缘集群的场景下边缘节点分布在不同的区域，且边缘节点和云端之间是单向网络，边缘节点可以访问云端节点，云端节点无法直接访问边缘节点，给边缘节点的运维带来很大不便，如果可以从云端SSH登录到边缘节点可以简化节点的运维工作。针对这一需求，SuperEdge 项目扩展了 tunnel 组件的能力，新增了 SSH 模块，让用户可以从云端 SSH 登录到边缘节点。
需求分析
边缘集群的节点分布在不同的区域，边缘节点能够访问云端 master 节点，但 master 节点无法访问边端区域内的节点，用户希望通过访问 master 节点的端口 SSH 登录到节点实施运维工作。
常规方案
使用 SSH 端口转发技术可以实现 SSH 运维边缘节点功能，具体内容如下图所示：
- 边缘节点 node-A 和 node-B 通过 SSH 的远程转发(ssh -R)将云端 master-A 节点的 port-A 和 port-B 端口与本地22端口(SSH Server 的端口)绑定
- user 通过SSH的动态转发(ssh -D)与 master-A 建立 SSH 隧道同时在本地监听 local-port 端口
- local-port 的请求都会通过 SSH 连接传到 master-A，由master-A 转发，例如 SSH 登录 node-A：ssh -o ProxyCommand=”nc -X 5 -x 127.0.0.1:local-port 127.0.0.1 port-A” root@127.0.0.1 ，127.0.0.1 port-A 就是 master-A 转发时请求的目标地址。
常规方案的缺点：
- 边缘节点映射端口管理复杂 如图2所示，node-A 和node-B 将本地的22端口在 master-A 上映射为不同的端口，SSH 登录目标节点需要指定其在master-A映射的端口，当边缘节点数量很多时端口映射管理非常复杂，直接导致方案不可行。
- 请求涉及的多个连接，增加了出错的概率 以 SSH 登录 node-A为例，如图1所示，sshClient->local-port，user->master-A，master-A->port-A，master-A->node-A，node-A->sshServer，共计需要建立5条连接。
- 云端和边端的 SSH 维护麻烦 边端节点和云端节点的 SSH 连接，需要在边端节点上执行建立，且连接不具备断开重连的能力，维护起来比较麻烦。
tunnel 方案
架构设计
- SSH Client 请求 tunnel-cloud service 暴漏到外网的 NodePort-1 端口，service 根据负载均衡策略将请求转发 tunnel-cloud pod-A 或 tunnel-cloud pod-B。
- 如果请求转发到 pod-A(R.1.1)，由于 node-A 没有和 pod-A 建立隧道，pod-A 会查询 coredns 获取与 node-A 建立隧道的 pod-B 的 podIp，然后将请求转发到 pod-B(R.1.2)
- pod-B 收到请求后将请求通过隧道转发到 node-A 的 tunnel-edge，tunnel-edge 将请求转发到 SSH Server。
本方案的优势
- 在云端和边缘节点间的隧道不会映射端口，避开端口管理。
- 减少了请求过程中的建立连接数，减少了出错的概率
- 云端和边端的隧道具备断开重连机制，降低维护成本
云边隧道的建立
使用 gRPC 开源项目搭建长连接隧道，gRPC 实现断开重连机制。
- tunnel-edge 向 tunnel-cloud 发送建立 gRPC 连接的请求 tunnel-edge 在向 tunnel-cloud 的 NodePort-2 发送建立连接的请求，请求中携带了所在节点的节点名和 token 信息，tunnel-cloud service 根据负载均衡策略将请求转发到 tunnel-cloud pod，如图3所示，将请求转发到 tunnel-cloud pod-B
- tunnel-cloud 向 coredns 注册本 pod 的 podIp 和 tunnel-edge 所在的节点的节点名信息 tunnel-cloud 验证 tunnel-edge 请求信息中的 token 信息，验证通过后，节点请求信息中的节点名和本 pod的 podIp 写入到 coredns
- tunnel-cloud 返回 gRPC 连接建立成功的消息
- tunnel-edge 和 tunnel-cloud 之间通过 gRPC 长连接发送自定义协议消息 StreamMsg 关于自定义协议消息的字段定义请参考 一文读懂SuperEdge云边隧道
tunnel-cloud 转发的实现
-
SSH Client 请求 tunnel-cloud service 的 NodePort-1端口，发送 method 为 Connect的http 请求 SSH Client 通过工具 netcat 或 crokscrew 发送的 method 为 CONNECT HTTP 请求，即 ProxyCommand 的内容(ProxyCommand= "nc -X connect -x tunnel-cloudIp:NodePort-1 node-A 22" )，参数的定义如下：
- -X: 参数为协议的类型，这里指定的 connect 是 HTTP CONNECT
- -x: HTTP Server 的ip地址和端口，这里指定的 tunnel-cloudIp:NodePort-1 是 tunnel-cloud service 暴漏到外网的ip和端口
- node-A 为边端节点的节点名
- 22 为边端节点 SSH Server 的监听的端口
tunnel-cloud service 根据负载均衡策略将 SSH Client 的请求转发到 tunnel-cloud pod，如架构设计图3所示如果转发到 tunnel-cloud pod-A，tunnel-cloud 的 HTTP Server 收到的消息为 CONNECT node-A:22 HTTP/1.0 ,其中 node-A 为边端节点的节点名，22为边端节点 SSH Server 监听的端口，由于node-A没有与tunnel-cloud pod-A 建立云边隧道，因此 HTTP Server 会请求 coredns 获取 node-A 节点名对应的 tunnel-cloud 的 podIp，即为 tunnel-cloud pod-B , pod-A 会把请求转发给 pod-B
-
tunnel-cloud 向 tunnel-edge 发送自定义协议消息(StreamMsg.Type 为 connecting) tunnel-cloud 会根据 HTTP CONNECT 的请求信息中获取云端和边端节点的隧道，并通过云边隧道向 tunnel-edge 发送自定义协议消息用于与 SSH Server 建立 TCP 连接，类型为 connecting
-
tunnel-edge 向 SSH Server 发送建立 TCP 连接的消息 tunnel-edge 在接收到 connecting 类型的自定义协议消息之后根据消息中 SSH Server 的ip和 port 发送建立TCP连接的请求
-
SSH Server 返回 TCP 连接建立成功的消息给 tunnel-edge
-
Tunnel-edge 返回自定义协议消息(StreamMsg.Type 为 conneted)给 tunnel-cloud tunnel-edge 在收到连接建立成功的消息后向 tunnel-cloud 发送一个 TCP 连接已建立的类型 connected 的自定义协议的消息
-
tunnel-cloud 返回 SSH Client 状态为 200 的 reponse 消息 tunnel-cloud 在接收到 connected 的自定协议消息后会 SSH Client 返回一个状态码为 200的消息： HTTP/1.1 200 Connection established
-
SSH Client 向 tunnel-cloud 发送 SSH 协议的消息 SSH Client在接收到状态码为200的响应消息后，使用和 tunnel-cloud 已经建立的隧道发送 SSH 协议数据
-
tunnel-cloud 将 SSH 协议的消息封装为自定义协议消息(StreamMsg.Type 为 content)发送给 tunel-edge
-
tunnel-edge 将 SSH 协议消息通过TCP连接发送给 SSH Server
-
SSH Server 将 SSH 协议消息发送给 tunnel-edge
-
tunnel-edge 将 SSH 协议消息封装为 content 类型的自定义消息发送给 tunnel-cloud
-
tunnel-cloud 将 SSH 协议消息返回给 SSH Client
SSH登录节点
前置条件
安装 corkscrew，Mac 直接使用 brew 安装
brew install corkscrew
或者，安装netcat(centos)
yum install -y netcat
SSH 登录节点
SSH 登录边缘节点 node-A-1，可以使用下面的命令：
ssh -o ProxyCommand= "corkscrew masterIP cloud-port node-A-1 22" root@127.0.0.1
或者
ssh -o ProxyCommand= "nc -X connect -x masterIP:cloud-port node-A-1 22" root@127.0.0.1
- materIP: master 节点所在节点的外网ip
- cloud-port: NodePort 端口，对应的 SSH 模块的 Server 的端口 获取 cloud-port
kubectl -n edge-system get svc tunnel-cloud -o=jsonpath='{range .spec.ports[*]}{.name}{"\t"}{.nodePort}{"\n"}{end}' | grep ssh | awk '{print $2}'
总结
使用该方案，用户无需手动搭建，可以快速SSH登录边端节点，实施运维工作。同时本方案提供的隧道相对传统方案更便于维护且提高了稳定性，用户体验得到提升。
未来展望
支持从云端统一SSH 运维边缘节点是tunnel组件的增强功能，也是对 一文读懂SuperEdge云边隧道 的展望的实现，SuperEdge 开源之后社区小伙伴也对 tunnel 组件提了新的需求，大致如下：
- 支持云端 apiserver 访问边缘端的webhook server
- 支持服务之间的跨区域互访
合作和开源
云边隧道的SSH运维边缘节点的新特性已经在 SuperEdge release 0.4.0 开源，欢迎大家体验。我们也会持续提升 Tunnel 的能力，适用更加复杂的边缘网络场景，也欢迎对边缘计算感兴趣的公司、组织及个人一起共建 SuperEdge 边缘容器项目。