关于边缘计算:火山引擎边缘计算在云边协同方面的探索与实践

作者:杜怀宇

近期,由边缘计算产业联盟(ECC)主办的2022边缘计算产业峰会(ECIS2022)以云端直播模式胜利举办,峰会以“边云智联 助力行业数字化转型”为主题,汇聚来自寰球的商业首领、国内组织、政府机构、产业搭档、学术大咖,全方位探讨边缘计算前沿学术与技术、摸索新兴技术与边缘计算的深度联合、展示边缘计算翻新利用、聚合边缘计算产业生态。火山引擎边缘计算平台研发专家杜怀宇也在大会的边缘原生分论坛分享了火山引擎边缘计算在云边协同方面的摸索与实际。本文依据演讲内容整顿。

  1. 边缘计算与云边协同
  2. 边缘计算场景下对管控零碎建设的挑战
  3. KubeHub-火山引擎边缘计算的数据通道计划
  4. 总结

1、边缘计算与云边协同

边缘的演进

在过来的十年中,随着音视频等互联网业务的倒退促使业务谋求更好地用户体验,而基于数据中心的私有云始终存在高时延问题,这就导致时延敏感型业务面临着用户体验的晋升瓶颈。同时,网络时延与物理间隔间接相干,因而将计算迁徙到数据中心之外,成为体验优化的不二之选,边缘计算也由此而来。

火山引擎把从用户到云核心之间所有的算力层都定义为 边缘计算 的领域,包含:现场边缘、近场边缘、云边缘三层,笼罩1-40ms时延范畴,别离提供从用户现场到本地城市节点和区域核心汇聚节点等多种异构算力资源, 并依据地理位置的散布,提供复线、多线等多种网络接入能力,确保用户就近接入,满足业务超低时延的算力调度和网络能力的需要。

云-边-端协同架构

为了更好的施展新基础设施的能力,技术解决方案也在继续演进。随着整个行业对边缘的了解加深,如何无效地开释边缘能力就成为了新的摸索方向。同时,在边缘计算畛域,原生的概念也成了热门探讨的话题。边缘原生与云原生理念不同之处在于,边缘原生理念下技术注意力更多地投向稳定性,安全性,以及云端与边缘的垂直扩大能力构建。

从理论需要角度来看,为了晋升用户体验,业务偏向于把算力卸载到边缘来升高服务时延,同时也会配合更多品种的硬件来辅助特定计算。这种形式催生出了一种可能混合调动多种资源的解决方案,也就是咱们当初称之为云-边-端协同的架构。在云-边-端协同的架构构想中,计算、流量、资源能够依照业务需要来灵便调度,甚至是无缝的平滑迁徙,最终会造成一种云和边缘之间的垂直扩大能力。

依靠云边协同的管控零碎

对于火山引擎边缘计算而言,在边缘原生的背景上来建设管控零碎时,就须要同时思考到基础设施的现状以及所服务的客户的技术诉求。例如:

  • 管控零碎,要能形象各种异构设施,并具备较强的资源纳管能力
  • 提供资源调动能力,要足够灵便足够易用,以便于帮忙业务向边缘原生的架构转变

而这些诉求,实际上反映地就是边缘计算中的云边协同问题,要实现云边协同,那么咱们就须要在资源,数据,和服务三方面都做到协同。在过往的私有云建设中,惯例的管控零碎,都具备资源调度,数据同步,和服务编排的能力,这三种能力从领域上其实是与云边协同的主张相响应的。过渡到边缘云时代,尽管根本模型并无太大出入,然而在边缘场景下,新基础设施的物理现状扭转了,这对于根本模型的实现提出新挑战。

其中最大挑战就是数据同步能力的建设。因为数据同步能力是管控零碎最底层的物理能力之一,这个能力会间接制约资源调度与服务编排的准确性与效率,甚至进一步影响整个体系的老本。因而,要先解决好数据同步的问题。

2、边缘计算场景下对管控零碎建设的挑战

规模宏大的节点网络

