简介：边缘计算平台的建设，以 Kubernetes 为外围的云原生技术体系，无疑是以后最佳的抉择与建设门路；然而云原生体系宏大，组件简单，将体系下沉至边缘会面临很大的挑战与艰难，同时充斥微小的时机及设想空间。业务利用想要真正践行边缘的云原生体系，须要从理念、零碎设计、架构设计等多方面来独特实现，能力充分发挥边缘的劣势及价值。
作者：段嘉，新胜
云计算发展史，就是虚拟化技术的发展史。近 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），监控 / 上报运行状态。边缘计算场景存在以下比拟显著的挑战：
状态强统一且集中式存储架构，属于核心云计算的大成产品，基于大规模的池化资源的编排调度实现业务继续服务。
Master 管控节点与 Worker 工作节点通过 List-Watch 机制，实现状态工作实时同步，然而流量较大，Worker 工作节点齐全依赖 Master 节点长久化数据，无自治能力。
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 弱小的容器编排、调度能力，针对边缘资源无限，网络受限不稳固等状况适配加强；将核心云原生能力拓展至分散式边缘节点，实现面向边缘业务就近低提早服务；同时买通反向安全控制运维链路，提供便捷高效的，云端集中式边缘设施及利用的对立运维治理能力。其外围性能个性如下：
边缘节点自治：在边缘计算场景，云边管控网络无奈保障继续稳固，通过加强适配解决原生 Worker 工作节点无状态数据，强依赖 Master 管控节点数据且状态强统一机制，这些在边缘场景不适配的问题。从而实现在云边网络不畅的状况下，边缘工作负载不被驱赶，业务继续失常服务；即便断网时边缘节点重启，业务仍然能恢复正常；即边缘节点长期自治能力。
协同运维通道：在边缘计算场景，云边网络不在同一网络立体，边缘节点也不会裸露在公网之上，核心管控无奈与边缘节点建设无效的网络链路通道，导致所有原生的 Kubernetes 运维 APIs（logs/exec/metrics）生效。适配加强 Kubernetes 能力，在边缘点初始化时，在核心管控与边缘节点之间建设反向通道，承接原生的 Kubernetes 运维 APIs（logs/exec/metrics）流量，实现中心化对立运维；
边缘单元化负载：在边缘计算场景，面向业务个别都是“集中式管控，分散式运行”这种云边协同分布式架构；对于治理端，须要将雷同的业务同时部署到不同地区节点; 对于边缘端，Worker 工作节是个别是扩散在广域空间，并且具备较强的地域性，跨地区的节点之间网络不互通、资源不共享、资源异构等显著的隔离属性。适配加强 Kubernetes 能力，基于资源，利用及流量三层实现对边缘负载进行单元化治理调度。
通过 OpenYurt 开源社区引入更多的参与方共建，联结研发形式提供更多的可选的业余性能，OpenYurt 个性正在逐步完善，并扩充笼罩能力：
边缘设施治理：在边缘计算场景，端侧设施才是平台真正的服务对象；基于云原生理念，形象非侵入、可扩大的设施治理规范模型，无缝交融 Kubernetes 工作负载模型与 IoT 设施治理模型，实现平台赋能业务的最初一公里。目前，通过规范模型实现 EdgeX Foundry 开源我的项目的集成，极大的晋升了边缘设施的管理效率。
本地资源管理：在边缘计算场景，将边缘节点上已有的块设施或者长久化内存设施，初始化成云原生便捷应用的容器存储，反对两种本地存储设备：（一）基于块设施或者是长久化内存设施创立的 LVM；（二）基于块设施或者是长久化内存设施创立的 QuotaPath。
OpenYurt 设计架构及原理
（1）设计架构
原生 Kubernetes 是一个核心式的分布式架构，Master 管制节点负责管理调度及管制集群运行状态；Worker 工作节点负责运行容器（Container）及监控 / 上报运行状态；
OpenYurt 以原生 Kubernetes 为根底，针对边缘场景将中，心式分布式架构（Cloud Master，Cloud Worker）解耦适配为中心化管控分散式边缘运行（Cloud Master,Edge Worker），造成一个核心式大脑，多个分散式小脑的章鱼式云边协同分布式架构，其次要外围点是：
将元数据集中式且强统一的状态存储，扩散至边缘节点，并且调整原生 Kubernetes 调度机制，实现自治节点状态异样不触发从新调度，以此实现边缘节点长期自治能力；
保障 Kubernetes 能力残缺统一，同时兼容现有的云原生生态体系的同时，尽最大肯能将云原生体系下沉至边缘；
将核心大规模资源池化，多利用委托调度共享资源的模式，适配为面向地区小规模甚至单节点资源，实现边缘场景下，更精细化的单元化工作负载编排治理；
面向边缘理论业务场景需要，通过开放式社区，无缝集成设施治理、边缘 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 比拟重，运行占用资源多的问题，须要深刻理解节点资源分配及应用状况，通常节点的资源自下而上分为四层：
- 运行操作系统和零碎守护过程（如 SSH、systemd 等）所需的资源；
- 运行 Kubernetes 代理所需的资源，如 Kubelet、容器运行时、节点问题检测器等；
- Pod 可用的资源；
- 保留到驱赶阈值的资源。
对于各层的资源分配设置的没有规范，须要依据集群的状况来衡量配置，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 为外围的云原生技术体系，无疑是以后最佳的抉择与建设门路；然而云原生体系宏大，组件简单，将体系下沉至边缘会面临很大的挑战与艰难，同时充斥微小的时机及设想空间。业务利用想要真正践行边缘的云原生体系，须要从理念、零碎设计、架构设计等多方面来独特实现，能力充分发挥边缘的劣势及价值。
原文链接
本文为阿里云原创内容，未经容许不得转载。