从中心走向边缘——深度解析云原生边缘计算落地痛点

云计算发展史，就是虚拟化技术的发展史。近 20 年来云计算与互联网相互促进高速发展，中心云技术成为全社会通用的基础设施。随着物联网、人工智能等技术的不断发展，尤其是产业互联网发展落地，中心云计算开始相形见绌，分散式边缘计算在当下被重新寄予厚望。如果中心云计算是由技术创新驱动的，那么边缘计算一定是业务价值驱动的。

那到底什么是边缘计算？边缘计算有哪些分类？边缘计算与中心云的关系是什么？本文将抽丝剥茧，深入浅出，详细阐述对边缘计算与云原生的理解与思考。

边缘计算的理解与思考

边缘计算的定义

边缘计算当前没有准确定义，从 IT 云计算领域视角，边缘计算被看作中心云计算的拓展。边缘计算产业联盟对边缘计算的定义：“在靠近物或数据源头的网络边缘侧，融合网络、计算、存储、应用核心能力的开放平台，就近提供边缘智能服务，满足行业数字化在敏捷连接、实时业务、数据优化、应用智能、安全与隐私保护等方面的关键需求”。从 CT 电信领域视角，边缘计算最初也被称为移动边缘计算（MEC）。欧洲电信标准协会（ETSI）对 MEC 的定义：“移动边缘计算在移动网络的边缘、无线接入网（RAN）的内部以及移动用户的近处提供了一个 IT 服务环境以及云计算能力”。

边缘计算的定义各有侧重，但核心思想基本一致——边缘计算是基于云计算核心技术，构建在边缘基础设施之上的新型分布式计算形式，在边缘端靠近最终用户提供计算能力，是一种靠近数据源的现场云计算。

中心云计算凭借其强大的数据中心，为业务应用提供大规模池化，弹性扩展的计算、存储、网络等基础设施服务，更适用于非实时、长周期数据、业务决策场景；边缘计算则聚焦在实时性、短周期数据、本地决策等业务场景，比如当下热门的音视频直播、IoT、产业互联网、虚拟现实甚至元宇宙等，将工作负载下沉至离终端设备或者靠近最终用户的地方，以此实现更低的网络延迟，提升用户的使用体验。

“章鱼式”边缘计算

边缘是相对中心式计算的边缘分散式计算。边缘计算的核心目标是快速决策，将中心云的计算能力拓展至“最后一公里”。因此它不能独立于中心云，而是在云-边-端的整体架构之下，有中心式管控决策，也有分散式边缘自主决策，即章鱼式边缘计算。

如上图漫画中所示，章鱼全身神经元中心式脑部占 40%，其余 60% 在分散式腿部，形成 1 个大脑总控协调 + N 个小脑分散执行的结构。1 个大脑擅长全局调度，进行非实时、长周期的大数据处理与分析；N 个小脑侧重局部、小规模数据处理，适用于现场级、实时、短周期的智能分析与快速决策。

章鱼式边缘计算采用中心云+边缘计算的分布式云边一体化架构，海量终端采集到数据后，在边缘完成小规模局部数据的实时决策处理，而复杂大规模的全局性决策处理则汇总至中心云深入分析处理。

边缘计算的位置

边缘计算位于中心云及终端之间，将云计算能力由中心下沉到边缘，通过云边协同的架构解决特定的业务需求，能最大程度降低传输时延，这也是边缘计算的核心价值。但中心云与终端之间的网络传输路径经由接入网（距离 30 公里，延迟 5 到10 毫秒），汇聚网，城际网（距离 50 到 100 公里，延迟 15 到 30 毫秒）到骨干网（距离 200 公里，延迟 50 毫秒），最后才到数据中心（假定数据中心 IDC 都在骨干网），耗时数据是正常网络拥塞的拨测统计值，即业务侧感知的实际延迟数据，虽不是非常精确，但足够辅助架构决策。

