简介： 随着 5G、IoT、直播、CDN 等行业和业务的发展，越来越多的算力和业务开始下沉到距离数据源或者终端用户更近的位置，以期获得很好的响应时间和成本，这是一种明显区别于传统中心模式的计算方式——边缘计算。

随着 5G、IoT、直播、CDN 等行业和业务的发展，越来越多的算力和业务开始下沉到距离数据源或者终端用户更近的位置，以期获得很好的响应时间和成本，这是一种明显区别于传统中心模式的计算方式——边缘计算。

然而，在边缘计算的规模、复杂度正逐日攀升的同时，短缺的运维手段和运维能力也终于开始不堪重负。在这个背景下，“云、边、端一体化运维协同”已经开始成为一种架构共识。通过云原生加持，云边融合的进程也正在被急剧加速。在这样的趋势下，引入云原生理念、全面转型边缘应用的运维管理模式成为亟需解决的问题。

本文整理自作者阿里云容器服务技术专家，OpenYurt 作者 & 初创人员之一何淋波（新胜）于 1 月 26 日在阿里云开发者社区“周二开源日”的直播分享，将站在实际落地场景的角度，探索云原生技术和边缘计算的融合挑战，详细介绍基于 OpenYurt 的云原生边缘计算平台架构和行业实践。

什么是边缘计算（Edge Computing)

边缘计算是相对传统集中通用计算而言，指将工作负载部署在边缘的一种计算方式。最近几年，边缘计算非常火热，主要是因为 5G、IoT 等业务和场景发展越来越快，包括智能终端设备越来越多，造成对边缘计算业务的下沉诉求越来越多。如果所有的处理全部放在中心，很难满足大规模边缘智能设备的增长。边缘计算目前在各行各业都开始大规模使用，例如汽车、运输、能源等。总结来说，边缘计算就是让计算离用户或者离数据源更近。

1. 边缘计算顶层架构

============

业界定义的边缘计算的分层结构，主要引用 Gartner、IDC。

Gartner 定义的分层结构如下图所示：Endpoint > Near edge > Far edge > Cloud > Enterprise。

• Near Edge ：非标准服务器或设备，在距离端侧最近的地方。
• Far Edge ：标准的 IDC，可以分三种类型：IDC（为主）、MEC、CDN 等；相对来说，计算能力比较强，比如运营商的机房、云服务提供商的级联机房等等。
• Cloud ：公共云或专有元服务，特征为资源集中、中心化管理。

IDC 定义的分层结构如下图所示：

• Heavy Edge：数据中心维度；集中式计算平台；CDN，自建 IDC。
• Light Edge：低功耗计算平台，适用于工业控制，数据处理、传输等物联网场景。
• 由上图可以看出，Gartner 定义与 IDC 定义其实是相互依存，相互关联的。另外，边缘计算与云计算不是替代关系，而是相互补充、相互关联的关系。

1. 边缘计算行业趋势

============

边缘计算行业趋势可以从以下三个方面（维度）来讲：第一是行业的业务，第二是行业的架构，第三是行业的规模与变化。

趋势一：AI 、IoT 与边缘计算的融合

近几年来，边缘计算和 AI、IoT 的结合非常多，边缘智能设备的数量增加之后，包括所有的数据或视频全部回传到云端去处理，整个成本与效率都非常不合适，所以直接靠近设备这一侧进行 AI 处理或 IoT 处理的需求越来越多。比如 AI，会在云上或在中心云做训练，然后在边缘做推理，有非常多这种形式。调查显示：

• 到 2024 年，有 50% 的计算机视觉和语音识别模型将在边缘运行。
• 到 2023 年，近 20% 用于处理 AI 工作负载的服务器部署在边缘侧。
• 到 2023 年，中国 70 ％ 的物联网项目将包含 AI 功能，追求实时性、降低带宽、数据合规。
• 到 2023 年，中国 75 ％ 的企业将在网络边缘对物联网数据进行处理。

