OpenYurt 如何 “0 侵入” 攻破云边融合难点

做者 | 何淋波
来源|阿里巴巴云原生公众号

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

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

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

点击回看完整视频：https://developer.aliyun.com/live/246066

什么是边缘计算（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 定义实际上是相互依存，相互关联的。另外，边缘计算与云计算不是替代关系，而是相互补充、相互关联的关系。

2. 边缘计算行业趋势

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

趋势一：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超/远程会诊）等。

3. 边缘计算现状

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

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

• 第一，互联网智能终端设备数量的急剧增长；数据、业务下沉的诉求增多。

• 第二，边缘计算规模和业务复杂度提高，边缘智能、边缘实时计算、边缘分析等新型业务不断涌现。传统云计算中心集中存储、计算的模式已经没法知足边缘设备对于时效、容量、算力的需求。

• 第三，云边端协同难度大，缺乏统一的交付、运维、管控标准，且边缘服务和边缘数据的安全风险控制难度较高。

• 第四，异构资源支持困难，对不一样硬件架构、硬件规格、通讯协议的支持，以及基于异构资源、网络、规模等差别化提供标准统一的服务能力的挑战。

云边一体的边缘云原生

1. 什么是云原生？

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

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

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

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

• 第一块是新的应用负载，包括：数据&智能、分布式应用、DevOps，如今都是经过云原生承载业务。

• 第二块包括：Serverless、容器编排，是一个新的业务系统。

• 第三块包括：公共云、专有云、边缘云是一个新的资源承载系统。

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

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

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

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

4. 云边一体价值

云原生的概念最先是在 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 服务器上，作视频监控，好比一些省级、市县级的机房里面处理，作视频管理、汇聚转发等处理以后，把最后结果再上传到中心云上的云控平台。而后在云控平台能够作不少处理，好比能够跟高德地图来作一些事件的发布，或信息通知等等，造成云边端一体化的服务管理平台。

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

以上就是本次关于 OpenYurt 的分享，若是你们对 OpenYurt 感兴趣，欢迎扫码加入咱们的社区交流群，以及访问 OpenYurt 官网和 GitHub 项目地址：

• OpenYurt 官网：
  https://openyurt.io

• GitHub 项目地址：
  https://github.com/openyurtio/openyurt