本文作者：中国联通智网创新中心云边协同小组：常乐/栗霖/赵斌/隗英英
随着5G的到来，边缘应用的数据量和终端的数量迅速增长。根据IDC预测，到2023年，全球联网设备将会达到489亿，大部分数据都在终端形成、积累，传送到云端，进行数据处理，再返回到终端指导业务。这一系列动作将对网络带宽产生数百Gbps每秒的超高需求，不仅会存在延迟，还需要面临弱网卡顿、连接成功率低等诸多问题，用户体验无法保障。因此需要将算力从中心迁移至边缘，减少中心网络及算力压力。
当计算迁移至边缘，就需要云网边端相互协同，保证业务的展开。在云网边端协同架构的业务中，边缘侧，计算能力可下沉部署到边缘进行业务部分处理；中心云进行业务统一管控。在本地进行数据的初步分析和处理，承担部分“云“的工作，减轻云中心的压力，同时也可以满足一些业务本地处理的安全要求，还能减少复杂网络中各种路由转发和网络设备处理的时延，更加能大幅减少网络传输和多级转发带来的带宽成本。如此一来，既能解决处理能力问题，又能优化成本的问题。
应用场景
云边端协同业务主要有以下业务场景。 AI业务场景： 如AI视频监控-监控视频产生大量的数据，同时AI视频分析需要大量的计算能力。如果在终端上进行视频AI分析，会大量消耗端的算力，终端无可避免的需要庞大的体积来承载这些算力；又如果将AI计算放在云中心，又将面临高昂的视频传输成本。这时候，终端算力上移、云端算力下沉，在边缘形成算力融合，在云上训练，边缘执行。即充分发挥云计算海量资源的优势，将 AI 模型的训练放在云端，而 AI 的执行则贴近设备侧，提高AI的执行效率与速度。 边缘分发： 将业务内容下发到离用户近的边缘节点，让用户可以就近访问需要的内容，不必去中心云访问内容，减少了传输时延，提升用户的业务体验，同时，缓解传统架构中网络压力，减少了中心云的带宽成本。 VR云渲染： 在云端对VR内容进行渲染，对VR内容延迟响应要求及带宽需求极高，当渲染延迟大于30ms时，会使用户感到眩晕，同时会造成VR内容视野内出现黑边。通过将渲染平台部署到边缘，实现渲染计算资源在边缘完成回传给用户，减少了网络传输时延，实现业务的稳定。基于云原生的边缘计算框架
Kubernetes已经成为云原生的主流选择，Kubernetes能够在任何基础设施上提供一致的云上体验。目前，不仅大多数新兴的云原生负载是构建在Kubernetes上的，传统应用和负载也在以更快的速度向Kubernetes迁移。而且Kubernetes 在朝着大规模，复杂场景的方向延伸，与AI、大数据、IoT、以及垂直行业等领域的结合越来越紧密。近年来，越来越多围绕Kubernetes生态圈的创新，正在这些领域发生着。把 Kubernetes 从云端延伸到边缘，目前有三个开源项目讨论较多，分别是OpenYurt、 KubeEdge 和 K3S，下面将详细介绍这三个开源框架。OpenYurt
概述 OpenYurt 是一款云原生边缘计算框架，由阿里云开源。主打“云边一体化”概念，依托 Kubernetes 强大的容器应用编 排能力，满足了云-边一体化的应用分发、交付、和管控的诉求。相较于其他基于 Kubernetes 的边缘计 算框架，OpenYurt 秉持着“最小修改”原则，通过在边缘节点安装 Yurthub 组件，在云端部署 Yurtcontroller-manager组件，保证了在对 Kubernetes 零侵入的情况下，提供管理边缘计算应用所需的相 关能力。OpenYurt 能帮用户解决在海量边、端资源上完成大规模应用交付、运维、管控的问题，并提 供中心服务下沉通道，实现和边缘计算应用的无缝对接。 OpenYurt架构分为云端和边缘端两部分，主要设计理念为集中的Kubernetes master节点驻留在云 端，它管理驻留在边缘端的多个边缘节点。每个边缘节点都有适度的计算资源，允许运行多个边缘应用 程序和节点守护进程，群集中的边缘节点可以跨越多个物理区域。 架构 主要组件如下：
YurtHub：
是一个运行在边缘节点上的节点守护程序，用作Kubernetes节点守护程序 (Kubelet，Kubeproxy，CNI插件等)的出站流量的代理。它在边缘节点的本地存储中缓存 Kubernetes节点守护程序可能访问的所有资源的状态。如果边缘节点处于脱机状态，这些守护程 序可以通过访问缓存来获取资源状态信息，在节点重新启动恢复正常时再从APIServer同步状态。
Yurt控制器管理器：
是一个部署在云端节点的组件，承接了原kube-controller-manager中的一些 工作。针对不同的边缘计算用例，它管理一些控制器，例如节点控制器(已发布)、单元控制器 (未发布)和隧道服务器(未发布)。其目前主要应用场景例如， autonomy 模式下的节点，即使 缺少节点心跳，也不会从APIServer退出处于该模式的节点中的Pod。
Yurt隧道(未发布)：
为云端控制节点和已联网的边缘节点之间建立安全的网络访问。其主要实 现方式为部署在云端的 Tunnel Server 通过反向代理的方式与部署在每个边缘节点中守护程序 TunnelAgent 建立通信通道。通过YurtTunnel建立内部网络流量通道，保证数据安全，同时解决了租用私有网络，带宽有限，且延迟高的问题。
特点
OpenYurt秉持着“最小修改”原则，对K8S零侵入，基于标准K8S API及标准网络技术实现，使得其具有 强兼容性，易于集成，提供一键集群转化功能，最大程度保证用户在管理边缘应用时获得和管理云端应 用一致的体验。YurtTunnel建立内部网络流量通道，保证数据安全，同时解决了租用私有网络，带宽有 限，且延迟高的问题。通过云上管控，边缘自治(YurtController+YurtHub)架构，一方面把云上把 Kubernetes原生容器编排和调度延伸至边缘，另一方面，在网络不稳，或边缘离线的状态下，保证离 线自治，应用继续工作。虽然OpenYurt 刚刚开源，当前开放的能力还不多，但是从其规划上看，未来 一年内将会有较大的提升及完善。
KubeEdge
概述 KubeEdge是基于Kubernetes构建的云边协同开源框架，可将容器化应用扩展到边缘端设备。其对Kubernetes侵入性较低，提供网络和应用程序提供核心基础架构支持，可完美支持ARM架构和x86架构。KubeEdge分为三个层面：云、边、端。KubeEdge可以做到云边可靠性协同，主要依赖于核心模块Cloud Hub同Edge Hub之间的数据传输通道，协议支持WebSocket和QUIC两种，保障云边信息同步：Cloud Hub基于WebSocket服务端，用于大量的边缘节点基于websocket协议连接上来，并监听云端的变化，缓存并发送消息到EdgeHub。Edge Hub基于WebSocket客户端，负责将接收到的信息转发到各边缘节点的各功能模块处理，同时将来自各edge端的消息通过隧道发送到cloud侧。
架构
Controllers包括EdgeController和DeviceController两个模块。
EdgeController:
用于控制 Kubernetes API Server 与边缘的节点、应用和配置的状态同步。
DeviceController:
DeviceController 是一个扩展的 Kubernetes 控制器，管理边缘设备，确保设备信息、设备状态的云边同步。
MetaManager：
通过本地数据库存储边缘端同云端通信时的所有信息，当云端需要查询数据时，直接从本地获取。假如云边网络不稳定时，本地数据库也能保障业务正常进行，在网络通信正常后，再重新同步数据。
Edged：
相当于k8s中轻量版的kubelet,裁减掉边缘端多余功能，只维护核心的组件，管理pod生命周期。使EdgeCore做到极致轻量。
EventBus：
MQTT客户端，为其他组件提供订阅和发布功能。
ServiceBus：
接受来自云上服务的请求，与运行在边缘端的HTTP服务器交互，提供了云上服务通过HTTP协议访问边缘端HTTP服务器的能力。
DeviceTwin：
负责存储设备状态并将设备状态同步到云，它还为应用程序提供查询接口。
KubeEdge实现边缘节点应用管理，利用Cloud Hub和Edge Hub消息传输机制，可在云端管理边缘端的应用，进行升级、更新。
由于工业场景设备会使用不同的协议，如蓝牙、Zigbee、Modbus等，若使用KubeEdge交互，需要通过Mapper将协议转成MQTT，最终才能实现设备同云端的通信。
特点
KubeEdge基于Kubernetes构建，并将k8s的能力扩展至边缘侧，保留了 Kubernetes 的管理面，重新开发了节点agent，大幅度优化使边缘组件资源占用更低。其通过底层优化的多路复用消息通道优化了云边的通信的性能。底层完美支持 ARM 架构和 x86 架构，满足更多异构服务器的管理。边缘侧极致轻量，占用资源约70M。云端中心可对边缘节点应用管理，统一进行应用分发、升级等。KubeEdge丰富了应用和协议支持，目前已经支持和计划支持的有：MQTT、BlueTooth、OPC UA、Modbus等，通过Mapper模块进行设备协议转换，实现设备的海量接入、实时通信。
K3S
概述 K3S是由Rancher公司开源的一套基于Kubernetes的轻量化云原生框架。K3S专为在资源有限的环境中运行 Kubernetes 的研发和运维人员设计，目的是为了在 x86、ARM64 和 ARMv7D 架构的边缘节点上运行小型的 Kubernetes 集群。K3S 的所有组件(包括 Server 和 Agent)都运行在边缘，因此不涉及云边协同。K3S 应用到边缘计算还需要搭配Rancher公司自己的Rancher平台进行使用，通过Rancher平台实现边缘云的管理、监控。 架构
k3s相比于的Kubernetes发行版，有以下更改：
- 移除过时的功能、Alpha功能、非默认功能，这些功能在大多数Kubernetes集群中已不可用，除此之外，K3S 还删除了所有非默认的 Admission Controller，in-tree 的 cloud provider 和存储插件。
- 删除内置插件(比如云供应商插件和存储插件)，可用外部插件程序替换。
- 使用 containderd 替换 Docker，减少运行时占用空间。
- 引入 SQLite 代替 etcd 作为管理面数据存储，并用 SQLite 实现了 list/watch 接口，即 Tunnel Proxy。
- 整合打包进程。为了节省内存，K3S 将原本以多进程方式运行的 Kubernetes 管理面和数据面的多个进程分别合并成一个来运行。
- 包含在一个简单的启动程序当中，可以处理复杂的TLS和其他选项。
- 几乎没有操作系统依赖性(仅需要健全的内核和cgroup挂载)。k3s软件包所需的依赖：
- containerd
- Flannel
- CoreDNS
- CNI
- 主机系统服务 (iptables, socat, etc)
K3S的边缘计算架构相比其它边缘计算云原生架构，通过将Rancher自己的管理平台管理整个云原生系统，在每个边缘节点则部署完整的自治的K3S集群，在Rancher的管理平台实现边缘节点的统一纳管，可以实现边缘节点的业务部署及开通，负责跨集群的应用管理、监控、告警、日志、安全和策略。
特点
轻量化的Kubernetes，二进制文件包小于 40 mb，只需要 512MB RAM 即可运行
边缘是一套完整的K3S系统。
通过Rancher对边缘节点进行管理，每个边缘节点都是完整一套K3S集群。
开源框架功能对比
| OpenYurt | KubeEdge | K3S | |
| 边缘自治 | 支持 | 支持 | 支持 |
| 原生支持K8S | 支持 | 支持 | 支持 |
| 边缘组件资源占用 | 大 | 最小(内存256M) | 小 |
| 是否支持MQTT | 不支持 | 支持 | 不支持 |
| 容器化编排 | 支持 | 支持 | 支持 |
建议与思考
依托云原生的边缘计算开源框架有利于发挥云原生轻量化、易移植等优势，帮助企业快速构建云边端能力，有利于应用在云网边端之间平滑移动，后续还需思考运营商网络能力如何在边缘计算架构下进行能力延伸，提供混合云架构的边缘计算网络能力，以及思考企业应用在云边端协同架构的应用能力分解和协同。 ———————————————— 请持续关注边缘计算中文社区公众号，获取最新的边缘技术知识。 更多硬货资料供下载： 1、在公众号对话框回复“报告”，获取《5G时代的边缘计算：中国的技术和市场发展》； 2、在公众号对话框回复“边缘计算”，获取《2020边缘计算产业前沿研究报告》； 3、在公众号对话框回复“IT”，获取《边缘计算IT基础设施白皮书1.0》； 4、在公众号对话框回复“网络”，获取《运营商边缘计算网络技术白皮书》； 5、在公众号对话框回复“安全”，获取《边缘计算安全白皮书》； 6、在公众号对话框回复“协同”，获取《云计算与边缘计算协同九大应用场景白皮书》； 7、在公众号对话框回复“曲线”，获取《2019边缘计算成熟度曲线报告》； 8、在公众号对话框回复“MEC”，获取《5G MEC边缘云平台架构及商用实践白皮书》。 9、关注公众号，在对话框回复“网络切片”，获取《网络切片分级白皮书》 。 10、在公众号对话框回复“边缘计算价值”，获取《5G边缘计算的价值机遇》报告。 11、在公众号对话框回复“优势”，获取《边缘计算优势》白皮书。 12、在公众号对话框回复“ICT技术”，获取《Gartner：2020年中国ICT技术成熟度曲线》。
点击“阅读原文”，了解更多精彩内容！
925
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