趋势二：云延伸，IT 去中心化，设施自治，边缘托管

边缘计算跟云计算是相互补充、相互依赖的关系。再延伸一步说，边缘计算其实是云计算往边缘的一个延伸，把云上的一些能力往边缘上延伸。一是要求 IT业务在边缘这一侧去中心化，另外因为边缘业务或设施是自治的，云和边之间网络断开的情况下，有一定控制能力，再有边缘托管能力。未来架构趋势将向云延伸、IT 中心化、设施自治、边缘托管的发展路线演进：

• 混合云 - 到 2023 年， 10% 的企业负载将运行位于本地数据中心和边缘资源上。
• 去中心化 - 到 2023 年，超过 30% 新基础架构将部署在边缘位置。
• 设施自治 - 到 2024 年，50% 核心企业数据中心和 75% 主要边缘 IT 站点将改变运维方式。
• 边缘托管 - 到 2022 年，50% 的公司将依靠托管服务来提高基于边缘人工智能的性能和投资回报率。

趋势三：5G 与边缘计算引爆新增长

最近几年，5G 的快速发展，对边缘计算是一个新的增长引爆点。预计到 2024 年,边缘应用程序的数量将增长 800% ，可以想象这个行业后面会是什么样的增长情况。典型应用场景将包括车联网（自动驾驶/车路协同）、智能电网（设备巡检/精准负荷控制）、工业生产控制、智慧医疗（远程B超/远程会诊）等。

1. 边缘计算现状

==========

边缘云促使管理的复杂性迅速上升

随着边缘计算的形态、规模、复杂度的日益增长，边缘计算领域的运维手段、运维能力越来越难以满足边缘业务的创新速度；而“未来企业都在全力追求超规模、超高速、超连接”，又进一步加剧运维管理的复杂度。边缘云促使管理的复杂性迅速上升，主要来自以下四个方面：

• 第一，互联网智能终端设备数量的急剧增加；数据、业务下沉的诉求增多。
• 第二，边缘计算规模和业务复杂度提升，边缘智能、边缘实时计算、边缘分析等新型业务不断涌现。传统云计算中心集中存储、计算的模式已经无法满足边缘设备对于时效、容量、算力的需求。
• 第三，云边端协同难度大，缺少统一的交付、运维、管控标准，且边缘服务和边缘数据的安全风险控制难度较高。
• 第四，异构资源支持困难，对不同硬件架构、硬件规格、通信协议的支持，以及基于异构资源、网络、规模等差异化提供标准统一的服务能力的挑战。

云边一体的边缘云原生

1. 什么是云原生？

===========

云原生的定义：云原⽣是一套开放、标准的技术体系。基于云原生技术体系，可以为用户敏捷的构建和运行高弹性、容错性好、易于管理的一套业务系统。整个技术体系有很多热门技术，如 Cloud Native、Serverless、Kubernetes、Container、Docker 等等，业界广泛使用的这些技术。

现在各大云厂商、云服务提供商都在大力投入云原生，云原生也越来越成为广大用户使用云计算能力的入口。云原生技术体系能够帮助企业最大化利⽤云的能⼒，最大化发挥云的价值。

1. 丰富的云原生产品家族

==============

以阿里云为例，云原生产品家族主要分三块，如下图所示：

• 第一块是新的应用负载，包括：数据&智能、分布式应用、DevOps，现在都是通过云原生承载业务。
• 第二块包括：Serverless、容器编排，是一个新的业务系统。
• 第三块包括：公共云、专有云、边缘云是一个新的资源承载系统。

1. 云边一体云原生基础设施

===============

云边一体云原生基础设施，是在云端做管控、边缘自治的云原生系统。如下图所示：

在中心这一侧，可以提供原生的云中心的管控能力和产品化能力，例如利用 Kubernetes+存储/+AI/+大数据等能力可以在中心提供出来；中心的这些能力通过管控通道，下沉到边缘计算，比如标准化的 CDN、 Infrastructure 、Edge、ENS，或者是上图右边的智慧工厂、智慧园区、楼宇、机场等等的设备网关；在边缘，可以就近接入各种设备，比如传感器、视频、控制器等等，可以支持各种通讯设备接入。这样便形成了云边端一体化的云原生基础设施。