云计算能力由中心逐步下沉到边缘，节点数量增多，覆盖范围缩小，运维服务成本快速增加。根据国内网络（国内有多张骨干网，分别是电信 CHINANET 与 CN2，联通 CNCNET 以及移动 CMNET）现状，骨干网节点，城际网节点，汇聚网节点，接入网节点，以及数以万计的业务现场计算节点都可以安置边缘计算，因此范围太广难以形成统一标准。因此我们说中心云计算由技术定义，边缘计算由网络与业务需求定义。

边缘计算生态参与者众多，云厂商、设备厂商、运营商三大关键服务商方以及一些新型 AI 服务商等，都是从各自现有优势延伸，拓展更多客户及市场空间。设备商借助物联网逐渐构建单一功能的专业云；云厂商从中心化的公有云开始下沉，走向分布式区域云，区域云之间通过云联网打通，形成一个覆盖更大的云。运营商在互联网时代被公有云及繁荣的移动应用完全屏蔽只能充当管道，但在边缘计算时代，业务及网络定义边缘计算，运营商重新回归焦点，不可替代。

边缘计算的类型

（1）网络定义的边缘计算：

通过优化终端与云中心网络路径，将中心云能力逐渐下沉至靠近终端，实现业务就近接入访问。从中心到边缘依次分为区域云/中心云，边缘云/边缘计算，边缘计算/本地计算三大类型：

• 区域云/中心云：将中心云计算的服务在骨干网拓展延伸，将中心化云能力拓展至区域，实现区域全覆盖，解决在骨干网上耗时，将网络延迟优化至 30ms 左右，但逻辑上仍是中心云服务。
• 边缘云/边缘计算：将中心云计算的服务沿着运营商的网络节点延伸，构建中小规模云服务或类云服务能力，将网络延迟优化至 15ms 左右，比如多接入边缘计算（MEC）、CDN。
• 边缘计算/本地计算：主要是接近终端的现场设备及服务能力，将终端部分逻辑剥离出来，实现边缘自主的智能服务，由云端控制边缘的资源调度、应用管理与业务编排等能力，将网络延迟优化至 5ms 左右，比如多功能一体机、智能路由器等。

总的来说，基于网络定义的边缘计算，更多是面向消费互联业务及新型 2C 业务，将云中心的能力及数据提前下沉至边缘，除了经典的 CDN，视频语音业务外，还有今年大火的元宇宙等。

当前大部分面向消费互联业务都是通过安置在骨干网的中心云计算能力支持，时延在 30ms 到 50ms，远小于本身云端后端业务处理的延迟；算力下沉至边缘的初衷，主要是实现中心云海量请求压力分散，用户体验优化等，对业务都属于锦上添花，而非雪中送炭。

这里说一下运营商网络，中心云计算技术，是将数据中心内部网络全部虚拟化，即云内网络，衍生出 VPC，负载均衡等诸多产品；数据中心外部几乎完全屏蔽运营商网络，只提供弹性公网 IP 及互联网出口带宽服务，中心云计算与运营商网络没有融合；但从中心云计算演进到边缘计算，是强依赖网络将中心云与边缘链接起来，如果中心云是大脑，边缘计算是智能触角，那么网络就是神经，就是动脉血管，但实际上整体网络规划与建设发生在云计算发展之前，并不是专门服务云计算的，所以中心云计算与运营商网需要融合，即云网融合，云网融合最终目标是实现云能力的网络化调度编排，网络能力的云化快速定义。希望借助新型业务需求和云技术创新，驱动运营商网络架构深刻变革升级开放。

当前，网络的能力极大限制了云计算的发展，在边缘计算及物联网建设过程中尤为明显；云网融合与算力网络依然还是运营商的独家游戏，新一代 5G 颠覆性技术变革，引爆整个领域的颠覆性巨变，也只解决了海量设备接入及设备低延迟接入的问题，后端整体配套及解决方案明显跟不上。就当前情况来看，依然还是 5G 找业务的尴尬局面，未来 5G 在实体产业领域（港口， 码头，矿山等）领域，相比消费者领域，相信会带来更大变革与价值。

（2）业务定义的边缘计算：

