云计算的出现促使物联网实现爆炸式增长。在设备规模和业务复杂度不断攀升的趋势之下，边缘计算因其能够将计算能力更靠近网络边缘和设备，从而带来云性能成本的降低，也在这波浪潮之下得到快速发展。

诚然，物联网边缘计算尚处发展初期，有许多挑战需要被解决。比如在大量软件及通信协议极为复杂的设备异构环境下，需要具备快速处理业务数据，并对异常情况作出快速响应的能力；另外，在大多数情况下，出于安全或其他考虑，边缘节点在物理上无法从云节点直接访问，使部署变得困难，也无法实现云到边缘的管理。这些问题都使业务的连续性、稳定性和可用性遭受威胁。

现在，企业和开发者通过开源社区就能够找到应对以上问题的解决方案。近日，OpenYurt 与开源项目 eKuiper 正式达成合作，完成了集成对接：从 v0.4.0 版本开始，OpenYurt 将正式支持部署和管理 eKuiper ，双方将共同帮助开发者轻松、高效地解决物联网边缘计算场景下流式数据处理和运维挑战。

1 eKuiper:轻量级 IoT 数据分析和流处理开源软件

物联网边缘计算很多场景下需要流式数据处理能力。所谓流数据是指一组顺序、大量、快速、连续到达的数据序列。一般情况下，流数据可被视为一个随时间延续而无限增长的动态数据集合，它可以帮助用户实时了解系统设备的状态，并对异常情况做出快速响应。

在边缘端，计算资源（CPU，内存等）不像在云端一般丰富，因此传统的流式数据处理框架类似于 Apache Spark 或者 Apache Flink 等，由于其安装包过大，或者部署结构与过程过于复杂、运行时的高消耗等原因，并不适合于在这些资源受限的边缘设备（工控机、网关，或者配置不高的 X86 或者 ARM 服务器等设备）上运行。而 eKuiper 就是为了解决在物联网边缘设备上的这些问题而设计开发。

eKuiper 的前身是由开源物联网数据基础设施软件供应商 EMQ 于 2019 年正式开源的 Kuiper 项目。2021 年 6 月，Kuiper 项目加入  LF Edge 基金会并更名为 eKuiper，开始作为独立的项目运营。eKuiper 的本质是一个轻量级物联网数据分析和流处理软件，可以运行在各类资源受限的边缘设备上，希望使边缘端的流式数据处理拥有如 Spark 与 Flink 的能力。

如下图所示，eKuiper 整体架构大致分为三部分：

• 左侧为 Sources，代表数据来源的位置，数据来源可能是 OpenYurt 里部署边缘端的 MQTT Broker，也可能是消息队列、文件和数据库等；

• 右侧为 Sinks，代表数据处理完成后所要存储的位置，也就是目标系统，目标可以是 MQTT，可以将其存到文件、数据库里面，也可以调用 HTTP 服务；

• 中间部分为 eKuiper 的运行时，最上层为数据业务逻辑处理，这个层面提供了 SQL 与规则解析器，SQL 处理器进行处理后并将其转化成 SQL 执行计划；下面层为流运行时和 SQL 运行时, 运行最终执行出来的执行计划；最底层为存储，存储在运行过程中需要持久化的一些信息。

在 eKuiper 中，用户可通过管理仪表板来管理一个或多个 eKuiper 实例。通常，这些仪表板部署在云节点中，用于管理跨多个边缘节点的 eKuiper 实例。正如前文所述，由于大多数情况下边缘节点在物理上无法从云节点访问， 使得部署变得困难，无法进行高效的 eKuiper 云边管理。

OpenYurt 则改变了这种情况。

2 OpenYurt：非侵入式的边缘云原生智能平台

云原生技术已经无处不在，并被应用于“新的应用负载” ，“新的计算形态”和“新的物理边界”。作为云原生的技术基石，容器和 Kubernetes 正在通过越来越多的计算形态承载，丰富的形态也开始从传统的中心云走向边缘计算、走向终端。