云计算擅长需要海量可扩展存储能力，非实时且周期相对较长的数据处理和分析，而边缘计算脱胎于云计算，它擅长的是局部短周期数据的实时处理和分析，云计算与边缘计算之间不是替代关系，而是互相协同的关系，二者之间紧密结合才能更好地满足各种需求场景的匹配。

1. 云边一体价值

==========

云原生的概念最早是在 2013 年被提出，经过这几年的发展，尤其是从 2015 年 Google 牵头成立 CNCF 以来，云原生技术开始进入公众的视线并逐渐演变成包括 DevOps、持续交付、微服务、容器、基础设施，Serverless，FaaS 等一系列的技术，实践和方法论集合。云原生加速了多云、云边融合，云边一体的价值是：

• 一是可以为用户在任何基础设施上提供和云上一致的功能和体验，实现云边端一体化的应用。
• 二是可以利用容器的隔离性，利用系统的流量控制、网络策略等能力，保证运行在边缘上业务的安全性。
• 三是通过容器化，通过容器和资源之间的解耦，对异构资源的支持上能够有很好的适配。

5. 云原生与边缘计算融合难点

随着边缘计算的形态、规模、复杂度的日益增长，边缘计算领域的运维手段、运维能力越来越难以满足边缘业务的创新速度；而未来企业都在全力追求“超规模、超高速、超连接”，又进一步加剧运维管理的复杂度。

云原生与边缘计算融合要解决什么问题？在实际的解决问题的过程中，总结出以下 4 个关键点：

第一点：边缘计算规模和业务复杂，边缘资源的分散在不同地域，各个区域内部的边缘应用的生命周期管理，升级，扩缩容，区域内部流量闭环都面临挑战。

举个例子，比如 CDN 场景，全国各地可能有成百上千个机房，每个机房的资源或者机器可能都不一样，机器上面运行的业务承载的流量可能也不太一样。这时如果是用原生 Kubernetes 的 workload 来管理是非常不足的，会形成非常大的挑战，容易出错，整个运维效率非常低。

第二点：云边网络连接不可靠。通常情况下，云和边之间会通过公网连接，在一些客观因素的影响下，云边之间的网络可能出现断联，对边缘业务的持续运行形成很大挑战。因为网络断开的情况下，节点会脱离云端管控，在原生K8s下会对该Pod进行驱逐。但实际情况下无论是业务重启还是机器重启，都需要保证边缘业务可以持续运行。因此边缘需要一定的自治能力。

第三点：云边端运维协同难度大，由于边缘的机器是部署用户防火墙内部的，公网无法主动连接。因此，一些需要从中心拉取数据的K8s原生运维能力就无法使用，造少缺少统一的交付、运维、管控标准，且边缘服务和边缘数据的安全风险控制难度较高。

第四点：异构资源支持困难，对不同硬件架构、硬件规格、通信协议的支持，以及基于异构资源、网络、规模等差异化提供标准统一力的挑战。

OpenYurt 边缘计算云原生平台

CNCF 边缘云项目 OpenYurt：延伸原生 Kubernetes 到边缘计算的智能开放平台。

1. 边缘自治、中心（云）管控

OpenYurt 架构是非常简洁的云边的一体化的架构，如上图所示，云上有蓝色和橙色两部分，蓝色部分是原生 K8s 的一些组件，然后橙色部分是 OpenYurt 的组件；边缘的每个节点上，Edge Note 上每个节点上也有蓝色的部分和橙色的部分,蓝色部分也是原生的 K8s 的组件，或者设置的一些云原生的一些组件，橙色部分是 OpenYurt 的组件。

