从中心走向边缘——深度解析云原生边缘计算落地痛点
一 边缘计算的理解与思考
1 边缘计算的定义
2 “章鱼式”边缘计算
3 边缘计算的位置
4 边缘计算的类型
区域云/中心云：将中心云计算的服务在骨干网拓展延伸，将中心化云能力拓展至区域，实现区域全覆盖，解决在骨干网上耗时，将网络延迟优化至 30ms 左右，但逻辑上仍是中心云服务。
边缘云/边缘计算：将中心云计算的服务沿着运营商的网络节点延伸，构建中小规模云服务或类云服务能力，将网络延迟优化至 15ms 左右，比如多接入边缘计算（MEC）、CDN。
边缘计算/本地计算：主要是接近终端的现场设备及服务能力，将终端部分逻辑剥离出来，实现边缘自主的智能服务，由云端控制边缘的资源调度、应用管理与业务编排等能力，将网络延迟优化至 5ms 左右，比如多功能一体机、智能路由器等。
智能设备/专业云：基于云计算能力之上，围绕智能设备提供整体化，有竞争力的解决方案，包含智能设备、云端的服务以及端到云之间的边缘侧服务，比如视频监控云、G7 货运物联等；
产业边缘/行业云：也基于云计算能力之上，围绕行业应用及场景，提供套件产品及解决方案，比如物流云、航天云等。
5 小结
二 Kubernetes 从中心走向边缘
1 Kubernetes 架构及边缘化的挑战
状态强一致且集中式存储架构，属于中心云计算的大成产品，基于大规模的池化资源的编排调度实现业务持续服务。 Master 管控节点与 Worker 工作节点通过 List-Watch 机制，实现状态任务实时同步，但是流量较大，Worker 工作节点完全依赖 Master 节点持久化数据，无自治能力。 Kubelet 承载太多逻辑处理，各种容器运行时各种实现的兼容，还有 Device Plugin 硬件设备驱动，运行占用资源高达 700M；对资源有限的边缘节点负担太重，尤其是低配的边缘设备。
2 Kubernetes 边缘化运行方案
集群 Cluster：将 Kubernetes 标准集群下沉至边缘，优点是无需 Kubernetes 做定制化研发，同时可以支持 Kubernetes 多版本，支持业务真正实现云边架构一致；缺点是管理资源占用多。方案比较适合区域云/中心云、边缘计算/本地计算以及规模较大的产业边缘场景。
单节点 Single Node：将 Kubernetes 精简，部署在单节点设备之上，优点与集群 Cluster 方案一致，缺点是 Kubernetes 能力不完整，资源的占用会增加设备的成本，对业务应用无法保证云边一致的架构部署运行，没有解决实际问题。
边缘节点 Remote Node：基于Kubernetes 二次开发增强扩展，将 Kubernetes 解耦适配成云边分布式架构的场景，中心化部署 Master 管理节点，分散式部署 Worker 管理节点。
3 Kubernetes 边缘容器快速发展
4 如何构建云边一体化云原生平台
标准集群（大规模）：支持超过 400 个节点的大规模集群，配置为 ETCD + Master 3 台 8c16G，Prometheus + Ingress 5 台 8C16G， N * Work 节点；主要是业务规模较大的云原生应用运行场景；
标准集群（中等规模）：支持超过 100 个节点以内的集群，ETCD + Master + Prometheus 3 台 8c16G，N * Work 节点；主要是业务规模中等的场景；
边缘原生容器集群：在云端部署集群管理节点，将边缘节点单独部署业务现场，支持运行单业务场景的应用，比如 IoT 物理设备接入协议解析应用，视频监控分析 AI 算法模型等业务场景。
三 OpenYurt：智能边缘计算平台开源实践
1 设计原则
“云边一体化”原则：保证与中心云一致的用户体验及产品能力的基础上，通过云边管控通道将云原生能力下沉至边缘，实现海量的智能边缘节点及业务应用，基础架构提升至业界领的云原生架构的重大突破。
“零侵入”原则：确保面向用户开放的 API 与原生 Kubernetes 完全一致。通过节点网络流量代理方式（proxy node network traffic），对 Worker 工作节点应用生命周期管理新增一层封装抽象，实现分散式工作节点资源及应用统一管理及调度。同时遵循“UpStream First”开源法则；
“低负载”原则：在保障平台功能特性及可靠性的基础上，兼顾平台的通用性，严格限制所有组件的资源，遵循最小化，最简化的设计理念，以此实现最大化覆盖边缘设备及场景。
“一栈式”原则：OpenYurt 不仅实现了边缘运行及管理的增强功能，还提供了配套的运维管理工具，实现将原生 Kubernetes 与支持边缘计算能力的 Kubernetes 集群的相互一键高效转换；
2 功能特性
边缘节点自治：在边缘计算场景，云边管控网络无法保证持续稳定，通过增强适配解决原生 Worker 工作节点无状态数据，强依赖 Master 管控节点数据且状态强一致机制，这些在边缘场景不适配的问题。从而实现在云边网络不畅的情况下，边缘工作负载不被驱逐，业务持续正常服务；即使断网时边缘节点重启，业务依然能恢复正常；即边缘节点临时自治能力。 协同运维通道：在边缘计算场景，云边网络不在同一网络平面，边缘节点也不会暴露在公网之上，中心管控无法与边缘节点建立有效的网络链路通道，导致所有原生的 Kubernetes 运维 APIs（logs/exec/metrics）失效。适配增强 Kubernetes 能力，在边缘点初始化时，在中心管控与边缘节点之间建立反向通道，承接原生的 Kubernetes 运维 APIs（logs/exec/metrics）流量，实现中心化统一运维； 边缘单元化负载：在边缘计算场景，面向业务一般都是“集中式管控，分散式运行”这种云边协同分布式架构；对于管理端，需要将相同的业务同时部署到不同地域节点;对于边缘端，Worker 工作节是一般是分散在广域空间，并且具有较强的地域性，跨地域的节点之间网络不互通、资源不共享、资源异构等明显的隔离属性。适配增强 Kubernetes 能力，基于资源，应用及流量三层实现对边缘负载进行单元化管理调度。
边缘设备管理：在边缘计算场景，端侧设备才是平台真正的服务对象；基于云原生理念，抽象非侵入、可扩展的设备管理标准模型，无缝融合 Kubernetes 工作负载模型与 IoT 设备管理模型，实现平台赋能业务的最后一公里。目前，通过标准模型完成 EdgeX Foundry 开源项目的集成，极大的提升了边缘设备的管理效率。 本地资源管理：在边缘计算场景，将边缘节点上已有的块设备或者持久化内存设备，初始化成云原生便捷使用的容器存储，支持两种本地存储设备：（一）基于块设备或者是持久化内存设备创建的 LVM；（二）基于块设备或者是持久化内存设备创建的 QuotaPath。
3 OpenYurt 设计架构及原理
（1）设计架构
将元数据集中式且强一致的状态存储，分散至边缘节点，并且调整原生 Kubernetes 调度机制，实现自治节点状态异常不触发重新调度，以此实现边缘节点临时自治能力； 保证 Kubernetes 能力完整一致，同时兼容现有的云原生生态体系的同时，尽最大肯能将云原生体系下沉至边缘； 将中心大规模资源池化，多应用委托调度共享资源的模式，适配为面向地域小规模甚至单节点资源，实现边缘场景下，更精细化的单元化工作负载编排管理； 面向边缘实际业务场景需求，通过开放式社区，无缝集成设备管理、边缘 AI、流式数据等，面向边缘实际业务场景的开箱的通用平台能力，赋能更多的边缘应用场景。
（2）实现原理
针对边缘节点自治能力，一方面，通过新增 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 实现通过云原生模式管理边缘设备。