作者：赵震，深信服云计算开发工程师，OpenYurt 社区 Member
编者案：在 5G、物联网等新技术的持续推动下，边缘计算产业已然走向大风口，未来越来越多的种类，越来越大的规模和越来越复杂的应用和工作负载都会被部署到边缘侧。本文基于深信服云计算工程师赵震在由 CNCF 和阿里云联合举办的云原生容器领域开发者沙龙 KubeMeet 中的分享整理，介绍了边缘计算落地的机遇与挑战，以及边缘容器开源项目 OpenYurt 在企业生产环境下的实践方案。
本次分享是偏重于实践的案例，主要是关于 OpenYurt 产品在真实落地情况下的方案是怎么部署的。
主要从 4 个方面来进行，首先是关于边缘计算遇到的机遇和挑战都有哪些，第二部分就是深信服平台针对这些挑战做了哪些解决方案，可以让用户更好地使用边缘计算的东西。第三部分是方案和 OpenYurt 的落地结合，有哪些要点要去做落实的。最后一部分是针对整个行业的未来展望，以及社区未来发展做一些期许。
边缘计算的机遇与挑战
伴随着 5G 的到来以及直播和物联网的产生，越来越多的边缘设备已经被大家所使用，产生的数据也非常庞大。比如智能终端的一个 1080p 的视频监控头，每分钟就会产生 10GB 的数据。在一个中小型城市，这种摄像头有 100 到 150 万个，而且还在不断增加。在这样一个边缘场景下，它的数据应用是非常庞大的。
万物互联的时代，产生了很多智能家居，它们除了简单的接入网关之外，还有很多数据需要处理，这部分也是边缘侧的应用场景。
以上都是我们遇到的机遇，那挑战是什么？
对于一些传统行业而言，他们的云计算可能是很小的，比如市面上有很多私有云场景、政府专有云场景，他们不足以做到像大厂商那些云计算一样无限的扩容来做很多计算处理。目前的市场环境下，云和端的环境非常不理想，主要原因有以下几个方面。
第一，因为端侧数据采集的设备普及率较低，导致很多有用的数据没有办法采集上来供云端的大脑进行分析操作。
第二，采集数据的维度低、功能单一，会漏掉一部分有价值的数据。
第三，前端设备的维保非常难。以摄像头为例，我们没办法对每一个摄像头进行严密的监控和维护。出事故以后去追溯问题，可能已经过了好几天了。在这种情况下，这部分数据就会丢失。
第四，行业的数据标准不一样。设备一直在更新迭代，数据的标准也在不断更新。市面上有很多不同类型的设备，把这些设备的数据统一集中到云端去做处理，云端的能力也跟不上。
传统云端的主要瓶颈就是资源和效率问题。一个 1080p 的摄像头可能每分钟就会产生 10GB 的数据，而云端和边端的带宽非常有限，仅仅一个摄像头可能就会把整个网络的带宽占满，导致别的服务没法使用。再一个是效率限制，很多私有云的能力并不强，对于数据的处理就达不到理想的效果，也就没办法做及时的响应。对于一些要求低延时的行业，这是非常危险的。
同时，传统意义上的端和云链路是不可控的，比如端因为网络抖动和云失去联系，云端的指令不能及时下发到边端上，这也会带来一定的风险。
再者，传统上意义上端的设备更新是很缓慢的，一次性部署以后很长时间都不会有迭代。但是在一些新兴行业的场景下，比如智慧路口，它的 AI 算法是需要不断地进行模型训练的。它们部署下去之后会采集一些数据，这些数据上传到云端之后对模型进行训练，得到一个更优化的版本，然后把这更优化的版本再推到端上面去，进行更智能化的操作。这部分就是软件不停更新迭代的过程，这个也是传统意义上的云端不能做到的。
深信服智能边缘平台解决方案
针对以上这些问题，我们给用户提供了解决方案。先看一下解决方案的整体架构。它是从两个方面来进行的——边缘侧和中心侧。
首先，我们采取的是云端一体化架构。在边端给用户部署一个云边一体机，也可以理解成是一个小型的服务器，它可以和终端设备放在同一个地方。于是他们之间会整体形成一个独立的小网络。这样边端的设备就可以把数据发给云边一体机，数据就可以得到尽快的处理和响应。
其次，即使在云边断网的情况下，端侧可以和边侧一体机进行网络访问，我们可以内置一些 AI 算法进去，使特定场合下的指令也可以得到响应。
最后就是关于数据的处理。云边侧的网络带宽是有限的，我们可以先将数据收集在一体机里，先做一轮处理，把一些有效的数据处理出来。再将这些数据通过的 SD-WAN 网络汇报到中心侧进行处理，这样一方面减轻了带宽的压力，另一方面提高了中心侧的数据处理能力。
云边断网情况下的边缘自治能力其实是根据我们和社区的 OpenYurt 进行结合，将云边运维通道、边缘端的自治以及单元化部署都有机结合到了一起，形成了这样一个边缘计算的架构图。
云边一体机的最终目标是为智能化改造打通最后一公里。
它里面提供了很多功能，包括控制面板，AI 算法的平台，以及监控日志的收集，当然还有最重要的安全网络管理，以及一些视频的解码编码。同时这个盒子也是支持硬件适配的，比如 arm 架构、x86 架构，还包括不同的网络 GPU 的配合、底层数据操作系统适配。
完成了底层硬件的适配、AI 算法的适配、网络设备和视频解码的适配以后，把整体的方案交给用户，就可以帮助用户更快地实现业务的容器化部署，这大大提高了产品智能化改造的效率。
技术方案与 OpenYurt 落地结合
边缘计算比较重要的一个使用场景就是智慧路口。城市里每个路口的策略不一样。比如在一些车流量非常庞大的路口，它的重点更在于流量管控。由于车辆密集，红绿灯可能来不及做相应，就需要通过 AI 算法来支持。
再比如，在人流量非常密集的情况下，一些公安系统重点关注的有犯罪记录的人经过，这个时候要通过 AI 算法的人脸识别功能来及时通知周围民警，提醒他们注意防范。
还有很多的城市道路会和村道进行结合，这种城乡结合道路不光需要流量的管控，还需要交通安全的管控。我们要对 AI 算法植入一些智能语音服务的喊话系统，结合动态告警功能，可以避免交通事故的发生。
以上这些都是智慧路口关于 AI 算法的接入场景，这些 AI 算法可以根据不同的区域范围来做智能化的注入，这其实就利用了边缘计算 OpenYurt 的单元化管理，我们给它设置不同的单元化场景，连接到网络之后就可以根据当前的这一个区域来推送不同的 AI 算法。
说了这么多关于真实业务落地场景，后面将会结合整个平台的架构来讲解我们的改造思路。
KubeManager（KM）架构是我们公司自研的一个产品， 它是一个容器管理平台，底层是由多个 K8s 集群管理构建起来的，集成了多个应用商店和软件 ，还有一些数据的采集和监控、给用户的可视化展示。
它主要分为两个大的模块，上图左下方是管理集群，前文提到的一系列内容都是在管理集群里去承接的。用户集群可以通过接入层来进行数据接入，然后将 API 的数据发送到 API 业务层，再把这些数据存储到原生 K8s 的 etcd 里面去。
我们做改造的部分主要是针对用户集群这一块，跟 OpenYurt 做结合。在改造落地的过程中也出现了很多问题。
在有多个 master 的情况下，需要与 Tunnel 流量做适配，用户自己去做适配的过程非常麻烦。所以我们已经跟社区对接完成，把他们全部融入到平台的里面去，用户可以直接使用，不用考虑各种适配的问题。
用户集群接入到 km 集群之后，需要从 K8s 集群转换成边缘集群，我们也提供了一个自动化转换。
OpenYurt 是基于原生 K8s 来做的，由于搭建方式不同，在后面的平台对接过程中会出现一些差异，比如证书的自动管控和轮询操作、下发，这些都是需要在前期对接过程中解决，然后才能使用 OpenYurt。
改造之后，用户集群架构就从上图左边这切换到了右边的状态。这里面的改造主要有以下几点：
第一，对 YurtControlManager 组件做了改动，以前它是个 deployment，它的副本数是 1。现在把它改成了 DaemonSet，会随着 master 数量的变化自动扩缩容，这是一个。
第二，因为整体流量是通过 Nginx 找不同的 APS server 做代理，所以 YurtHub 其实不是直接访问 APIserver，而是通过 Nginx。但它现在这样也可以达到边缘集群和 OpenYurt 的结合之后想要的效果——比如流量过滤和边缘自治。
行业未来展望以及社区发展期许
最后说一下关于整个行业的发展和未来的期望。
从上图可以看到，边缘设备的成长是一个不断累积的过程。整个行业的发展对边缘设备会有非常多的需求，这么大的需求会带动整个行业的发展，行业的发展也离不开边缘社区，包括 OpenYurt 社区的贡献。希望每一个用户在使用 OpenYurt 的时候可以更加边缘化、安全化和智能化。
如果您有兴趣也可以钉钉搜索群号：31993519，加入 OpenYurt 项目钉钉群。
戳此处，立即了解 OpenYurt 项目！