大家能看到 OpenYurt 对 K8s 或者对云原生的这种原生的架构是 0 修改、非侵入式的，OpenYurt 项目是业界首个非侵入式增强 K8s 的一个边缘计算云原生平台。其他的边缘计算云原生项目，或多或少可能都对 K8s 做了一定的修改或者裁剪，这也是 OpenYurt 最大的区别，因此也就保证了 OpenYurt 的标准化。

• OpenYurt 可以紧跟 Kubernetes 版本升级节奏。
• 非侵入式的理念，OpenYurt 与云原生主流技术，如 ServeiceMesh、Serverless 等，可以同步衍进。

OpenYurt 在 2020 年 9 月份进入 CNCF sandbox，是一个非常中立的项目，一是技术、架构上的中立，二是这个项目运营上的中立。

OpenYurt 的品质和稳定性也是有保障的，在阿里集团内部，使用非常广泛，已经管理数百万核的规模。

2. OpenYurt 如何解决原生与边缘计算融合难点

• 第一，边缘单元化。大规模业务下，因为边缘单元分比较分散，因此通过边缘单元化，对单元内业务进行一个单元化的管理以及流量闭环的管理。
• 第二，边缘自治能力。为了应对云边网络不可靠，通过给边缘增加一个自治的能力，云边网络断开的情况下，也可以保证的业务可以持续运行。
• 第三，无缝转换。主要是为了降低 OpenYurt 的使用门槛，通过提供一个无缝转换的能力，使 K8s 与 OpenYurt 集群之间可以一键式切换，一条命令可以把一个标准的 K8s 集群转换成 OpenYurt 集群，反向切换也可以，这也是业界首创的能力。
• 第四：是解决云端访问主动访问边缘的问题，提供了云边协同的能力来解决运维的难题。

下面，针对每一个能力具体介绍。

1）单元化能力

提供边缘场景下应用模型能力，主要包括以下三点：

• NodePool 可以对节点做单元化批量管理。
• 流量管理支持原生 service 的流量拓扑管理。
• UnitedDeployment 提供原生 APPs 模型单元化部署。

单元化主要是提供边缘场景下应用模型的能力，在资源这块提节点池，可以对每一个地域的一个节点，进行一个池化的管理，如上图边缘单元一，假如是北京的一个机房，这些节点都可以放到北京池里面，可以对这些节点进行一个批量化的标签等功能统一的管理，这样就相同的一批机器整体特性管理操作起来就非常方便。UnitedDeployment 这个资源是基于节点池，以节点池为单元，对节点池的业务进行部署管理。

根据上图举例，单元一部署两个实例，单元二部署三个实例，把配置提交给 OpenYurt 集群之后，就可以自动把部署信息下发到边缘，然后可以启动相对应的实例数，这就解决了单元管理的时每个单元独立去操作的问题，通过一个统一的视角，UnitedDeployment 可以管理各个单元。

2）边缘自治能力

为边缘业务持续运行护航，具体包括以下两点：

• YurtHub 缓存云端的数据，云边断网时，所有系统组件均从 YurtHub 获取数据。
• Yurt-Controller-Manager 解决云边网络连接不稳定时造成的边缘业务驱逐问题。

边缘自治能力为边缘业务持续运行护航，在云边网络断联的情况下，也可以保证边缘业务持续运行。主要涉及到两个组件，一个是 YurtHub，一个是 Yurt-Controller-Manager。

YurtHub 是部署在边缘节点上，每个节点上以容器化的形式部署的一个组件， 通过上图，了解处理流程，从请求 Kubelet、KubeProxy、Flannel 这种原生组件，之前都是直接连的云端 APIServer，现在调整为先连 YurtHub 再把请求转发给 APIServer。

这样的优点就是当请求过来之后，云边网络没有断开的情况下，有一个 health check 模块，会检测云边网络的连通性，如果云边网络正常，请求就直接到负载均衡模块，然后选择一个云端服务器转发过去，结果返回，一个是可以返回一个请求端，另外一个结果数据缓存在本地磁盘，持续化在本地磁盘。

