DockOne微信分享(二五〇):Kubernetes在边缘计算领域的发展

【编者的话】现在开源边缘计算正在经历其业界最具活力的发展阶段。如此多的开源平台,如此多的整合以及如此多的标准化举措!这显示了构建更好平台的强大动力,以便将云计算带到边缘以满足不断增长的需求。同时Kubernetes现在已经成为容器编排的事实标准,在云原生领域大放异彩,能否可以将Kubernetes应用于边缘计算领域?具有哪些优势,又有哪些挑战?

什么是边缘计算

边缘计算(Edge computing)是一种在物理上靠近数据源头的网络边缘侧来融合网络、计算、存储、应用核心能力的开放平台。为终端用户提供实时、动态和智能的服务计算,边缘计算会将计算推向更接近用户的实际现场,这与需要在云端进行计算的传统云计算有着本质的区别,而这些区别主要表现在带宽负载、资源浪费、安全隐私保护以及异构多源数据处理上。

这里 有一个非常典型的例子, 就是章鱼,章鱼在捕猎时它们动作非常灵巧迅速,腕足之间高度配合,从来不会缠绕和打结。这是因为章鱼的神经元的分布是40%集中在他的头部,60%的神经元分布在他的触角上,是“多个小脑+一个大脑”的构造,类似于分布式计算。而边缘计算也是一种分布式计算,这种分布的好处呢,就是大部分重复的,低级的操作,都有触角来完成,是减轻了中央章鱼大脑的功耗,而让中央大脑只处理一些核心的数据。

随着5G,万物互联时代的到来,整个网络设备接入的数量,以及靠近设备端产生的数据会爆发式增长。这就遇到一个问题,如果所有数据处理都放到集中式数据中心,带宽,实时性,能耗,隐私等等都会面临很大的挑战。但采用边缘计算,就可以就近处理海量数据,大量设备可以实现高效协同工作,诸多问题迎刃而解。

因此边缘计算有着它独特的价值:

  1. 连接的广泛性, 因为他高度分散,能够覆盖到用户的实际现场各个终端。
  2. 是数据带宽的优化,可以将部分业务下沉到数据的产生源头,这样大部分的数据并没有经过骨干网,这对于整体网络的带宽是一个极大的优化,通过本地数据预处理,可以极大减少传输带宽的需求,这里面最典型的例子就是CDN,通过就近拉取视频流,这样骨干网络只有中心站点到CDN站点几份的数据传输。但是每个CDN站点的访客可能数以万计或者百万计。
  3. 是边缘的自治性,整个业务下沉到边缘,高度分散之后,边缘跟中心云的网络不能很好的保障,这就需要在骨干网络质量不能保证的情况下,需要边缘具备一定的自治性。这样才能更好的服务终端业务的请求。
  4. 从端到端的体验来说,主要体现的是业务的实时性,因为大部分的业务请求都在边缘处理, 整体的业务请求可以缩小到10ms以内。
  5. 最后一点, 因为实施边缘计算以后,可以减少大量不必要的敏感数据的跨网传输,可以在边缘做数据的预处理或者匿名化处理,把最敏感的数据处理放在边缘,这样可以大大的增强数据的安全性和隐私保护。

其实边缘计算这个概念已经出现了很长时间, 那么为什么近几年会快速发展呢,其中一方面是因为网络技术的快速发展,以及5G时代的到来,万物互联,一切连接皆有可能。从关键因素上来开,主要是4大点:

  1. 低时延,很多新兴的业务快速发展,包括自动驾驶,AI,VR等等,这些都对时延有非常苛刻的要求。
  2. 是随着接入到网络的设备数量大量增多, 导致数据爆发式增长, 这也是对边缘计算的一个很大的推动力。
  3. 是隐私安全,像现在人工智能, 以及对应的人脸,指纹识别等,但是这些最原始的指纹或者人脸的隐私信息, 我们不希望在公网传输被被人去盗取或者篡改数据,如果用边缘计算呢, 我们可以避免这种问题。
  4. 最后一点呢, 就是边缘的业务要具备自治能力,如果跟云端的网络请求断开,或者网络质量不高的情况下, 边缘业务要在出现故障时候,自我恢复。