除了面向消费者的互联网边缘场景，边缘计算更多的是面向实体产业及智慧化社会衍生的场景。

对于实体产业场景来说，由于历史原因，在边缘及现场存在大量异构的基础设施资源；通过业务需求驱动边缘计算平台的建设，不仅要整合利用现有基础设施资源，还要将中心云计算技术及能力下沉至边缘及现场，实现大量存量业务运营管控上云，海量数据统一入湖，以此支持整个企业的数字化转型。

对于智慧化社会衍生场景来说，越是新型的业务，对网络时延敏感越高，数据量越大，结构化数据逐渐转化成非结构化数据，需要人工智能，神经网络等高等智能化技术支持。

当前对网络时延敏感的新型业务场景，都是通过云端总控管理，设备现场实时计算这种分布式架构策略，以此减弱对网络的强依赖。面向业务将边缘计算分为智能设备/专业云及产业边缘/行业云两种类型：

• 智能设备/专业云：基于云计算能力之上，围绕智能设备提供整体化，有竞争力的解决方案，包含智能设备、云端的服务以及端到云之间的边缘侧服务，比如视频监控云、G7 货运物联等；
• 产业边缘/行业云：也基于云计算能力之上，围绕行业应用及场景，提供套件产品及解决方案，比如物流云、航天云等。

总的来说，基于业务定义的边缘计算，更多是面向智能设备及实体产业，对智能设备，从 AVG，密集式存储，机械手臂等单一功能的智能设备，到无人机，无人驾驶车等超复杂的智能设备，云计算能力不仅支撑设备控制管理应用的运行，同时借助中心云计算能力拓展至边缘侧，解决这种产品上云，无法集中化标准化管理难题；对产业边缘，通过云计算技术，结合行业场景的抽象总结，构建行业通用的产品及解决方案，随着整个产业互联网加速建设，是边缘计算未来发展的重点方向。

小结

对于规模较大的企业，云边场景非常复杂，中心云计算平台与边缘计算平台建设，不仅应对业务需求，还要面临诸多基础设施问题：在中心云计算面临多云使用多云互通问题；在边缘网络链路面临多运营商的骨干网，多云运营商网络及多云的云网融合问题；在端侧接入网面临多运营商 5G 网络的共享的问题等，很多问题只能通过治理的手段应对，无法从技术平台层面彻底解决。

总的来说，边缘计算范围大，场景泛，目前整个行业缺少经典的案例及标准。因此推动边缘计算落地，一定是面向真实的业务场景及需求整体规划，面向价值逐步建设。

Kubernetes 从中心走向边缘

Kubernetes 遵循以应用为中心的技术架构与思想，以一套技术体系支持任意负载，运行于任意基础设施之上；向下屏蔽基础设施差异，实现底层基础资源统一调度及编排；向上通过容器镜像标准化应用，实现应用负载自动化部署；向外突破中心云计算的边界，将云计算能力无缝拓展至边缘及现场，快速构建云边一体基础设施。

将云原生技术从中心拓展到边缘，不仅实现了云边基础设施技术架构大一统，业务也实现了云边自由编排部署。相对于 Kubernetes 在中心云的革命性创新，在边缘场景虽优势明显，但缺点也很致命，因为边缘侧存在资源有限、网络受限不稳定等特殊情况，需要根据不同业务场景，选择不同 Kubernetes 边缘方案。

Kubernetes 架构及边缘化的挑战

Kubernetes 是典型的分布式架构，Master 控制节点是集群“大脑”，负责管理节点，调度 Pod 以及控制集群运行状态。Node 工作节点，负责运行容器（Container），监控/上报运行状态。边缘计算场景存在以下比较明显的挑战：

1. 状态强一致且集中式存储架构，属于中心云计算的大成产品，基于大规模的池化资源的编排调度实现业务持续服务。
2. Master 管控节点与 Worker 工作节点通过 List-Watch 机制，实现状态任务实时同步，但是流量较大，Worker 工作节点完全依赖 Master 节点持久化数据，无自治能力。
3. Kubelet 承载太多逻辑处理，各种容器运行时各种实现的兼容，还有 Device Plugin 硬件设备驱动，运行占用资源高达 700M；对资源有限的边缘节点负担太重，尤其是低配的边缘设备。

