| 编辑推荐: |
文章主要介绍了边缘计算场景，为什么我们需要云边协同，Kubernetes的优势与挑战,KubeEdge架构分析,K3S架构分析等等相关。
本文来自于csdn，由火龙果软件Anna编辑、推荐。 |
|
边缘计算场景分类与挑战
这里要讨论的“边缘”特指计算资源在地理分布上更加靠近设备，而远离云数据中心的资源节点。典型的边缘计算分为物联网（例如：下一代工业自动化，智慧城市，智能家居，大型商超等）和非物联网（例如：游戏，CDN等）场景。
在现实世界中，边缘计算无法单独存在，它必定要和远程数据中心/云打通（具体原因见下文）。以IoT（Internet
of Things，物联网）为例，边缘设备除了拥有传感器收集周边环境的数据外，还会从云端接收控制指令。边缘设备与云连接一般有两种模式：直连和通过中继边缘节点连接，如下图所示:
边缘设备能否直连云端/数据中心取决于是否有全球唯一可路由的IP，例如：手机、平板电脑等。不过，大部分的设备通过近场通信协议与边缘节点通信，进而和云端/数据中心连接的。边缘节点是设备的汇聚点，有分配IP地址，扮演了边缘网关的作用。边缘节点为普通的设备提供IP地址，也可以运行容器。
我们注意到，边缘节点也是有不同层级的，而划分的标准之一就是资源（计算、存储、网络带宽等）的大小。
如上所示，我们将edge分为“Device Edge”和“Infrastructure Edge”。Device
Edge（设备边缘）是指那些并不被认为是IT基础设施组成部分的边缘节点，例如：火车、油田、工厂和家庭等。通常它们没什么计算能力，被用于解决最后“一公里”接入的问题，一个典型的例子就是智能路由器，它一端通过红外信号控制家中电器，另一端通过网络和云数据中心相连。由于设备边缘网络稳定性较差，因此必须要考虑它们会较长时间离线的情况（例如火车过隧道）。
注：日常生活中很多设备我们可以看成是device+device edge的结合体，例如智能手机。
Infrastructure Edge（基础设施边缘）相对于Device Edge计算和存储能力都更强，而且通常通过骨干网与数据中心连接，因此具有更大的网络带宽和更加可靠的网络连接，例如：CDN，游戏服务器等。基础设施边缘除了能运行容器外，有些甚至还有足够资源运行完整的Kubernetes。
对边缘节点进行分类的意义在于，针对不同层级的边缘需要有针对性的部署模型，并且平台要为边缘节点提供通信能力。
最后，我们总结一下当前边缘计算领域面临的几个挑战：
云边协同：AI/安全等业务在云和边的智能协同、弹性迁移；
网络：边缘网络的可靠性和带宽限制；
管理：边缘节点的资源管理与边缘应用生命周期管理；
扩展：高度分布和大规模的可扩展性；
异构：边缘异构硬件和通信协议。
其中，云边协是当前面临最大的技术挑战！
为什么我们需要云边协同
边缘计算和云计算不是两种互斥的技术，它们是相辅相成的关系。而且从场景需求上看，IoT/Edge与云数据中心有一些相似之处，例如：
边缘也有管理节点的计算、存储、网络等资源的需求；
边缘应用也想容器化和微服务化；
边缘计算希望能有标准的API和工具链；
安全，数据/信道加密和认证授权。
因此，将云数据中心的现有架构和能力顺势延伸到边缘就变得水到渠成了。下面列举了一些需要云边协同的场景：
AI云上训练，边缘执行。即充分发挥云计算海量资源的优势，将AI模型的训练放在云端，而AI的执行则贴近设备侧；
微服务，DevOps。微服务和DevOps不仅仅是云上开发的专利，将它们引入边缘将会显著加速嵌入式设备、机器人等IoT软件的迭代周期，提升部署和运维效率；
数据备份转储。例如，海量的工业数据（加密后）存储在云端；
远距离控制。云端远程下发对边缘设备的控制信号；
自动扩展。由于边缘节点不如云具备良好的自动扩展能力，因此可以选择在峰值时将边缘的负载弹性扩容到云上。
我们已经积累了足够的管理云上资源的经验，现在下一步的挑战就是如何构建一个边缘云平台，把对云上资源的管理方法延伸到边缘，让我们能够无缝地管理边缘的资源和设备。边缘云平台将重点解决以下问题：
大规模/异构的设备，网关和边缘节点的接入；
大量遥测数据汇聚、处理后提供给云端应用使用；
设备安全和识别服务；
支持远程下达对设备的指令；
自动创建和管理边缘节点和设备；
实现云端对边缘应用的编排、部署和配置；
为边缘应用的开发提供数据存储、事件管理、API管理和数据分析等能力。
Kubernetes的优势与挑战
Kubernetes已经成为云原生的标准，并且能够在任何基础设施上提供一致的云上体验。我们经常能够看到“容器
+ Kubernetes”的组合在DevOps发挥10X效率，最近也有越来越多Kubernetes运行在数据中心外（边缘）的需求。
如果要在边缘部署较复杂的应用，那么Kubernetes是个理想的选择：
容器的轻量化和可移植性非常适合边缘计算的场景；
Kubernetes已经被证明具备良好的可扩展性；
能够跨底层基础设施提供一致的体验；
同时支持集群和单机运维模式；
Workload抽象，例如：Deployment和Job等；
应用的滚动升级和回滚；
围绕Kubernetes已经形成了一个强大的云原生技术生态圈，诸如：监控、日志、CI、存储、网络都能找到现成的工具链；
支持异构的硬件配置（存储、CPU、GPU等）；
用户可以使用熟悉的kubectl或者helm chart把IoT应用从云端推到边缘；
边缘节点可以直接映射成Kubernetes的Node资源，而Kubernetes的扩展
API（CRD）可以实现对边缘设备的抽象。
然而Kubernetes毕竟是为云数据中心设计的，要想在边缘使用Kubernetes的能力，Kubernetes或其扩展需要解决以下问题：
ARM的低功耗和多核的特点又使得其在IoT/Edge领域的应用非常广泛，然而大部分的Kubernetes发行版并不支持ARM架构；
很多设备边缘的资源规格有限，特别是CPU处理能力较弱，因此无法部署完整的Kubernetes；
Kubernetes非常依赖list/watch机制，不支持离线运行，而边缘节点的离线又是常态，例如：设备休眠重启；
Kubernetes的运维相对于边缘场景用到的功能子集还是太复杂了；
特殊的网络协议和拓扑要求。设备接入协议往往非TCP/IP协议，例如，工业物联网的Modbus和OPC
UA，消费物联网的Bluetooth和ZigBee等；
设备多租。
关于如何在边缘使用Kubernetes，Kubernetes IoT/Edge WG组织的一个调查显示，30%的用户希望在边缘部署完整的Kubernetes集群，而70%的用户希望在云端部署Kubernetes的管理面并且在边缘节点上只部署Kubernetes的agent。
把Kubernetes从云端延伸到边缘，有两个开源项目做得不错，分别是KubeEdge和K3S，下面我们将详解这两个项目，并做全方位的对比。
KubeEdge架构分析
KubeEdge是首个基于Kubernetes扩展的，提供云边协同能力的开放式智能边缘平台，也是CNCF在智能边缘领域的首个正式项目。KubeEdge重点要解决的问题是：
云边协同
资源异构
大规模
轻量化
一致的设备管理和接入体验
KubeEdge的架构如下所示：
KubeEdge架构上清晰地分为三层，分别是：云端、边缘和设备层，这是一个从云到边缘再到设备的完整开源边缘云平台，消除了用户厂商绑定的顾虑。
KubeEdge的边缘进程包含以下5个组件：
edged是个重新开发的轻量化Kubelet，实现Pod，Volume，Node等Kubernetes资源对象的生命周期管理；
metamanager负责本地元数据的持久化，是边缘节点自治能力的关键；
edgehub是多路复用的消息通道，提供可靠和高效的云边信息同步；
devicetwin用于抽象物理设备并在云端生成一个设备状态的映射；
eventbus订阅来自于MQTT Broker的设备数据。
KubeEdge的云端进程包含以下2个组件：
cloudhub部署在云端，接收edgehub同步到云端的信息；
edgecontroller部署在云端，用于控制Kubernetes API Server与边缘的节点、应用和配置的状态同步。
Kubernetes maser运行在云端，用户可以直接通过kubectl命令行在云端管理边缘节点、设备和应用，使用习惯与Kubernetes原生的完全一致，无需重新适应。
K3S架构分析
K3S是CNCF官方认证的Kubernetes发行版，开源时间较KubeEdge稍晚。K3S专为在资源有限的环境中运行Kubernetes的研发和运维人员设计，目的是为了在x86、ARM64和ARMv7D架构的边缘节点上运行小型的Kubernetes集群。K3S的整体架构如下所示：
事实上，K3S就是基于一个特定版本Kubernetes（例如：1.13）直接做了代码修改。K3S分Server和Agent，Server就是Kubernetes管理面组件
+ SQLite和Tunnel Proxy，Agent即Kubernetes的数据面 + Tunnel
Proxy。
为了减少运行Kubernetes所需的资源，K3S对原生Kubernetes代码做了以下几个方面的修改：
删除旧的、非必须的代码。K3S不包括任何非默认的、Alpha或者过时的Kubernetes功能。除此之外，K3S还删除了所有非默认的Admission
Controller，in-tree的cloud provider和存储插件；
整合打包进程。为了节省内存，K3S将原本以多进程方式运行的Kubernetes管理面和数据面的多个进程分别合并成一个来运行；
使用containderd替换Docker，显著减少运行时占用空间；
引入SQLite代替etcd作为管理面数据存储，并用SQLite实现了list/watch接口，即Tunnel
Proxy；
加了一个简单的安装程序。
K3S的所有组件（包括Server和Agent）都运行在边缘，因此不涉及云边协同。如果K3S要落到生产，在K3S之上应该还有一个集群管理方案负责跨集群的应用管理、监控、告警、日志、安全和策略等，遗憾的是Rancher尚未开源这部分能力。
KubeEdge与K3S全方位对比
部署模型
KubeEdge遵循的是以下部署模型:
KubeEdge是一种完全去中心化的部署模式，管理面部署在云端，边缘节点无需太多资源就能运行Kubernetes的agent，云边通过消息协同。从Kubernetes的角度看，边缘节点
+ 云端才是一个完整的Kubernetes集群。这种部署模型能够同时满足“设备边缘”和“基础设施边缘”场景的部署要求。
K3S的部署模型如下所示：
K3S会在边缘运行完整的Kubernetes集群，这意味着K3S并不是一个去中心化的部署模型，每个边缘都需要额外部署Kubernetes管理面。这种部署模型带来的问题有：
在边缘安装Kubernetes管理面将消耗较多资源，因此该部署模型只适合资源充足的“基础设施边缘”场景，并不适用于资源较少的“设备边缘”的场景；
集群之间网络需要打通；
为了管理边缘Kubernetes集群还需要在上面叠加一层多集群管理组件（遗憾的是该组件未开源）。
云边协同
云边协同是KubeEdge的一大亮点。KubeEdge通过Kubernetes标准API在云端管理边缘节点、设备和工作负载的增删改查。边缘节点的系统升级和应用程序更新都可以直接从云端下发，提升边缘的运维效率。另外，KubeEdge底层优化的多路复用消息通道相对于Kubernetes基于HTTP长连接的list/watch机制扩展性更好，允许海量边缘节点和设备的接入。KubeEdge云端组件完全开源，用户可以在任何公有云/私有云上部署KubeEdge而不用担心厂商锁定，并且自由集成公有云的其他服务。
K3S并不提供云边协同的能力。
边缘节点离线自治
与Kubernetes集群的节点不同，边缘节点需要在完全断开连接的模式下自主工作，并不会定期进行状态同步，只有在重连时才会与控制面通信。此模式与Kubernetes管理面和工作节点通过心跳和list/watch保持状态更新的原始设计非常不同。
KubeEdge通过消息总线和元数据本地存储实现了节点的离线自治。用户期望的控制面配置和设备实时状态更新都通过消息同步到本地存储，这样节点在离线情况下即使重启也不会丢失管理元数据，并保持对本节点设备和应用的管理能力。
K3S也不涉及这方面能力。
设备管理
KubeEdge提供了可插拔式的设备统一管理框架，允许用户在此框架上根据不同的协议或实际需求开发设备接入驱动。当前已经支持和计划支持的协议有：MQTT，BlueTooth，OPC
UA，Modbus等，随着越来越多社区合作伙伴的加入，KubeEdge未来会支持更多的设备通信协议。KubeEdge通过device
twins/digital twins实现设备状态的更新和同步，并在云端提供Kubernetes的扩展API抽象设备对象，用户可以在云端使用kubectl操作Kubernetes资源对象的方式管理边缘设备。
K3S并不涉及这方面能力。
轻量化
为了将Kubernetes部署在边缘，KubeEdge和K3S都进行了轻量化的改造。区别在于K3S的方向是基于社区版Kubernetes不断做减法（包括管理面和控制面），而KubeEdge则是保留了Kubernetes管理面，重新开发了节点agent。
需要注意的是，K3S在裁剪Kubernetes的过程中导致部分管理面能力的缺失，例如：一些Admission
Controller。而KubeEdge则完整地保留了Kubernetes管理面，没有修改过一行代码。
下面我们将从二进制大小、内存和CPU三个维度对比KubeEdge和K3S的资源消耗情况。由于KubeEdge的管理面部署在云端，用户不太关心云端资源的消耗，而K3S的server和agent均运行在边缘，因此下面将对比KubeEdge
agent，K3S agent和K3S server这三个不同的进程的CPU和内存的资源消耗。
测试机规格为4 vCPU，8GB RAM。
内存消耗对比
分别用KubeEdge和K3S部署0~100个应用，分别观测两者的内存消耗，对比如下所示：
从上图可以看出，内存消耗：KubeEdge agent \u0026lt; K3S agent \u0026lt;
K3S Server。有意思的是，K3S agent即使不运行应用也消耗100+MB的内存，而K3S
server在空跑的情况下内存消耗也在300MB左右。
CPU使用对比
分别用KubeEdge和K3S部署0~100个应用，分别观测两者的CPU使用情况，对比如下所示：
从上图可以看出，KubeEdge agent CPU消耗要比K3S
agent和server都要少。
二进制大小
KubeEdge agent二进制大小为62MB，K3S二进制大小为36MB。
大规模
Kubernetes原生的可扩展性受制于list/watch的长连接消耗，生产环境能够稳定支持的节点规模是1000左右。KubeEdge作为华为云智能边缘服务IEF的内核，通过多路复用的消息通道优化了云边的通信的性能，压测发现可以轻松支持5000+节点。
而K3S的集群管理技术尚未开源，因为无法得知K3S管理大规模集群的能力。
小结
K3S最让人印象深刻的创新在于其对Kubernetes小型化做的尝试，通过剪裁了Kubernetes一些不常用功能并且合并多个组件到一个进程运行的方式，使得一些资源较充足的边缘节点上能够运行Kubernetes，让边缘场景下的用户也能获得一致的Kubernetes体验。然而通过上面的性能对比数据发现，K3S的资源消耗还是比KubeEdge要高出好几倍，而且动辄几百MB的内存也不是大多数设备边缘节点所能提供的。最重要的是，Kubernetes最初是为云数据中心而设计的，很多边缘计算场景特殊的问题原生Kubernetes无法很好地解决，
K3S直接修改Kubernetes的代码甚至基础实现机制（例如，使用SQLite替换etcd）的做法仍值得商榷。关于什么能改，什么不能改以及怎么改？每个用户根据自己的实际需求有各自的观点，而且也很难达成一致。另外，
K3S这种侵入式的修改能否持续跟进Kubernetes上游的发展也是一个未知数。
KubeEdge和K3S走的是另一条道路，KubeEdge是一个从云到边缘再到设备的完整边缘云平台，它与Kubernetes的耦合仅仅是100%兼容Kubernetes原生API。KubeEdge提供了K3S所不具备的云边协同能力，开发了更轻量的边缘容器管理agent，解决了原生Kubernetes在边缘场景下的离线自治问题，并且支持海量异构边缘设备的接入等。KubeEdge最近捐献给CNCF，成为CNCF边缘计算领域的第一个正式项目，就是为了和社区合作伙伴一起制定云和边缘计算协同的标准，结束边缘计算没有统一标准和参考架构的混沌状态，共同推动边缘计算的产业发展。
最后，边缘计算还有广阔的发展前景，KubeEdge和K3S都是非常年轻的优秀开源项目，我相信未来他们会在相互学习的过程中共同进步，更好地解决边缘计算用户的需求。
|
