深度解密(二):Kubernetes从中心走向边缘

1.Kubernetes从中心走向边缘

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

深度解密(二):Kubernetes从中心走向边缘_第1张图片

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

1.1.Kubernetes架构及边缘化的挑战

深度解密(二):Kubernetes从中心走向边缘_第2张图片

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

        1.状态强一致且集中式存储架构,属于中心云计算的大成产品,基于大规模的池化资源的编排调度实现业务持续服务。

        2.Master管控节点与Worker工作节点通过List-Watch机制,实现状态任务实时同步,但是流量流量较大,Worker工作节点完全依赖Master节点持久化数据,无自治能力。

        3.Kubelet承载太多逻辑处理,各种容器运行时各种实现的兼容,还有Device Plugin硬件设备驱动,运行占用资源高达700M;对资源有限的边缘节点负担太重,尤其是低配的边缘设备。

        边缘计算涉及的范围大,场景复杂,没有统一的标准;Kubernetes开源社区的主线版本并没边缘场景的适配计划。

1.2.Kubernetes边缘化运行方案

深度解密(二):Kubernetes从中心走向边缘_第3张图片

        针对中心云计算及边缘计算这种云边分布式架构,需要将Kubernetes适配成适合边缘分布式部署的架构,借助Kubernetes的优势,弥补Kubernetes的不足,通过多集群管理实现统一管理,实现中心云管理边缘运行,整体分为三种方案:

        集群 Cluster:将Kubernetes标准集群下沉至边缘,优点是无需Kubernetes做定制化研发,同时可以支持Kubernetes多版本,支持业务真正实现云边架构一致;缺点就是管理资源占用多。方案比较适合区域云/中心云,边缘计算/本地计算以及规模较大的产业边缘场景。

         单节点 Single Node:将Kubernetes精简,部署在单节点设备之上,优点与集群 Cluster方案一致,缺点Kubernetes能力不完整,资源的占用会增加设备的成本,对业务应用无法保证云边一致的架构部署运行,是一个中庸方案,没有解决实际问题。

        边缘节点 Remote Node:基于Kubernetes二次开发增强扩展,将Kubernetes解耦适配成云边分布式架构的场景,中心化部署Master管理节点,分散式部署Worker管理节点。

1.3.Kubernetes边缘容器的碎片化

深度解密(二):Kubernetes从中心走向边缘_第4张图片

        Kubernetes已经成为容器编排和调度的事实标准,针对边缘计算场景,目前国内各个公有云厂商都开源了各自基于Kubernetes的边缘计算云原生项目:

        KubeEdge :由华为开源,采用边缘节点 Remote Node方案,深度定制了Kubernetes,精简了Kubelet,是面向边缘计算场景、专为边云协同设计的业界首个云原生边缘计算框架。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从中心走向边缘_第5张图片

        围绕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.业务应用的云边管运协同

深度解密(二):Kubernetes从中心走向边缘_第6张图片

        基于中心云的分布式业务应用架构,与云边分布式协同业务应用架构本质上是有很大的差别。在中心云更多的是基于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)

你可能感兴趣的:(云原生,云原生,云计算,kubernetes,容器,分布式)