想做一个好的数据同步能力须要先解决以后面临的问题,以火山引擎边缘计算的基础设施为例,火山引擎边缘计算节点超过500个,覆盖全国各省市和运营商,同时资源储备带宽也超过100T。咱们的管控平台要去实时监测这么多资源,并且还要在呈现突发状况时要协同调动服务做躲避止损,这对数据同步而言是十分大的挑战,一方面管控零碎必须保障数据通道的稳固和通顺,另一方面须要尽可能思考和应答各种突发状况

丰盛的业务场景

另外一个维度的挑战来自于客户和业务。火山引擎边缘计算在正式凋谢前次要服务于抖音团体的外部业务,如抖音的直播以及音视频类业务。这些业务无一例外都对稳固与性能有极致谋求。当客户向管控平台收回指令,要求对资源做出治理时,如果零碎不能及时对客户的指令做出正当反馈会,其结果难以想象,所以这其实也是在向数据同步能力提出挑战。

云边数据通道该当具备的能力

综上,对于咱们来说,建设一个合乎边缘原生理念的管控平台是首要任务,而建设管控平台的首要外围问题就是要建设一套稳固的数据通道,之后在此基础上进一步去解决好整个云边协同问题。所以咱们决定投入精力先把数据通道问题做好。那么在布局的过程中,对这个计划该有的能力做了些构想:

  • 第一是性能,云边数据通道次要承载南北向的数据流动。而南向与北向的数据流动有非对称性,南向以指令数据为主,北向以数据上报为主。这两种流动咱们称之为命令通道与数据通道两种能力,须要在性能中体现。
  • 第二是性能,咱们的性能必须表现出色,具体来说,要思考时延稳定,高吞吐量,和高可用问题。
  • 第三扩展性,咱们起步较晚,但咱们要同时发展虚拟机和容器,甚至函数计算等多种业务,那么就能够尽早思考拓展性,设计一套欠缺计划以应答所有问题。
  • 第四是安全性,作为tob业务服务商,平安问题毋庸置疑,具体来说,至多要保障租户之间的隔离性以及数据传输平安

3、KubeHub-火山引擎边缘计算的数据通道计划

KubeHub-企业级云边网关

自2021年开始咱们将上述的想法逐渐落地,造成一套云边网关计划,在外部咱们称之为 KubeHub。这套计划的次要特点有四个方面:

  • 第一,代理式实现的云边网关,通过接管云边两端的数据转发,让通道的概念对业务变得通明,升高业务和架构研发的了解和应用难度。
  • 第二,充分考虑了理论场景,通过缓存+实时同步,对一部分读申请的减速,晋升了性能
  • 第三,基于业务的安全性要求,着重管控和平安能力建设
  • 第四,建设了与之配套的运维平台,加强对云边通道的即时干涉能力,并补全监控,告警等根底的可观测性机制。

KubeHub 架构

接下来跟大家具体介绍一下KubeHub的具体实现。

整体上看,KubeHub 由核心和边缘两侧的代理组件组成了一个对称式的架构。核心一侧的代理组件称为 Hub,边缘一侧的组件叫 Agent,两个代理合作散发核心与边缘之间的南北向流量。核心一侧还存在一个称为 metaserver 的组件,metaserver 是一个元数据中心,除了保护用户信息,集群拜访证书等数据之外,还会记录 hub,agent 的实例信息,以反对对 hub 和 agent 实例的服务发现。

KubeHub 外围性能

KubeHub 所提供能力分为三类。

  • 第一是外围性能,次要有:

    • 通过核心与边缘两侧的代理来维持业务通明的网络通道
    • 通过实时同步边缘数据来实现局部数据查问类指令的减速
  • 第二是运维相干的性能,次要有:

    • 云边通道的租户治理,包含用户的资源,身份受权,以及拜访权限校验
    • 另外是通过 metaserver 的元数据管理与服务注册能力,对于 hub 与 agent 的行为进行干涉,比方调整负载平衡,调度流量等等
  • 第三是扩大性能,次要会在边缘一侧发挥作用:比方,通过为 agent 开发 K8s 插件,以及本地 native 指令的组件,比方执行本地命令等等。咱们能够让管控零碎通过 KubeHub 间接治理 K8s 或裸金属集群,甚至调动一些如函数,大数据等更非凡的场景。

KubeHub 集群纳管

