您的位置:首页 > 运维架构

SuperEdge 云边隧道新特性:从云端SSH运维边缘节点

2021-07-06 17:21 671 查看

背景

在边缘集群的场景下边缘节点分布在不同的区域,且边缘节点和云端之间是单向网络,边缘节点可以访问云端节点,云端节点无法直接访问边缘节点,给边缘节点的运维带来很大不便,如果可以从云端SSH登录到边缘节点可以简化节点的运维工作。针对这一需求,SuperEdge 项目扩展了 tunnel 组件的能力,新增了 SSH 模块,让用户可以从云端 SSH 登录到边缘节点。

需求分析

边缘集群的节点分布在不同的区域,边缘节点能够访问云端 master 节点,但 master 节点无法访问边端区域内的节点,用户希望通过访问 master 节点的端口 SSH 登录到节点实施运维工作。

常规方案

使用 SSH 端口转发技术可以实现 SSH 运维边缘节点功能,具体内容如下图所示:

  1. 边缘节点 node-A 和 node-B 通过 SSH 的远程转发(ssh -R)将云端 master-A 节点的 port-A 和 port-B 端口与本地22端口(SSH Server 的端口)绑定
  2. user 通过SSH的动态转发(ssh -D)与 master-A 建立 SSH 隧道同时在本地监听 local-port 端口
  3. 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 方案

架构设计

  1. SSH Client 请求 tunnel-cloud service 暴漏到外网的 NodePort-1 端口,service 根据负载均衡策略将请求转发 tunnel-cloud pod-A 或 tunnel-cloud pod-B。
  2. 如果请求转发到 pod-A(R.1.1),由于 node-A 没有和 pod-A 建立隧道,pod-A 会查询 coredns 获取与 node-A 建立隧道的 pod-B 的 podIp,然后将请求转发到 pod-B(R.1.2)
  3. pod-B 收到请求后将请求通过隧道转发到 node-A 的 tunnel-edge,tunnel-edge 将请求转发到 SSH Server。

本方案的优势

  • 在云端和边缘节点间的隧道不会映射端口,避开端口管理。
  • 减少了请求过程中的建立连接数,减少了出错的概率
  • 云端和边端的隧道具备断开重连机制,降低维护成本

云边隧道的建立

使用 gRPC 开源项目搭建长连接隧道,gRPC 实现断开重连机制。

  1. tunnel-edge 向 tunnel-cloud 发送建立 gRPC 连接的请求 tunnel-edge 在向 tunnel-cloud 的 NodePort-2 发送建立连接的请求,请求中携带了所在节点的节点名和 token 信息,tunnel-cloud service 根据负载均衡策略将请求转发到 tunnel-cloud pod,如图3所示,将请求转发到 tunnel-cloud pod-B
  2. tunnel-cloud 向 coredns 注册本 pod 的 podIp 和 tunnel-edge 所在的节点的节点名信息 tunnel-cloud 验证 tunnel-edge 请求信息中的 token 信息,验证通过后,节点请求信息中的节点名和本 pod的 podIp 写入到 coredns
  3. tunnel-cloud 返回 gRPC 连接建立成功的消息
  4. tunnel-edge 和 tunnel-cloud 之间通过 gRPC 长连接发送自定义协议消息 StreamMsg 关于自定义协议消息的字段定义请参考 一文读懂SuperEdge云边隧道

tunnel-cloud 转发的实现

  1. 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

  2. tunnel-cloud 向 tunnel-edge 发送自定义协议消息(StreamMsg.Type 为 connecting) tunnel-cloud 会根据 HTTP CONNECT 的请求信息中获取云端和边端节点的隧道,并通过云边隧道向 tunnel-edge 发送自定义协议消息用于与 SSH Server 建立 TCP 连接,类型为 connecting

  3. tunnel-edge 向 SSH Server 发送建立 TCP 连接的消息 tunnel-edge 在接收到 connecting 类型的自定义协议消息之后根据消息中 SSH Server 的ip和 port 发送建立TCP连接的请求

  4. SSH Server 返回 TCP 连接建立成功的消息给 tunnel-edge

  5. Tunnel-edge 返回自定义协议消息(StreamMsg.Type 为 conneted)给 tunnel-cloud tunnel-edge 在收到连接建立成功的消息后向 tunnel-cloud 发送一个 TCP 连接已建立的类型 connected 的自定义协议的消息

  6. tunnel-cloud 返回 SSH Client 状态为 200 的 reponse 消息 tunnel-cloud 在接收到 connected 的自定协议消息后会 SSH Client 返回一个状态码为 200的消息: HTTP/1.1 200 Connection established

  7. SSH Client 向 tunnel-cloud 发送 SSH 协议的消息 SSH Client在接收到状态码为200的响应消息后,使用和 tunnel-cloud 已经建立的隧道发送 SSH 协议数据

  8. tunnel-cloud 将 SSH 协议的消息封装为自定义协议消息(StreamMsg.Type 为 content)发送给 tunel-edge

  9. tunnel-edge 将 SSH 协议消息通过TCP连接发送给 SSH Server

  10. SSH Server 将 SSH 协议消息发送给 tunnel-edge

  11. tunnel-edge 将 SSH 协议消息封装为 content 类型的自定义消息发送给 tunnel-cloud

  12. 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 边缘容器项目。

>【腾讯云原生】云说新品、云研新术、云游新活、云赏资讯,扫码关注同名公众号,及时获取更多干货!! ![](https://img2020.cnblogs.com/other/2041406/202107/2041406-20210706172122820-638108027.png)
内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签: