DockOne微信分享(二七七):OpenYurt:延伸原生Kubernetes到边缘场景下的落地实践


【编者的话】随着云原生技术的逐步成熟,阿里云容器服务团队在具体落地实践过程中不断探索云原生技术的应用边界。同时随着物联网和5G的迅猛发展,传统的边缘计算架构已经不能满足业务发展的需要。如何基于云原生技术构建新一代的边缘计算平台成为行业的新焦点。如何解决云边协同,边缘自治等业界难题来帮助开发者轻松完成在海量边,端资源上大规模应用的交付,运维,管控?我们构建并开源了OpenYurt:业内首个基于原生Kubernetes构建的、对于Kubernetes非侵入式的边缘计算项目,无缝的融合了云原生和边缘计算,目前已经在万台边缘节点规模场景下落地实践。本文将介绍如何融合云原生技术和边缘计算,解决大规模应用的交付,运维,管控。

边缘计算背景

3.png

首先,我们从直观感受上看看什么是边缘计算。随着5G、IoT、音视频、直播、CDN等行业和业务的发展,我们看到一个行业趋势,就是越来越多的算力和业务开始下沉到距离数据源或者终端用户更近的地方,从而来获得很好的响应时间和更低的计算成本;这明显区别传统的中心式的云计算模式。并越来越被广泛应用于汽车、农业、能源、交通等各行各业。边缘计算,总结为一句话“让计算离数据和设备更近”。
4.png

再从IT架构上看边缘计算,可以看到它具有明显的按照业务时延和计算形态来确定的分层结构,这里分别引用Gartner和IDC对边缘计算架构的解释:Gartner将边缘计算分为“Near Edge”、“Far Edge”、“Cloud”三部分,分别对应常见的设备终端,云下IDC/CDN节点,以及公共云/私有云;而IDC则将边缘计算定义为更直观的“Heavy Edge”、“Light Edge”来分别表示数据中心维度,和低功耗计算的端侧。从图中我们可以看到分层结构中,层层相依,互相协作。这种定义也是现在业界对边缘计算和云计算关系所达成的一个共识,接下来再看看边缘计算的趋势。
5.png

去分析一个IT行业的趋势,通常包括业务、架构和规模三个维度;边缘计算的三大趋势是:第一,AI、IoT与边缘计算的融合,会有种类越来越多、规模越来越大、复杂度越来越高的业务运行在边缘计算场景中,从图上我们也能看到一些非常震撼人心的数字;第二,边缘计算作为云计算的延伸,将被广泛应用于混合云场景,这里面需要未来的基础设施能够去中心化、边缘设施自治、边缘云端托管能力,同样图上也有部分引用数字;第三个场景趋势是基础设施的发展将会引爆边缘计算的增长,随着5G、IoT、音视频行业的发展,边缘计算的爆发是理所当然,今年疫情期间在线直播、在线教育行业的爆发式增长也是一个例子。
6.png

随着架构的共识形成,落地过程中我们发现,边缘计算的规模、复杂度正逐日攀升,而短缺的运维手段和运维能力也终于开始不堪重负,那么如何去解这个问题呢? “云边端一体“的运维协同是目前比较能形成共识的一种方案。

云边一体的边缘云原生

作为云原生领域的从业人员,我们试着从云原生的角度来思考和解决这些问题:
8.png

首先我们一起回顾下云原生的定义和技术体系,眼下,云原生已经作为一系列的工具、架构、方法论而深入人心,并广泛使用;那么云原生到底是如何定义的呢?早期,云原生含义包括:容器、微服务、DevOps、CI/CD;18年以后CNCF又加入了服务网格和声明式API。而回过头,我们再粗线条的看看云原生的发展历史,早期因为Docker的出现,大量的业务开始容器化,Docker化,容器化通过统一交付件、隔离性从而带来了DevOps的快速发展;Kubernetes的出现让资源编排调度与底层基础设施解耦,应用和资源的管控也开始得心应手;随后,以Istio 为代表的服务网格技术·解耦了服务实现与服务治理能力。越来越多的企业、行业开始拥抱云原生。
9.png

接下来聊下阿里云的云原生产品家族,阿里云作为云原生的践行者,不论是集团内部全面上云,还是为广大的客户提供丰富的云原生业务,都是拥抱云原生最好的佐证;我们坚信云原生是未来;云原生技术已经无处不在, 作为云原生服务的提供者,我们认为云原生技术会继续高速发展,并被应用于“新的应用负载” ,“新的计算形态”和“新的物理边界”;从阿里云云原生产品家族大图中我们可以看到:容器正被用于越来越多类型应用和云服务中;并且通过越来越多的计算形态承载,如Serverless,函数计算等等;而丰富的形态也开始从传统的中心云走向边缘计算,走向终端。
10.png

在中心云的标准托管架构下,我们抽象出了云边端协同的云原生架构:在中心(云),我们保留了原汁原味的云原生管控和产品化能力,通过云边管控通道将之下沉到边缘,使海量边缘节点和边缘业务摇身一变成为云原生体系的工作负载,通过服务流量和服务治理更好的和端进行交互;从而完成业务、运维、生态的一体化。
11.png

那么,通过云边一体架构我们可以有哪些收益呢;首先,云上云下通过云原生体系实现云边一体化融合,从而为用户在任何基础设施上提供和云上一致的功能和体验,实现云边端一体化的应用分发,容器化的隔离特性、流量控制,网络策略等等能力让工作负载的运行更加安全;“云边端一体”有云原生的加持,将会更好的加速多云,云边融合进程。
11-2.png

聊完云边一体的云原生基础设施之后,接下来聊下云原生和边缘计算融合的难点,在实际落地过程中,我们主要识别了下面几个问题:
  • 边缘计算规模和业务复杂,采取原生Kubernetes的workload管理模型远不能满足现实需求
  • 云边网络通过公网相连,网络连接有很大不可控因素,可能带来边缘业务运行的不稳定因素
  • 由于边缘节点一般位于用户网络的防火墙内部,从而造成云边网络只能单向连通的客观条件,因此给原生的Kubernetes运维监控带来很大挑战
  • 最后是边缘资源种类多样,系统可能是Linux/Windows,架构也可能是amd64/arm/arm64等等,从而给边缘标准化支持带来巨大挑战


OpenYurt边缘计算云原生平台

接下来我们看下OpenYurt,业界首个非侵入式Kubernets的边缘计算云原生开源平台。
13.png

OpenYurt是一个典型的“中心-边缘”简洁架构。如架构图所示:边缘和云之间通过公网连接,其中蓝色框是原生Kubernetes的组件,橙色框是OpenYurt的组件。基于Kubernetes强大的插件化,Operator能力,OpenYurt保证对upstream kubernetes的零修改,因此保证了OpenYurt可以跟随社区同步演进,并且保证和云原生社区主流技术的兼容。OpenYurt项目在2020年9月份已经捐给CNCF,也保证了项目的中立性。同时OpenYurt目前在阿里内部已经大规模使用,管理了数百万核的规模,场景上覆盖了CDN,物联网,音视频,边缘AI等多种场景。也意味OpenYurt的品质和稳定性已经有足够验证。
14.png

OpenYurt目前已经发布三个版本,具备如下能力:边缘单元化、边缘自治、云边协同、无缝转换能力、异构资源(amd64/arm/arm64)支持能力、云上云下业务弹性和互通能力等。
15.png

单元化管理能力用于解决前面提到的融合难点1,主要是对节点提供分组、批量管理能力,并在分组内对应用编排部署、业务流量做更精细化管控,比如为了业务流量的安全、效率考虑可以将业务流量现在在某一个单元内;或者为了批量管理某一个区域内的节点,打标签,配置调度策略等等;相关能力由yurt-app-manager组件提供。
16.png

边缘自治能力用于解决前面提到的融合难点2,主要是云边网络断开或者连接不稳定时,确保边缘业务可以持续运行;相关能力由yurt-controller-manager和YurtHub组件提供。另外下个版本中还会继续增强边缘自治能力。
17.png

云边协同能力用于解决前面提到的融合难点3,主要是由于边缘节点位于用户内网,无法从云端访问时,造成原生Kubernetes运维能力(如kubectl logs/exec/port-forward,Prometheus等)无法支持。云边协同能力通过云边隧道解决云边网络只能单向通,从而支持原生Kubernetes运维能力。相关能力由tunnel-server/tunnel-agent组件提供。
18.png

无缝转换能力用于部分解决融合难点4,主要用于标准Kubernetes和OpenYurt集群之间的一键式转换,目前在Minikube,Kubeadm,ACK等工具部署的集群上完整验证过。也欢迎有兴趣的同学来支持和贡献其他工具部署的集群。相关能力由yurtctl组件提供。