这是推动边缘计算的四大主要因素。

基于Kubernetes构建边缘计算平台

那么需要什么框架去构建边缘计算平台呢?

我们可能首先想到的就是现在大火的Kubernetes。

对Kubernetes来说,它的核心功能基本上趋于成熟。现如今Kubernetes已经日益成为公有云/企业IT系统的基础设施,不仅大多数新兴的云原生负载是构建在Kubernetes上的,我们还将看到传统应用和负载也在以更快的速度向Kubernetes迁移,人们趋向于使用Kubernetes。而且Kubernetes 在朝着大规模,复杂场景的方向延伸,与AI、大数据、IoT、以及垂直行业等领域的结合越来越紧密。近来,越来越多围绕Kubernetes生态圈的创新,正在这些领域发生着。

与其他的新技术出世的情景类似,目前的边缘计算也是一片炙热的景象,多种技术形式出现,大家都在争夺这个领域。而且边缘计算的发展空间显然是无限的,实现的方式也是无限的,多种多样。这使得灵活性成为了非常重要的关键点。如果打算让下一代服务能够继续与传统IT进行交互操作,兼容传统IT,就要去边缘计算技术尽量能够在任何类型的架构(边缘、云或集中式硬件)中部署和扩展,去兼容异构的架构,而这更Kubernetes的设计理念有点类似。

Kubernetes项目源自于Google的borg项目,天生站在巨人的肩膀上,自2014年6月开源以来,Kubernetes在众多厂商和开源爱好者的共同努力下迅速崛起。现在已经基本成为容器编排的事实标准。而且越来越多的公司和组织加入CNCF,众多的开源爱好者参与Kubernetes社区开发,现在,Kubernetes已经成为容器编排领域的事实标准。 超过80家厂商都已经提供了经过认证的标准的Kubernetes服务。除此之外,还有很多公司都在使用Kubernetes的服务。而且围绕Kubernetes的云原生版图也是越来越丰富。

那么在边缘计算场景下使用Kubernetes ,具有哪些优势呢?

这里首先要从Kubernetes的架构说起。

了解Kubernetes的同学对Kubernetes已经很熟悉了,这里我再简单介绍一下:

从架构层面,Kubernetes是一种比较先进的松耦合的架构。控制层面有:API server,controller-manager,Scheduler,集群的状态都存在etcd中,数据面有:kubelet和kube-proxy安装在每个计算节点,用来管理Pod生命周期和网络的处理。

它所有的组件都是用过API server来进行访问的,这样可以保证数据访问的过程是可以被鉴权和认证的。同时所有组件之间,没有耦合关系, 他们都跟API server做交互,只依赖于API server,他的API是声明式设计的。同时在具体的应用声明周期的管理过程中呢, 他是通过多个API对象,彼此互不,和组合来实现解耦。

其次由于容器有轻量级、安全性、秒级启动等优秀的特性,容器天然的轻量化和可移植性,对应用进行容器化封装,使用容器本身的特性,充分使用build once,run anywhere的优势,轻量化基础镜像,降低资源的占用,非常适合边缘计算的场景,这一点边缘计算的厂家和开发者们都心知肚明。而且鉴于Kubernetes已经成为云原生编排的事实标准,因此携手Kubernetes进入边缘将很有可能结束边缘计算当前混沌的状态,并定义云端和边缘统一的应用部署和管理的标准。

最后在边缘计算场景下,有着大量的异构设备,每种设备都有自己独特的特征属性,我们可以充分利用Kubernetes提供的扩展的API资源:CRD功能,对这些设备进行数据建模,数据抽象,从而进行统一管理。

但是,Kubernetes不是天生为边缘计算而生的, 他是从集中式数据中心的场景里诞生出来的技术,因此在边缘计算场景下,Kubernetes也遇到了很多挑战:

为了减轻API server的访问压力以及集群状态的快速同步,Kubernetes优先使用事件监听(list-watch)方式而不是轮训方式来处理。这也是一个很大的亮点。这种情况比较适合于网络质量较好的数据中心去部署。

但是呢反过来讲,这会对边缘计算场景带来挑战。Master和Node通信是通过list watch机制,它没有办法在边缘场景这种受限的网络下很好的工作,本身list watch实现也是假设的是数据中心的网络,整体网络质量相对比较好的情况下。

另外Kubernetes节点是没有自治能力的,如何在网络质量不稳定的情况下,对边缘节点实现离线自治,这也是个问题。

Kubernetes各个组件其实是比较耗资源的,当然这种组件对资源的占用,相对于集中式数据中心的资源来说是微不足道的,但是在边缘,资源有限的场景下,Kubernetes是很难很好的工作的。一个kubelet启动大概就占用上百兆的内存,整个Kubernetes如果附上HA的能力,实际上会占用相当多的资源。如果你想你的应用跑在一些IOT网关或者设备上,他们可能只有几百兆的内存,或许一个原生kubelet都跑不起来。

还有就是,在边缘计算场景下,它有很多异构的边缘设备,支持的工业协议也不一样,那么这些边缘设备怎么管理,怎么让边缘应用通过比较解耦的方式与这些设备交互,这是Kubernetes本身没有提供的。我们只能充分利用Kubernetes 的CRD资源进行二次抽象。

还有一个问题是在边缘计算场景下,应用和节点的监控和报警问题,是在边端进行数据的监控报警,还是在云端统一进行收集,这也是一个很大的挑战,另一个问题,是在Kubernetes的架构选型上,我们到底采用哪种场景和架构。

第一种是将整个Kubernetes集群跑在边缘,第二种是将Kubernetes的控制层面跑在云端,去管理边缘的计算节点。

这是很多在Kubernetes构建边缘计算平台时候,所面临的问题。

实际上在Kubernetes IOT EDGE这个working group调查中显示,两者比例是30%的人更倾向于把整个Kubernetes集群跑在边缘,这种场景更多的是一些近场的边缘,就是相对来说,靠近边缘的网络位置上的这种边缘计算,要求呢就是计算能力相对要高一点,首先要能够承载Kubernetes本身组件的运行。

还有70%更多的人,更倾向于这种现场的边缘计算,这种边缘是一种更轻量,更极致的边缘计算追求。在这种情况下, 没有太多的跨节点的调度,或者应用动态迁移的诉求,很多应用都会跟某个设备做绑定。

基于Kubernetes的开源边缘计算项目

其实现在基于Kubernetes平台的开源边缘计算项目已经有很多个了,这里列出来了三个:

当然还有其他的开源项目,有兴趣的大家可以自行查找。

K3s定位是在边缘端轻量化的Kubernetes集群。

删除了Kubernetes一些alpha的feature,专门针对ARM环境进行了发布,为了处理Node节点在内网的场景,专门增加tunnel proxy的组件,来传递像exec 或者logs这些命令请求。对于Kubernetes的核心代码逻辑没有大的改动。

在资源占用上,已经比原生Kubernetes小了不少。 Server在480M,Agent是120M。

由于Server和Agent主要还是通过List-watch来通信,还是很适合于纯边缘侧部署一整套Kubernetes集群,不适合云边协同的场景,只能运行在边缘侧。社区这块,有Rancher开发和管理。

Mincrok8s也是轻量级的Kubernetes发行版。

Mincrok8s和K3s在应用场景上差不多,比较适合纯边缘的环境,也是缺少云边协同的解决方案。支持ARM/Win10/macOS安装,Kubelet占用大约80M内存,Master占用大约600M内存,K3s对Kubernetes的部分核心代码做了修改,但是Mincrok8s并没有做修改。

KubeEdge呢,由华为开源,2019年3月捐给CNCF基金会。

同时也是Kubernetes IOT Edge working group的关键参考架构之一。

主要是针对边缘侧做了优化:包括边缘恻节点的离线状态自治,云边消息传输默认使用WebSocket。支持云边协同,同时支持云端集群和边缘端集群的管理。