边缘计算涉及的范围大、场景复杂，尚无统一标准；Kubernetes 开源社区的主线版本并无边缘场景的适配计划。

Kubernetes 边缘化运行方案

针对中心云计算及边缘计算这种云边分布式架构，需要将 Kubernetes 适配成适合边缘分布式部署的架构，通过多集群管理实现统一管理，实现中心云管理边缘运行，整体分为三种方案：

• 集群 Cluster：将 Kubernetes 标准集群下沉至边缘，优点是无需 Kubernetes 做定制化研发，同时可以支持 Kubernetes 多版本，支持业务真正实现云边架构一致；缺点是管理资源占用多。方案比较适合区域云/中心云、边缘计算/本地计算以及规模较大的产业边缘场景。
• 单节点 Single Node：将 Kubernetes 精简，部署在单节点设备之上，优点与集群 Cluster 方案一致，缺点是 Kubernetes 能力不完整，资源的占用会增加设备的成本，对业务应用无法保证云边一致的架构部署运行，没有解决实际问题。
• 边缘节点 Remote Node：基于Kubernetes 二次开发增强扩展，将 Kubernetes 解耦适配成云边分布式架构的场景，中心化部署 Master 管理节点，分散式部署 Worker 管理节点。

此外，一致性是边缘计算的痛点，在边缘增加一个 Cache 即可实现断网特殊情况的边缘自治，同时可以保证正常网络情况的数据一致；还有就是 Kubelet 比较重的问题，随着 Kubernetes 放弃 Docker 已经开始精简；同时硬件更新迭代较快，相比少量硬件成本，保持 Kubernetes 原生及通用性为大。其实更希望Kubernetes 社区本身提供适配边缘化方案，同时考虑为 Kubelet 增加缓存机制。

Kubernetes 边缘容器快速发展

Kubernetes 已成为容器编排和调度的事实标准，针对边缘计算场景，目前国内各个公有云厂商都开源了各自基于 Kubernetes 的边缘计算云原生项目，比如阿里云向 CNCF 贡献的 OpenYurt，采用边缘节点 Remote Node 方案，是业界首个开源的非侵入式边缘计算云原生平台，秉承“Extending your native Kubernetes to Edge”的非侵入式设计理念，拥有可实现边缘计算全场景覆盖的能力。华为、腾讯、百度等，也都开源了自己的边缘容器平台。

边缘容器的快速发展带动了领域的创新，但一定程度上也导致构建边缘计算平台时难以抉择。从技术架构来看，几个边缘容器产品总的架构思路主要是将 Kubernetes 解耦成适合云边、弱网络及资源稀缺的边缘计算场景，本质上无太大差异；从产品功能来看也是如此，基本上都涵盖云边协同、边缘自治、单元化部署功能等。

如何构建云边一体化云原生平台

现阶段，围绕 Kubernetes 容器平台，构建云边一体化云原生基础设施平台能力是边缘计算平台的最佳选择，通过云端统一的容器多集群管理，实现分散式集群统一管理，同时标准化 Kubernetes 集群规格配置：

• 标准集群（大规模）：支持超过 400 个节点的大规模集群，配置为 ETCD + Master 3 台 8c16G，Prometheus + Ingress 5 台 8C16G， N * Work 节点；主要是业务规模较大的云原生应用运行场景；
• 标准集群（中等规模）：支持超过 100 个节点以内的集群，ETCD + Master + Prometheus 3 台 8c16G，N * Work 节点；主要是业务规模中等的场景；
• 边缘原生容器集群：在云端部署集群管理节点，将边缘节点单独部署业务现场，支持运行单业务场景的应用，比如 IoT 物理设备接入协议解析应用，视频监控分析 AI 算法模型等业务场景。