OpenYurt案例介绍

接下来我们介绍一下OpenYurt的实践案例。
20.png

第一个,是盒马鲜生基于边缘云原生实现的“人货场”数字化融合转型,通过云原生体系将多种类型的边缘异构算力统一接入、统一调度,包括:ENS(阿里公共云边缘节点服务、线下自建边缘网关节点,GPU节点等)。获取了强大的资源弹性和业务混编带来的灵活性。
21.png

第二个,是交通领域的视频上云场景,通过云边端一体化协同,融合了中心云大交通智慧能力,边缘CDN/ENS等算力资源,给业务提供就近接入的资源能力;视频采集端设备的统一管理。边缘云原生的调度、编排、服务管理等能力穿插其中,三层融合。

最后,OpenYurt还是一个比较初期的CNCF官方边缘计算云原生项目,需要大家的支持和帮助,也欢迎大家参与OpenYurt社区共建。

Q&A

Q:YurtHub代理实现机制,需要修改什么配置吗?
A:主要是边缘节点上组件的云端访问地址需要调整为本地YurtHub监听地址(http://127.0.0.1:10261),其他配置不用修改。

Q:和KubeEdge的优劣对比分析?
A:首先这个问题可能第三方来评价会客观一点,有兴趣看下知乎这篇文章:https://www.zhihu.com/question/434413222。不过站在程序员或者云原生开发者角度,也可以谈一点个人的看法:OpenYurt对Kubernetes零修改,通过Kubernetes的插件和Operator机制进行增强,因此对原生Kubernetes使用者会比较友好。而KubeEdge对Kubernetes有比较大的修改(kubelet/kube-proxy/list-watch机制等重写了),对原生Kubernetes使用者的友好性会弱一点。当然还有不少其他差别,时间有限,有兴趣的同学可以自行研究。

Q:想问问贵司在万台规模的机器采用了哪些版本系统呢?内核有什么要求吗?
A:目前主要是AliOS,CentOS,以及Ubuntu,内核版本基本在3.10以上。

Q:请问案例1和2分别是什么样的节点规模?
A:集群规模都在100+以上。

Q:请问案例1中的GPU节点主要是什么功能?
A:案例1的AI训练是云端完成的,GPU节点主要做推理相关的任务。

Q:如果中心和边缘彻底网络断开了,边缘侧是否可以继续持久运作?
A:节点重启或者业务重启的状态下,业务是可以持续运行的。如果出现节点宕机的情况下,云端还无法准确识别并在其他正常节点重建,这个会在下个版本解决。

Q:请问目前阿里内部是否会有专门的技术、产品等团队来支撑?
A:目前阿里云容器服务产品ACK@Edge是基于OpenYurt开源项目来实现的,因此是有专门团队来统一支撑的。

Q:请问边缘侧的CPU是否有限制?端侧呢?例如arm。
A:边缘侧CPU架构目前支持amd64/arm/arm64。端侧主要是设备端,由运行在OpenYurt边缘节点上的业务负责。所以端侧目前不在OpenYurt的覆盖范围内。

Q:请问对未来3年内,边缘这一块的主流应用场景在哪一块,怎么看?
A:这是一个好问题,目前能确定的是像CDN,边缘AI,音视频,5G MEC,IOT等已经在大规模铺开边缘计算云原生方案。其他像后续的车联网,云游戏,其他传统行业(如农业,能源等)都在逐步展开,总之边缘这快ToB属性比较强。

Q:现在Kubernetes场景已经覆盖的场景大概能占总边缘场景的多少百分比呢?估计。
A:这个很难讲,我个人觉得目前比例应该很低,整个边缘计算场景的数字化转型应该刚刚开始。相信这是一个会持续可以做20年的行业^-^!

以上内容根据2021年1月26日晚微信群分享内容整理。 分享人何淋波(花名:新胜),来自于阿里云容器服务团队,OpenYurt作者&初创成员之一。2015年开始从事Kubernetes相关产品的设计,研发,开源等工作,先后负责和参与物联网边缘计算,边缘容器服务,OpenYurt等相关项目。DockOne每周都会组织定向的技术分享,欢迎感兴趣的同学加微信:liyingjiesf,进群参与,您有想听的话题或者想分享的话题都可以给我们留言。

0 个评论

要回复文章请先登录注册