在边缘侧节点Edgecore的内存暂用率大约是70M,同时兼容Kubernetes的核心API功能,现在大约有超过250个贡献者参与其中。

每个开源项目都有它的侧重点,各有优势,大家在技术选型时候可以根据自己的业务场景选择不同的开源项目。

在这里主要着重讲一下KubeEdge。

KubeEdge详解

KubeEdge主打三个核心理念,首先是云边协同,边是云的延伸,用户的边可能位于私有网络,因此需要穿透私有网络,通过云来管理私有节点,KubeEdge默认采用WebSocket+消息封装来实现,这样只要边缘网络能访问外网情况下,就能实现双向通信,这就不需要边端需要一个公网的IP。同时呢,KubeEdge也优化了原生Kubernetes中不必要的一些请求,能够大幅减少通信压力,高时延状态下仍可以工作。

KubeEdge第二个核心理念是,做到节点级的元数据的持久化,比如Pod,ConfigMap等基础元数据,按照每个节点持久化在他的设备上,边缘的节点离线之后,它仍可以通过本地持久化的元数据来管理这些应用。熟悉Kubernetes的同学应该知道,当kubelet重启后, 它首先要向Master做一次list watch获取全量的数据,然后再进行应用管理工作,如果这时候边和云端的网络断开,是无法获得全量的基础元数据,也不能进行故障恢复。KubeEdge做了元数据的持久化后,可以直接从本地获得这些元数据,保障故障恢复的能力,保证服务的快速ready。

另外一个理念是极致的轻量化:在大多数边缘计算场景下,节点的资源是非常有限的,KubeEdge采用的方式是重组kubelet组件,移除了内置了面向于云厂商的驱动,通过CSI介入,去掉了static Pod,同时支持CRI,支持多种container runtime。

在空载时候,内存占用率很低。

这是KubeEdge整体架构,KubeEdge对原生Kubernetes的架构侵入比较小,都是旁路设计。

  • 云上:主要是通过旁路设计开发的CloudCore组件,边缘节点的同步和维护是通过CloudCore来维护,CloudCore通过list watch来跟Kubernetes集群做信息同步。而CloudCore里面内置的CloudHub模块和边端内置的EdgeHub模块,构建了一个WebSocket消息通道,通过结构化的消息封装,来同步Kubernetes的基础元数据,比如Pod,ConfigMap等等。另外CloudCore里面还包含edgecontroler和devicecontroller模块,这两个模块分别用来管理Kubernetes的元数据以及跟Device相关的CRD资源。
  • 边端: Edgecore,做到了持久化存储,edged相当于一个精简版的kubelet,支持CRI,底层可以对接多种container runtime,deviceTwin和DEventBus主要是做设备的元数据管理以及MQTT协议的订阅和发布。主要是跟终端设备通信用。
  • 在终端设备这里:现实场景里, 设备终端会有多种多样的访问协议,当然比较新兴的一些设备可能会直接支持MQTT协议,但是对于一些专用的设备或者工控的领域呢,会有他们专用的协议,KubeEdge呢采用了Mapper的设计,可以将这些专有的设备的协议转换成MQTT协议,来实现边缘的应用和云上的设备数据的同步和管理,当然KubeEdge最新版本还有SyncController,用来负责可靠性消息传输的同步问题,大家有兴趣的可以自行查看KubeEdge的源码。

那么在云端的核心组件CloudCore,主要由下面几部分组成:

  • Edge Controller主要是来负责边缘节点元数据的同步和管理,主要是Pod,ConfigMap等应用相关的元数据。
  • Device Controller是引入来管理边缘设备的模块,还有一套对应的CRD的定义,扩展的Kubernetes API,用来管理边缘设备。
  • CloudHub模块,上文也简单讲过了,主要是管理与边缘端EdgeHub的websocket的连接, 下发云端发来的数据,和上传边缘发来数据跟云端同步。
  • CSI Driver是为了实现标准的CSI方案而做的适配器。
  • Admission webhook主要用来给扩展性API做一些合法性的校验。