按照业务场景需求选择最优容器集群方案，其中边缘容器集群方案，与其他集群方案差别较大，其他集群依然保持中心云集群服务一致，基础资源集中并且池化，所有应用共享整个集群资源；而边缘容器集群Master 管理节点集中部署，共享使用；Worker 节点都是分散在业务现场，按需自助增加，自运维且独占使用。

当前边缘容器领域短时间内很难有大一统的开源产品，因此现阶段建议通过标准的 Kubernetes API 来集成边缘原生容器集群，这种兼容所有边缘容器的中庸方案，如果非要择其一，建议是 OpenYurt，非侵入式设计，整体技术架构及实现更加优雅。

OpenYurt：智能边缘计算平台开源实践

OpenYurt 以上游开源项目 Kubernetes 为基础，针对边缘场景适配的发行版。是业界首个依托云原生技术体系、“零”侵入实现的智能边缘计算平台。具备全方位的“云、边、端一体化”能力，能够快速实现海量边缘计算业务和异构算力的高效交付、运维及管理。

设计原则

OpenYurt 采用当前业界主流的“中心管控、边缘运行”的云边分布式协同技术架构，始终贯彻“Extending your native Kubernetes to Edge”理念，同时遵守以下设计原则：

• “云边一体化”原则：保证与中心云一致的用户体验及产品能力的基础上，通过云边管控通道将云原生能力下沉至边缘，实现海量的智能边缘节点及业务应用，基础架构提升至业界领的云原生架构的重大突破。
• “零侵入”原则：确保面向用户开放的 API 与原生 Kubernetes 完全一致。通过节点网络流量代理方式（proxy node network traffic），对 Worker 工作节点应用生命周期管理新增一层封装抽象，实现分散式工作节点资源及应用统一管理及调度。同时遵循“UpStream First”开源法则；
• “低负载”原则：在保障平台功能特性及可靠性的基础上，兼顾平台的通用性，严格限制所有组件的资源，遵循最小化，最简化的设计理念，以此实现最大化覆盖边缘设备及场景。
• “一栈式”原则：OpenYurt 不仅实现了边缘运行及管理的增强功能，还提供了配套的运维管理工具，实现将原生 Kubernetes 与支持边缘计算能力的 Kubernetes 集群的相互一键高效转换；

功能特性

OpenYurt 基于 Kubernetes 强大的容器编排、调度能力，针对边缘资源有限，网络受限不稳定等情况适配增强；将中心云原生能力拓展至分散式边缘节点，实现面向边缘业务就近低延迟服务；同时打通反向安全控制运维链路，提供便捷高效的，云端集中式边缘设备及应用的统一运维管理能力。其核心功能特性如下：

1. 边缘节点自治：在边缘计算场景，云边管控网络无法保证持续稳定，通过增强适配解决原生 Worker 工作节点无状态数据，强依赖 Master 管控节点数据且状态强一致机制，这些在边缘场景不适配的问题。从而实现在云边网络不畅的情况下，边缘工作负载不被驱逐，业务持续正常服务；即使断网时边缘节点重启，业务依然能恢复正常；即边缘节点临时自治能力。
2. 协同运维通道：在边缘计算场景，云边网络不在同一网络平面，边缘节点也不会暴露在公网之上，中心管控无法与边缘节点建立有效的网络链路通道，导致所有原生的 Kubernetes 运维 APIs（logs/exec/metrics）失效。适配增强 Kubernetes 能力，在边缘点初始化时，在中心管控与边缘节点之间建立反向通道，承接原生的 Kubernetes 运维 APIs（logs/exec/metrics）流量，实现中心化统一运维；
3. 边缘单元化负载：在边缘计算场景，面向业务一般都是“集中式管控，分散式运行”这种云边协同分布式架构；对于管理端，需要将相同的业务同时部署到不同地域节点;对于边缘端，Worker 工作节是一般是分散在广域空间，并且具有较强的地域性，跨地域的节点之间网络不互通、资源不共享、资源异构等明显的隔离属性。适配增强 Kubernetes 能力，基于资源，应用及流量三层实现对边缘负载进行单元化管理调度。