如果云边网络断开了，节点要重启，网络断开的情况下，它可以通过 local proxy 把本地缓实际化的数据提取出来，返回一个请求方，从而恢复边缘的业务，保证边缘业务的一个持续运行。

3）无缝转换能力

无缝转换能力是用 yurtctlconvert 组件完成。主要用于标准 K8s 和 OpenYurt 集群之间的一键式转换；目前支持 minikube，kubeadm，ack 等工具部署的集群。

当转换的情况下，因为集群里面有很多节点，每个节点要转成边缘节点，就往边缘上部一些 yurthub static pod 组件，kubelet 参数修改等。如下图所示：

通过阿里另外一个云原生开源项目 OpenKruise 的 broadcastJob，可以保证在每个节点上运行 pod 这样一个 job，来完成每个节点到节点的转换。目前我们 Yurtctl 工具，在 minikube，kubeadm，ACK 等工具部署的集群上，进行了比较完整的验证，后续会支持更多类型的集群，也欢迎更多感兴趣的同学在社区做贡献。

4）云边协同能力

如下图所示：

在云端部署 YurttunnelServer 组件，边缘每个节点会部署一个 Yurttunnel Agent，Yurttunnel Agent 启动时由里面的 ANP Proxy Agent 模块，通过公网云端与 ANP Proxy server 模块建立双向认证的加密通道。这个通道是 gRPC 协议来做的。

通道建立之后，云端访问节点的时候，Yurttunnel Server 里面的 iptable manager 会把节点访问的请求流量导入到 Yurttunnel Server 上，request Interceptor 拦截器模块会把请求拦截过来，要转化成 gRPC 通信协议格式，然后把这个请求转发给边缘端的 TunnelAgent，TunnelAgent 再把请求转发给 Kubelet 或者 pod。这样的话，就打通了云边运维协同能力。使原生的 Kubernetes 运维操作能力，都可以无感知地运行在 OpenYurt 集群或云边场景上。另外云边运维通道基于 gRPC 种协议，通过压缩 Tunnel 带宽可以大大降低成本，相比原生 TCP 通信最大减少 40% 流量。

OpenYurt 案例介绍

案例一：边缘 AI

第一个案例是边缘 AI 场景，这个是盒马鲜生的新零售线下业务。

盒马鲜生基于阿里云容器服务 ACK@Edge 产品为底座，进行了云原生的转型升级，构建了一个“人货场”数字化全链路的云、边、端一体化协同的天眼 AI 系统。首先在云上有一个云端的控制面，然后在边缘离门店比较近的区域，购买了 ENS 节点服务，这样就不用自己为门店构建机房，然后通过云边一体系统把门禁控制系统或者建模系统，部署到边缘的 ENS 服务上，之后跟门店里面的监控视频流推送，然后业务承载之后进行分析，得到结果，在控制业务系统这边，把计算的结果返回到云端做分析。

基公云于云+边缘的形式，低成本的实现了云端天眼系统、阿里云边缘汇聚节点 ENS、盒马门店物理场的业务架构，具备强大的弹性能力、混合资源管理能力、以及云原生的运维能力。实现新门店开服效率提升 70%，和 50% 以上的资源成本节省；共享算力。如下图所示：

案例二：视频上云

视频上云案例，现在全国各地用的特别多，如图所示：

从下往上看，比如在高速上，轻量型网关或标准型网关，会有一些视频拍摄流，把这些视频拍好之后，传到离边缘比较近的 ENS 或 CDN 服务器上，做视频监控，比如一些省级、市县级的机房里面处理，做视频管理、汇聚转发等处理之后，把最后结果再上传到中心云上的云控平台。然后在云控平台可以做很多处理，比如可以跟高德地图来做一些事件的发布，或信息通知等等，形成云边端一体化的服务管理平台。

通过云边端一体化的服务管理平台包括：应用部署/配置、设备/应用状态、结构化数据上云的实现，使整个运维效率、管控效率都大大提升。

作者：何淋波

本文为阿里云原创内容，未经允许不得转载