KubeEdge边端的核心组件Edgecore主要由下面几个模块组成:

  • EdgeHub:主要是跟云端交互,它跟云端的CloudHub是对等的,首先由EdgeHub发起云端的WebSocket连接。
  • MetaManager:本地持久化数据管理,KubeEdge的离线自治的能力主要是由这个模块实现的,简单来说每个Node用到了哪些Pod,哪些ConfigMap,Secret,都会通过MetaManager写入边缘本地的持久化数据库中,现在当前用的SQLite。
  • DeviceTwin和EventBus:主要是设备管理,比如说设备状态的上报,以及设备控制指令的下发,而EventBus相当于MQTT的一个client。
  • Edged:是一个非常轻量化裁剪过的kubelet,使用了应用生命周期管理中最关键的几个模块,去掉了云存储的驱动。支持CRI接口,适配多个container runtime。

整体KubeEdge比较适合于云边协同,边缘侧离线自治,通知对边缘侧资源要求比较苛刻的场景。如果您的场景需求跟这个比较类似, 建议尝试一下KubeEdge,来管理边缘集群。

同时呢,社区也有一些demo案例, 比如KubeEdge控制树莓派led,或者交通灯等等,可以让同学们能快速上手,对KubeEdge和边缘计算有个初步了解,有兴趣的同学可以研究一下。 https://github.com/kubeedge/examples

关于社区参与

KubeEdge在19年6月发布了1.0版本,现在最新版本是1.2.1,支持数据可靠性传输,Component API,边缘节点自动注册,适配Kubernetes 1.17版本等核心功能,计划今年的5月份,我们发布1.3版本,主要包括kubectl exec/logs的支持,CloudCore的HA,Edgemesh,云端监控数据收集等功能。也欢迎有兴趣的同学参与社区开发。

最后

边缘计算还有很广阔的发展前景,Kubernetes在边缘计算领域还有许多路要走,我相信基于Kubernetes的边缘计算开源项目也会不断完善,更好的解决边缘用户的需求。

Q&A

Q:边缘计算的边在哪里?网络的边缘到底是指什么,如何具象化?如何确定边的位置?边的位置和应用的关系?所谓的边与端的区别是什么?比如说摄像头算是边还是端?边缘网关算是边还是端?这个概念如何判断?

A:边缘计算的边具体在哪里,其实没有很明确的概念,一般主要看你的业务场景。网络边缘一般是指靠近客户现场一侧的网络边缘,在边缘计算场景下,应用是部署在边侧,就近计算,一般情况下摄像头我们可以是认为是端,但是如果摄像头自己有计算能力,有网络接入,能够部署应用,我们也可以理解是是边侧的计算节点。

Q:云边同步怎么做的?

A:KubeEdge云边同步主要通过EdgeHub和CloudHub这两个模块构建的WebSocket连接进行Kubernetes资源的同步的,连接请求首先由Edge端发起,一旦WebSocket建立后,云端就可以向边缘侧传递数据。

Q:如何保证云边状态的统一?Docker形式的边缘应用的优缺点有哪些?

A:KubeEdge最新版支持可靠性消息传输。云端的Kubernetes资源状态发生变化后,会默认通过WebSocket通道进行下发,如果这时候网络断开或者网络质量不高,会进行重传。但是这里为了防止资源状态数据的积压导致内存占用率过高,Kubeedge充分利用了Kubernetes的去重队列,对资源数据进行去重处理。

Q:Kubernetes Master,Kubernetes Node,KubeEdge Edge节点三者是什么关系?在Master上部署CloudCore去管理Edge节点,那Kubernetes Node是否参与其中?是不是说Edge节点只需要跟Master节点上的CloudCore进行通信,不关心Node;Node也只在Kubernetes集群内通信,不关心Edge?

A:Kubernetes Node和KubeEdge Edge节点没有本质区别,Kubernetes的Node是由kubelet像API server进行注册的,而KubeEdge Edge节点是KubeEdge通过云边协同机制通过CloudCore进行注册的。通过kubectl get node看到都是Node,区别在于Edge Node会有专门的标签。

