一文读懂 SuperEdge 云边隧道

作者李腾飞,腾讯容器技术研发工程师,腾讯云TKE后台研发,SuperEdge核心开发成员。杜杨浩,腾讯云高级工程师,热衷于开源、容器和Kubernetes。目前主要从事镜像仓库,Kubernetes集群高可用&备份还原,以及边缘计算相关研发工作。SuperEdge 介绍SuperEdge 是 Kubernetes 原生的边缘容器方案,它将 Kubernetes 强大的容器管理能力扩展到边缘计算场景中,针对边缘计算场景中常见的技术挑战提供了解决方案,如:单集群节点跨地域、云边网络不可靠、边缘节
摘要由CSDN通过智能技术生成

作者

李腾飞,腾讯容器技术研发工程师,腾讯云TKE后台研发,SuperEdge核心开发成员。

杜杨浩,腾讯云高级工程师,热衷于开源、容器和Kubernetes。目前主要从事镜像仓库,Kubernetes集群高可用&备份还原,以及边缘计算相关研发工作。

SuperEdge 介绍

SuperEdge 是 Kubernetes 原生的边缘容器方案,它将 Kubernetes 强大的容器管理能力扩展到边缘计算场景中,针对边缘计算场景中常见的技术挑战提供了解决方案,如:单集群节点跨地域、云边网络不可靠、边缘节点位于 NAT 网络等。这些能力可以让应用很容易地部署到边缘计算节点上,并且可靠地运行,可以帮助您很方便地把分布在各处的计算资源放到一个 Kubernetes 集群中管理,包括但不限于:边缘云计算资源、私有云资源、现场设备,打造属于您的边缘 PaaS 平台。SuperEdge 支持所有 Kubernetes 资源类型、API 接口、使用方式、运维工具,无额外的学习成本,也兼容其他云原生项目,如:Promethues,使用者可以结合其他所需的云原生项目一起使用。项目由以下公司共同发起:腾讯、Intel、VMware、虎牙直播、寒武纪、首都在线和美团。

云边隧道的架构与原理

在边缘场景中,很多时候都是单向网络,即只有边缘节点能主动访问云端。云边隧道主要用于代理云端访问边缘节点组件的请求,解决云端无法直接访问边缘节点的问题。

架构图如下所示:

实现原理为:

  • 边缘节点上 tunnel-edge 主动连接 tunnel-cloud service,tunnel-cloud service根据负载均衡策略将请求转到 tunnel-cloud pod

  • tunnel-edgetunnel-cloud 建立 gRPC 连接后,tunnel-cloud 会把自身的podIp和 tunnel-edge 所在节点的 nodeName 的映射写入 tunnel-dnsgRPC 连接断开之后,tunnel-cloud 会删除相关 podIp 和节点名的映射

而整个请求的代理转发流程如下:

  • apiserver 或者其它云端的应用访问边缘节点上的 kubelet 或者其它应用时,tunnel-dns 通过 DNS 劫持(将 HTTP Request 中的 host 中的节点名解析为 tunnel-cloud 的podIp)把请求转发到 tunnel-cloud 的pod上

  • tunnel-cloud 根据节点名把请求信息转发到节点名对应的与 tunnel-edge 建立的 gRPC 连接上

  • tunnel-edge 根据接收的请求信息请求边缘节点上的应用

Tunnel 内部模块数据交互

在介绍完 Tunnel 的配置后,下面介绍 Tunnel 的内部数据流转:

上图标记出了 HTTPS 代理的数据流转,TCP 代理数据流转和 HTTPS 的类似,其中的关键步骤:

  • HTTPS Server -> StreamServer:HTTPS Server 通过 Channel将 StreamMsg 发送给 Stream Server,其中的 Channel 是根据 StreamMsg.Node 字段从 nodeContext 获取 node.Channel

  • StreamServer -> StreamClient: 每个云边隧道都会分配一个 node 对象,将 StreamClient 发送到 node 中的 Channel 即可把数据发往 StreamClient

  • StreamServer -> HTTPS Server: StreamServer 通过 Channel 将 StreamMsg 发送给 HTTPS Server,其中的 Channel 是根据 StreamMsg.Node从nodeContext 获取 node,通过 StreamMsg.Topic 与 conn.uid 匹配获取 HTTPS 模块的 conn.Channel

nodeContext 和 connContext 都是做连接的管理,但是 nodeContext 管理 gRPC 长连接的和 connContext 管理的上层转发请求的连接(TCPHTTPS)的生命周期是不相同的,因此需要分开管理

Tunnel 的连接管理

Tunnel 管理的连接可以分为底层连接(云端隧道的 gRPC 连接)和上层应用连接(HTTPS 连接和 TCP 连接),连接异常的管理的可以分为以下几种场景:

gRPC 连接正常,上层连接异常

以 HTTPS 连接为例,tunnel-edge 的 HTTPS Client 与边缘节点 Server 连接异常断开,会发送 StreamMsg (StreamMsg.Type=CLOSE) 消息,tunnel-cloud 在接收到 StreamMsg 消息之后会主动关闭 HTTPS Server与HTTPS Client 的连接。

gRPC 连接异常

gRPC 连接异常,Stream 模块会根据与 gPRC 连接绑定的 node.connContext,向 HTTPS 和 TCP 模块发送 StreamMsg(StreamMsg.Type=CLOSE),HTTPS 或 TCP 模块接收消息之后主动断开连接。

Stream (gRPC云边隧道)

func (stream *Stream) Start(mode string) {
    context.GetContext().RegisterHandler(util.STREAM_HEART_BEAT, util.STREAM, streammsg.HeartbeatHandler)
    if mode == util.CLOUD {
        ...
        //启动gRPC server
        go connect.StartServer()
        ...
        //同步coredns的hosts插件的配置文件
        go connect.SynCorefile()
    } else {
        //启动gRPC client
        go connect.StartSendClient()
        ...
    }
    ...
}

tunnel-cloud 首先调用 RegisterHandler 注册心跳消息处理函数 HeartbeatHandler SynCorefile 执行同步 tunnel-coredns 的 hosts 插件的配置文件,每隔一分钟(考虑到 configmap 同步 tunnel-cloud 的 pod 挂载文件的时间)执行一次 checkHosts,如下:

func SynCorefile() {
    for {
        ...
        err := coreDns.checkHosts()
        ...
        time.Sleep(60 * time.Second)
    }
}

而 checkHosts 负责 configmap

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 1
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值