通常来说，边缘场景下计算规模庞大、业务复杂，采取原生 Kubernetes 的 workload 管理模型远不能满足现实中云原生边缘计算的落地需求；并且云边网络通过公网相连，网络连接有很大不可控因素，可能带来边缘业务运行的不稳定因素，而且由于边缘节点一般位于用户网络的防火墙内部，会造成云边网络只能单向连通的客观条件，给原生的 Kubernetes 运维监控带来很大挑战；最后，无可避免地要面对边缘资源种类的多样、异构，使边缘标准化支持面临困难。

OpenYurt 基于原生 Kubernetes 构建，是业界首个对 Kubernetes 无侵入的边缘计算云原生开源平台。OpenYurt 是阿里云容器服务产品 ACK@Edge 的核心框架，由阿里云于 2020 年 5 月以开源的方式反哺业界，并通过捐赠给 CNCF，实现更加中立、开放的社区环境，成为生态兼容场景下边缘云原生平台首选项目。

如下图所示，OpenYurt 的架构设计非常简洁，是一个典型的“中心-边缘”模式。在云端(K8s Master)上通过增加 Yurt Controller Manager, Yurt App Manager 以及 Tunnel Server 组件。而在边缘端(K8s Worker)上增加了 YurtHub 和 Tunnel Agent 组件：

这样的架构设计给边缘场景下的原生 Kubernetes 能力获得以下增强：

• 边缘单元化：通过 Yurt App Manager 组件，从单元化的视角，管理分散在不同地域的边缘资源，并对各地域单元内的业务提供独立的生命周期管理、升级、扩缩容、流量闭环等能力；且业务无需进行任何适配或改造

• 边缘自治: 因为每个边缘节点增加了具备缓存能力的透明代理 YurtHub，从而可以保障云边网络断开，如果节点或者业务重启时，可以利用本地缓存数据恢复业务

• 云边协同(运维监控)：通过 Tunnel Server/Tunnel Agent 的配合，为位于防火墙内部的边缘节点提供安全的云边双向认证的加密通道，即使边到云网络单向连通的边缘计算场景下，用户仍可运行原生 kubernetes 运维命令(如 kubectl proxy/logs/exec/port-forward/attach 等)。同时中心式的运维监控系统(如 prometheus, metrics-server 等)也可以通过云边通道获取到边缘的监控数据

• 云原生生态兼容：所有功能均是通过 Add-on 或者 controller 形式来增强 Kubernetes，因此保证对 Kubernetes 以及云原生社区生态的 100% 兼容；另外，OpenYurt 还提供了一个 YurtCtl 工具，可以用于原生 Kubernetes 和 OpenYurt 集群的一键式转换

简而言之，OpenYurt 使用户能够管理在边缘基础设施中运行的应用程序，就像它们在云基础设施中运行一样。

3 使用 OpenYurt 部署和管理 eKuiper

从 v0.4.0 版本开始，OpenYurt 项目正式支持部署 eKuiper 及其仪表板，用户可以利用 yurt- tunnel云边隧道，通过 eKuiper 的 Web 管理控制台实现对 eKuiper 实例进行配置管理，实现高效、轻量的 IoT 边缘流处理能力。

eKuiper 和 eKuiper Dashboard 组件采用原生 Helm Chart 直接部署，其中eKuiper 组件整个运行在边缘端，而 ekuiper Dashboard 运行在云端(管控端)。同时 OpenYurt 的 Yurt-Tunnel 组件通过 dns 和 iptables dnat 等机制，会自动拦截云边网络通信。因此 eKuiper 组件可以在对云边隧道无感知状态下完成云端对边缘端的指令下发。

基于以上方式，用户可以直接在 OpenYurt 平台上通过仪表板，在边缘场景下轻松管理 eKuiper，并且在浏览器中通过仪表板来及时查看服务是否健康：

4 社区合作规划

未来，双方还将面向 IoT 行业继续探索高效的云原生边缘中间件解决方案，并吸引更多轻量级 IoT 相关中间件加入 OpenYurt 生态，使边缘中间件真正以云原生的方式获得部署支持。此外，作为 eKuiper 的贡献者，EMQ 也将继阿里云、VMWare、Intel 后，正式成为由 OpenYurt 发起的云原生 IoT SIG 企业成员。

希望更多开发者支持并加入 OpenYurt 和 eKuiper 社区，共建面向云原生 IoT 开源生态。