深度解密：Kubernetes从中心走向边缘

Posted 2022-03-28 巨子嘉

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了深度解密：Kubernetes从中心走向边缘相关的知识，希望对你有一定的参考价值。

：由华为开源，采用边缘节点 Remote Node方案，深度定制了Kubernetes，精简了Kubelet，使用MQTT重新研发了Master与Worker通信机制等，是面向边缘计算场景、专为边云协同设计的业界首个云原生边缘计算框架。KubeEdge于2019年3月正式进入CNCF成为沙箱级项目（Sandbox），也成为CNCF首个云原生边缘计算项目。并于2020年9月晋升为孵化级项目(Incubating)，成为 CNCF 首个孵化的云原生边缘计算项目。

OpenYurt：由阿里开源，采用边缘节点 Remote Node方案,业界首个开源的非侵入式边缘计算云原生平台，秉承“Extending your native Kubernetes to Edge”的非侵入式设计理念，拥有可实现边缘计算全场景覆盖的能力。2020年5 月OpenYurt正式对外开源，发布v0.1.0版本，成为业界首个开源的非侵入式边缘计算云原生平台。

SuperEdge：由腾讯、Intel、VMware、虎牙直播、寒武纪、首都在线和美团联合开源，采用边缘节点 Remote Node方案。基于Kubernetes针对边缘计算场景中常见的技术挑战提供了解决方案，如：单集群节点跨地域、云边网络不可靠、边缘节点位于 NAT 网络等。这些能力可以让应用很容易地部署到边缘计算节点上，并且可靠地运行。HTTP)和超文本传输安全协议(HTTPS)。

Baetyl：由百度开源，采用单节点 Single Node方案， 2019年9月23日，百度宣布将BAETYL捐赠给Linux基金会旗下社区，是中国首个 LF Edge捐赠项目。2020-07-08，Baetyl 2.0 正式发布，同步开源了边缘计算云管平台 Baetyl-Cloud。

总的来说，边缘容器的碎片化严重，导致构建边缘计算平台时难以抉择。从技术架构来看，几个边缘容器产品架构是有差异，总的架构思路主要是将Kubernetes解耦成适合云边，弱网络及资源稀缺的边缘计算场景，本质上没有太大差异；从产品功能来看，几个边缘容器产品功能基本一致，基本上都是云边协同，边缘自治，单元化部署功能等；

1.4.构建云边一体化云原生平台

围绕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，非侵入式设计，整体技术架构及实现更加优雅。

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

1.5.业务应用的云边管运协同

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

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

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

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

1.6.总结

突破中心云计算的边界，将云原生Kubernetes从中心拓展至边缘，构建云边一体化基础设施。面向业务,不仅统一了广域边缘侧分布式的应用运行时，同时实现了应用的中心化管理和边缘侧运行的云边协同。面向运维,业务的自动化运维、高可靠性保障，降低边缘应用的运维工作量，提升边缘计算业务创新效率。

总的来说，Kubernetes云原生是一个庞大且复杂的体系，将整个体系下沉至边缘，面临很大挑战与困难；业务应用想要真正践行边缘的云原生体系，需要从理念、系统设计、架构设计等多方面来公关实现，才能充分发挥边缘的优势及价值。云原生，边缘计算两个领域都在发展，国家也对场景化边缘计算建设提出更高的要求，未来已来，共同期待。

参考资料：

1.边缘计算社区：2020十大边缘计算开源项目

2.红帽：Edge computing with Red Hat OpenShift

3.运营商边缘计算网络技术白皮书（2019）

深度解密：OpenYurt边缘容器架构与原理

OpenYurt边缘容器架构与原理

在中心云，Kubernetes容器平台已经成为容器编排和调度的事实标准，但是在边缘计算领域，涉及范围较大且场景复杂，缺乏统一的标准；当前Kubernetes开源社区的主线版本，并没适配边缘场景的计划。

目前国内各个公有云厂商，都开源了各自基于Kubernetes的边缘计算云原生项目，主要有华为的KubeEdge，阿里的OpenYurt，腾讯的SuperEdge，百度的Baetyl等，碎片化严重，短时间很难有大一统的开源产品。

长远来看，建议通过标准的Kubernetes API来集成，这种兼容所有边缘容器的中庸方案。如果非要择其一，建议是OpenYurt，非侵入式设计，整体技术架构及实现更加优雅。本篇主要是通过OpenYurt架构与原理分析，深入浅出的了解边缘容器的技术详情。

1.1.OpenYurt产品理念及特性

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

1.1.1.OpenYurt产品理念

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

“云边一体化”原则：保证与中心云一致的用户体验及产品能力的基础上，通过云边管控通道将云原生能力下沉至边缘，实现海量的智能边缘节点及业务应用，基础架构提升至业界领的云原生架构的重大突破。

“零侵入”原则：确保面向用户开放的API与原生Kubernetes完全一致。通过节点网络流量代理方式（proxy node network traffic），对Worker工作节点应用生命周期管理新增一层封装抽象，实现分散式工作节点资源及应用统一管理及调度。同时遵循“UpStream First”开源法则；

“低负载”原则：在保障平台功能特性及可靠性的基础上，兼顾平台的通用性，严格限制所有组件的资源，遵循最小化，最简化的设计理念，以此实现最大化覆盖边缘设备及场景。

“一栈式”原则：OpenYurt不仅实现了边缘运行及管理的增强功能，还提供了配套的运维管理工具，实现将原生Kubernetes与支持边缘计算能力的Kubernetes集群的相互一键高效转换；

1.1.2.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

1.2.OpenYurt设计架构及原理

1.2.1.OpenYurt设计架构

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

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

（一）将元数据集中式且强一致的状态存储，分散至边缘节点，并且调整原生Kubernetes调度机制，实现自治节点状态异常不触发重新调度，以此实现边缘节点临时自治能力；

（二）保证Kubernetes能力完整一致，同时兼容现有的云原生生态体系的同时，尽最大肯能将云原生体系下沉至边缘；

（三）将中心大规模资源池化，多应用委托调度共享资源的模式，适配为面向地域小规模甚至单节点资源，实现边缘场景下，更精细化的单元化工作负载编排管理；

（四）面向边缘实际业务场景需求，通过开放式社区，无缝集成设备管理，边缘AI，流式数据等，面向边缘实际业务场景的开箱的通用平台能力，赋能更多的边缘应用场景。

1.2.2.OpenYurt实现原理

OpenYurt践行云原生架构理念，深刻理解Kubernetes实现机制，创新性的采用非侵入式架构设计，面向边缘计算场景实现云边协同分布式架构及中心管控边缘运行的能力：

针对边缘节点自治能力，一方面，通过新增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实现通过云原生模式管理边缘设备。

1.2.3.OpenYurt核心组件

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.3.OpenYurt认知误区

1.3.1.云边网络差，不稳定

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

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

1.3.2.list-watch机制，云边流量大

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

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

1.3.3.边缘资源少，算力不足

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

1.3.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，稳定为大。