通过 OpenYurt 开源社区引入更多的参与方共建，联合研发方式提供更多的可选的专业功能，OpenYurt 特性正在逐步完善，并扩大覆盖能力：

1. 边缘设备管理：在边缘计算场景，端侧设备才是平台真正的服务对象；基于云原生理念，抽象非侵入、可扩展的设备管理标准模型，无缝融合 Kubernetes 工作负载模型与 IoT 设备管理模型，实现平台赋能业务的最后一公里。目前，通过标准模型完成 EdgeX Foundry 开源项目的集成，极大的提升了边缘设备的管理效率。
2. 本地资源管理：在边缘计算场景，将边缘节点上已有的块设备或者持久化内存设备，初始化成云原生便捷使用的容器存储，支持两种本地存储设备：（一）基于块设备或者是持久化内存设备创建的 LVM；（二）基于块设备或者是持久化内存设备创建的 QuotaPath。

OpenYurt 设计架构及原理

（1）设计架构

原生 Kubernetes 是一个中心式的分布式架构，Master 控制节点负责管理调度及控制集群运行状态；Worker 工作节点负责运行容器（Container）及监控/上报运行状态；

OpenYurt 以原生 Kubernetes 为基础，针对边缘场景将中，心式分布式架构（Cloud Master，Cloud Worker）解耦适配为中心化管控分散式边缘运行（Cloud Master,Edge Worker），形成一个中心式大脑，多个分散式小脑的章鱼式云边协同分布式架构，其主要核心点是：

1. 将元数据集中式且强一致的状态存储，分散至边缘节点，并且调整原生 Kubernetes 调度机制，实现自治节点状态异常不触发重新调度，以此实现边缘节点临时自治能力；
2. 保证 Kubernetes 能力完整一致，同时兼容现有的云原生生态体系的同时，尽最大肯能将云原生体系下沉至边缘；
3. 将中心大规模资源池化，多应用委托调度共享资源的模式，适配为面向地域小规模甚至单节点资源，实现边缘场景下，更精细化的单元化工作负载编排管理；
4. 面向边缘实际业务场景需求，通过开放式社区，无缝集成设备管理、边缘 AI、流式数据等，面向边缘实际业务场景的开箱的通用平台能力，赋能更多的边缘应用场景。

（2）实现原理

OpenYurt 践行云原生架构理念，面向边缘计算场景实现云边协同分布式架构及中心管控边缘运行的能力：

• 针对边缘节点自治能力，一方面，通过新增 YurtHub 组件实现边缘向中心管控请求（Edge To Cloud Request）代理，并缓存机制将最新的元数据持久化在边缘节点；另一方面新增 YurtControllerManager 组件接管原生 Kubernetes 调度，实现边缘自治节点状态异常不触发重新调度；
• 针对 Kubernetes 能力完整及生态兼容，通过新增 YurtTunnel 组件，构建云边（Cloud To Edge Request）反向通道，保证 Kubectl，Promethus 等中心运维管控产品一致能力及用户体验；同时将中心其他能力下沉至边缘，包含各不同的工作负载及 Ingress 路由等；
• 针对边缘单元化管理能力，通过新增 YurtAppManager 组件，同时搭配 NodePool,YurtAppSet （原UnitedDeployment），YurtAppDaemon,ServiceTopology 等实现边缘资源，工作负载及流量三层单元化管理；
• 针对赋能边缘实际业务平台能力，通过新增 NodeResourceManager 实现边缘存储便捷使用，通过引入YurtEdgeXManager/YurtDeviceController 实现通过云原生模式管理边缘设备。

核心组件

OpenYurt 所有新增功能及组件，均是通过 Addon 与 Controller 方式来实现其核心必选与可选组件如下：

1．YurtHub(必选)：有边缘 (edge) 和云中心 (cloud) 两种运行模式；以 Static Pod 形态运行在云边所有节点上，作为节点流量的 SideCar，代理节点上组件和 kube-apiserver 的访问流量，其中边缘 YurtHub 会缓存的数据，实现临时边缘节点自治能力。

