作者：杜怀宇

近期，由边缘计算产业联盟（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 进行开源贡献给社区，以便在边缘原生时代来临的当下，为大家提供一种新的技术选择。