Q:在Kubernetes中,云和终端节点如何通讯的,全双工还是半双工的?实时还是轮询的?IPv6和5G是否应用其中?如何连接其中节点的?对于大量节点之间如何规划网域?是否存在安全问题?如何解决安全隔离问题?

A:Kubernetes中,Master和Node是用过list-watch机制进行通信的,Node上的kubelet启动后,会首先进行list获取全量的数据,之后进行watch,只watch变化的数据。对于Kubernetes的容器网络来说,社区都有比较成熟的CNI插件,Flannel,Calico等等,可以根据自己具体的业务需求来使用不同的网络插件。如果对于安全隔离要求很高,可以让Kubernetes跑在VM上,使用VM本身的隔离性。

===》再问:我说的安全问题是,因为考虑节点之间的自治势必存在节点互通情况,比如这种场景:我和我家邻居冰箱都用同一个Cloud服务,会不会出现对方通过节点之间的通讯,hack访问到我的冰箱。

===》A:这种我觉得应该是称作为SaaS服务会比较合适,虽然你和你家邻居的冰箱感觉是在边缘侧,但是这种应该不属于边缘计算场景,而且节点自治和节点互通也没啥关系。

Q:KubeEdge和EdgeX能结合使用吗?

A:我个人没有应用实践过。KubeEdge是Kubernetes在云端向边端的延伸。如果你如果曾经将Kubernetes和EdgeX结合使用过,理论上KubeEdge也是可以的。

Q:老师您好,请问是不是每一个边缘侧Edge节点都需要具备能够访问公网的能力,但是不需要公网IP?如果要查看被调度到Edge端容器的日志应该怎么查,边缘侧没有kubelet,无法使用kubectl logs调用kubelet API查看日志。

A:是的,因为边缘侧节点需要与云端通信,一般情况下,边缘侧节点都需要具备访问公网的能力,但是不需要公网IP。关于kubectl logs这个特性社区会在1.3版本发布。

Q:完全是KubEedge新手的话,该从哪里入手呢?

A: https://kubeedge.io/zh/ ,另外有什么问题可以在KubeEdge社区里提issue或者slack里提问。另外KubeEdge社区每两周周三下午会有社区例会,相关连接可以查看: https://github.com/kubeedge/kubeedge

Q:KubeEdge当前应用于哪些商业场景?

A:最典型的是摄像头类场景,比如汽车保养门店,园区人脸识别入园,车牌识别等等。把AI计算类应用部署在客户现场一侧(比如汽车门店或者园区),直接就进图像识别。

Q:KubeEdge现在有支持哪些终端直接跑Node?除了前面提到的树莓派、交通灯。

A: 树莓派一般是用于开发测试场景。有兴趣的可以尝试一下华为的atlas开发者套件。一般ARM架构的服务器都可以。

Q15: 您觉得当前很多终端无法跑成KubeEdge的主要困难点在哪?

A:

Q16:现在运营商也在大力做边缘计算,请问5G与边缘计算结合的典型场景是什么?

A: 运营商主要是在做MEC层面。5G与边缘计算最典型的场景就是自动驾驶。

Q17:请问KubeEdge实际部署中遇到哪些问题?如何解决的? 现今面临的主要挑战是什么?

A:主要是边缘场景下,客户对云原生,Kubernetes的理解程度不一样,需要时间。这就跟最开始Kubernetes诞生以后,对传统观念是一个冲击。

Q:KubeEdge对关键功能是否有监控?监控方案是如何做的?报警规则分别有哪些?

A:KubEedge 1.3版本计划提供Metric功能,可以使用开源Prometheus去监控报警。

以上内容根据2020年3月24日晚微信群分享内容整理。 分享人 张杰,KubeEdge项目Approver,核心开发者 。DockOne每周都会组织定向的技术分享,欢迎感兴趣的同学加微信:liyingjiesf,进群参与,您有想听的话题或者想分享的话题都可以给我们留言。