2．YurtTunnel(必选)：由 Server 服务端与 Agent 客户端组成，构建双向认证加密的云边反向隧道，转发云中心 (cloud) 到边缘 (edge) 原生的 Kubernetes 运维 APIs（logs/exec/metrics）请求流量。其中 Server 以 Deployment 工作负载部署在云中心，Agent 以 DaemonSet 工作负载部署在边缘节点。

3．YurtControllerManager(必选)：云中心控制器，接管原生 Kubernetes 的 NodeLifeCycle Controller，实现在云边网络异常时，不驱逐自治边缘节点的Pod应用；还有 YurtCSRController，用以审批边缘节点的证书申请。

4．YurtAppManager(必选)：实现对边缘负载进行单元化管理调度，包括 NodePool：节点池管理；YurtAppSet：原 UnitedDeployment，节点池维度的业务负载；YurtAppDaemon：节点池维度的 Daemonset 工作负载。以 Deploymen 工作负载部署在云中心。

5．NodeResourceManager(可选)：边缘节点本地存储资源的管理组件，通过修改 ConfigMap 来动态配置宿主机本地资源。以 DaemonSet 工作负载部署在边缘节点。

6．YurtEdgeXManager/YurtDeviceController(可选):通过云原生模式管控边缘设备，当前支持 EdgeX Foundry的集成。YurtEdgeXManager 以 Deployment 工作负载署在云中心，YurtDeviceController 以 YurtAppSet 工作负载署部署在边缘节点，并且以节点池 NodePool 为单位部署一套 YurtDeviceController 即可。

7．运维管理组件(可选)：为了标准化集群管理，OpenYurt 社区推出 YurtCluster Operator 组件，提供云原生声名式 Cluster API 及配置，基于标准 Kubernetes 自动化部署及配置 OpenYurt 相关组件，实现 OpenYurt 集群的全生命周期。旧 Yurtctl 工具建议只在测试环境使用。

除了核心功能及可选的专业功能外，OpenYurt 持续贯彻云边一体化理念，将云原生丰富的生态能力最大程度推向边缘，已经实现了边缘容器存储，边缘守护工作负载 DaemonSet，边缘网络接入 Ingress Controller 等，还有规划中的有 Service Mesh，Kubeflow，Serverless 等功能，拭目以待。

当前挑战

（1）云边网络

在边缘计算场景中，被提到最多的就是云边网络差且不稳定，其实国内基础网络在 2015 年开始全面升级，尤其是在“雪亮工程”全面完成之后，基础网络有一个很大的提升。上图摘自《第 48 次中国互联网络发展状况》报告，固网 100Mbps 接入占比已达 91.5%；无线网络接入已经都是 4G，5G 的优质网络。

而真正的挑战在云边网络组网，对于使用公有云的场景：公有云屏蔽数据中心网络，只提供了互联网出口带宽，通过互联网打通云边，通常只需要解决数据安全传输即可，接入不复杂。对于私有自建的 IDC 场景：打通云边网络并不容易，主要是运营商网络没有完全产品化，同时私有 IDC 层层防火墙等其他复杂产品，需要专业的网络人员才能完成实施工作。

（2）list-watch 机制与云边流量

List-Watch 机制是 Kubernetes 的设计精华，通过主动监听机制获取相关的事件及数据，从而保证所有组件松耦合相互独立，逻辑上又浑然一体。List 请求返回是全量的数据，一旦 Watch 失败，就需要重新 Relist 。但是 Kubernetes 有考虑管理数据同步优化，节点的 kubelet 只监听本节点数据，kube-proxy 会监听所有的 Service 数据，数据量相对可控；同时采用 gRPC 协议，文本报文数据相比业务数据非常小。上图是在节点 1200 节点的集群规模，做的压测数据监控图表。