除了外围性能外,这里向大家介绍下 KubeHub 中的一些外围流程。首先,为了应用 KubeHub,须要先将集群接入到平台,这一步咱们也称之为集群纳管。一个规范的集群纳管流程是这样的:

  • 第一,咱们先要在边缘集群上装置 KubeHub 的边缘代理组件,即 agent。agent 的部署状态能够以容器或二进制模式存在,是比较简单的。
  • 第二,Agent 启动后,会向核心的 hub 发动 Websocket 链接,再与 hub 实现握手建连后,会进入到资源类型上报阶段。
  • 第三,在资源类型上报阶段,核心的 hub 实例会向边缘发动一个 Discovery 类型的探测申请,要求边缘 agent 上报集群反对的资源类型。
  • 最初,资源类型上报结束后,hub 会依据边缘集群的类型决定是否启用资源缓存,以 K8s 集群为例,hub 针对须要缓存的资源类型,会启动一组 Informer,通过 Informer 启动的 listwatch。agent 会将资源的 Event 同步到核心并缓存到 hub 中。

随后这些资源初始化全副实现后,Hub 就会向 MetaServer 去注册集群和 Agent 的信息。以上初始化过程是齐全自动化的,通过这套机制,咱们只须要在边缘集群部署一个 Agent 就能够实现集群的纳管。

KubeHub 指令下发

在集群实现纳管之后,使用者就能够开始通过 KubeHub 向边缘集群下发指令了。咱们以用户通过 KubeHub 治理边缘k8s集群的场景来举例。

首先,当用户通过 KubeHub 向边缘 K8s 集群下发指令时,须要先通过 MetaServer 去签发的一个对应集群的 Kubeconfig。MetaServer 在签发 Kubeconfig 之前会先核实租户身份并做资源权限校验,一旦通过用户就会失去一个与本人相干的惟一 Kubeconfig。一旦获取到 Kubeconfig,用户只须要将 K8s apiserver 的地址代理到 Hub 组件,能够就持续应用 kubectl、client-go 之类的传统形式,间接拜访边缘 K8s 集群。

因为用户发向边缘集群的申请曾经被代理至 hub 集群 。当 Hub 接管到 K8s 申请后会做指令类型判断。如果读申请,比方 Get/List/Watch 等,Hub 实例会查看本地是否具备对应资源的缓存,如果缓存命中,那么就将缓存数据间接返回给用户。如果申请未命中缓存,或者是一个写申请。比如说 Create/Update/Patch/Delete 类型,那么 Hub 会间接把这个申请发送至边缘侧的 Agent。由 Agent 再将这个申请转发到边缘的 APIServer,APIServer 将申请解决实现后,由 Agent 将后果返回给核心 Hub,而后再由 Hub 转交给用户。

这种设计其实思考了理论场景的,一般来说,申请的读写比往往遵循 2-8 准则,因而咱们通过在核心缓存热点资源的形式,缩小边缘 APIServer 压力,这样能够晋升边缘集群的一个稳定性,并缩小带宽开销。

KubeHub 高可用机制

作为一个底层基础设施。除了性能实现之外,KubeHub 必须思考高可用问题。在 KubeHub 中,咱们沿用了比拟经典的分布式架构。具体而言,就是通过多正本, 服务发现 ,流量 负载平衡 ,以及故障转移这些伎俩来实现 KubeHub 的数据通道高可用。

KubeHub 受权与认证

另外,KubeHub 也对筹备了一些平安机制。当租户应用 KubeHub 治理集群时,咱们会启用 rbac 鉴权,所有集群上的资源类型都能够按需受权给租户,这些信息都会记录在 MetaServer 中,并且通过签发 token 的形式给用户方法拜访凭证。当租户通过 KubeHub 下发指令时,Hub 会对 token 进行校验,检查用户身份以及资源权限的合法性。这是一种比拟轻量的平安校验形式,应用这种机制的是为了保障 KubeHub 的性能, 毕竟在高并发高负载的场景下,单次申请开销的渺小稳定会千里之行;始于足下,最终引起整体的性能衰减。

另一个对平安的思考是数据传输平安。在这里咱们 websocket 启用了 ssl 双向认证,由此建设平安的牢靠传输通道。

KubeHub 监控与运维

最初,作为基础性服务。咱们对监控和运维方面也做了一些投入,以保障能随时地掌控整个服务状况,并对一些突发问题做出疾速判断和应答。