真正的挑战在基础镜像及应用镜像下发，当前的基础镜像及业务镜像，即使在中心云，依然在探索各种技术来优化镜像快速分发的瓶颈；尤其是边缘的 AI 应用，一般都是由推送应用+模型库构成，推算应用的镜像相对较小，模型库的体积就非常，同时模型库随着自学习还需要频繁的更新，如果更高效的更新模型库，需要更多技术及方案来应对。

（3）边缘资源和算力

边缘的资源情况需要细分场景，针对运营商网络边缘，面向消费者的边缘计算，资源相对比较充足，最大的挑战是资源共享及隔离；针对实体产业的边缘，都会有不小的 IDC 支持，边缘资源非常充足，足以将整个云原生体系下沉；针对智能设备边缘，资源相对比较稀缺，但一般都会通过一个智能边缘盒子，一端连接设备，一端连接中心管控服务，从上图的 AI 边缘盒子来看，整体配置提升速度较快，长期来看，边缘的算力快速增强以此来满足更复杂更智能化的场景需求。

（4）Kubelet 比较重，运行占用资源多

对于 Kubelet 比较重，运行占用资源多的问题，需要深入了解节点资源分配及使用情况，通常节点的资源自下而上分为四层：

1. 运行操作系统和系统守护进程（如 SSH、systemd 等）所需的资源；

2. 运行 Kubernetes 代理所需的资源，如 Kubelet、容器运行时、节点问题检测器等；

3. Pod 可用的资源；

4. 保留到驱逐阈值的资源。

对于各层的资源分配设置的没有标准，需要根据集群的情况来权衡配置，Amazon Kubernetes 对 Kubelet 资源配置算法是 Reserved memory = 255MiB + 11MiB * MAX_POD_PER_INSTANCE；假设运行32 Pods，高达 90% 的内存都可以分配给业务使用，相对来说 Kubelet 资源占用并不高。

同时也要结合业务对高可用的要求,做响应的调整。针对边缘场景，一般不建议在一个节点上运行大量的Pods 稳定为大。

业务应用的云边管运协同模型

基于中心云的分布式业务应用架构，与云边分布式协同业务应用架构本质上有很大差别。在中心云更多的是基于 DDD 业务领域，将复杂的业务系统拆分成一个个相对独立的服务，整体构建一个松耦合的分布式应用；但在云边分布式场景下，更多强调的是集中式管控运营，分散式运作支撑，将管理运营系统集中在云中心，实现中心式管控，将支撑业务实时运作的应用分散至边缘，实现低延迟快速响应。

从业务应用来看，财务/经营，计划/管理两层属于管控运营类的应用，就是需要通过中心云统一汇聚，实现集中化强管控；对延迟不敏感，对安全，大数据分析能力等要求较高；控制，传感/执行，生产过程三层属于运作支撑类应用，也可以优先考虑中心云；如果业务场景对延迟敏感，才考虑通过边缘计算能力，实现分散式低时延响应；

从请求响应来看，对时延不敏感（50ms 以上）都有限考虑部署在中心云计算及云化的边缘产品（CDN）实现；对延迟敏感（小于10ms ），运营商骨干网完全无法支持的，考虑建设边缘计算平台，同时业务面临不小的投入及人员；

以实体物流领域为例，经典的 OTW 系统（OMS 订单管理系统，WMS 仓库管理系统，TMS 运输管理系统）其中 OT 就属于典型的管理运营系统，所以建议部署在中心云，通过中心云数据汇聚，实现拼单拆单，多式联运等跨区域业务；W 是仓库管理系统，管理四面墙的任务，属于运作支撑应用，并且仓库一般都有一些自动化设备，就可以考虑将 W 部署在边缘。

总结

边缘计算平台的建设，以 Kubernetes 为核心的云原生技术体系，无疑是当前最佳的选择与建设路径；但是云原生体系庞大，组件复杂，将体系下沉至边缘会面临很大的挑战与困难，同时充满巨大的机遇及想象空间。业务应用想要真正践行边缘的云原生体系，需要从理念、系统设计、架构设计等多方面来共同实现，才能充分发挥边缘的优势及价值。

作者：段嘉，新胜

原文链接

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