具体来说,可观测性方面,次要是云和边两侧的根底性能,稳定性监控。另外,干涉能力上,咱们会对以后的租户,曾经租户所应用的各种客户端做出监测,并决定流量调度策略,甚至封禁。此外,对于工程方面的机制,比方多环境隔离,灰度等机制,这在企业中是惯例需要。

以上就是咱们的自建数据通道 KubeHub 的全貌。在以后,KubeHub 曾经作为外围组件比拟宽泛地利用到火山引擎的边缘管控体系中。在咱们的主营业务中,对 KubeHub 的应用十分广泛,比方对边缘虚拟机,虚拟化网络,存储等业务中,大量的资源控制指令都须要 KubeHub 下发至边缘。

从实际效果看,通过 KubeHub 建设的云边通道,稳定性还比拟牢靠,同时可观测性和运维能力都比较完善,极大地加重业务研发和产品迭代的累赘。

4、总结

最初,和大家一起来简略回顾下咱们建设 KubeHub 的过程。作为一家发展 To B 业务的云服务商,宏大且简单的基础设施治理以及品质和效率等因素要求咱们着眼理论状况,以求实的眼光来尽可能高质量地、有打算地解决问题。这是咱们投入力量,启动 KubeHub 我的项目的根本原因。

另一方面,随着边缘原生的衰亡,云与边之间的协同管制被作为根底能力会更加受到关注。咱们在启动边缘计算业务的时候也曾经意识到这一点,咱们感觉云边通道是一个值得独立探讨和深入研究的问题。因而咱们在云边通道方面投入了力量,并致力为他补全工业级场景所匹配的配套能力,心愿他可能施展足够的作用。

KubeHub 集中体现了咱们对云边数据通道的了解与性能诉求,但相比与业界流行的边缘计算开源计划,会显得比拟特地。从定位来讲,有别于开源社区的思路,KubeHub 不是一个全面的云边协同计划,而是专一于数据协同这个问题,谋求为数据协同建设一个比拟可靠的技术底座,其实现绝对更短小精悍,但在扩大机制上做了足够的思考,目标是为了作为一个强有力的根底工具。同时咱们在运维和管控上投入了很大精力,使其具备企业级的能力。

最初,再简略介绍下咱们建设 KubeHub 的要害里程碑。

  • 外围性能建设: KubeHub 我的项目自2021年初启动,通过为期半年的投入实现了0.1版本的建设,这期间理论是咱们对云边协同问题的思考积淀阶段,因而咱们设定的指标是实现最外围的高可用连贯和申请减速能力。
  • 平台化: 在外围性能疾速失去验证之后,咱们发现这是一个有价值的技术原型,因而在20年底,咱们为 KubeHub 补全了配套的运维和扩大能力,在这个过程中 KubeHub 被倒退成了一个根底技术平台,并且开始在公司外部的更多业务中都失去利用。
  • 产品化: 在22年,随着业务的倒退,KubeHub 的利用越来越宽泛,咱们发现他显著地体现出了技术基石的特质,这时候咱们感觉这样一个比拟重要的根底组件值得一个更有远见的倒退布局,因而咱们决定将 KubeHub 打造的更齐备,一方面,咱们持续打磨易用性和用户体验,另一方面咱们尝试与开源计划做更多的对接,特地是为云原生场景的适配做了一些筹备。

在将来的工夫里,咱们心愿在两方面能有停顿,一个是外部生态建设,在边缘原生时代,大量的利用都将会顺应潮流向边缘进行迁徙,而云边协同问题也将会是第一大挑战,因而咱们心愿在外部能推广 KubeHub,让大量的经典云利用能更繁难地向边缘过渡。另一个方面,咱们也心愿能和业界分享这些想法,并将 KubeHub 进行开源奉献给社区,以便在边缘原生时代降临的当下,为大家提供一种新的技术抉择。

【腾讯云】轻量 2核2G4M,首年65元

阿里云限时活动-云数据库 RDS MySQL  1核2G配置 1.88/月 速抢

本文由乐趣区整理发布,转载请注明出处,谢谢。

您可能还喜欢...

发表回复

您的电子邮箱地址不会被公开。 必填项已用*标注

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据