![头图.png]()
作者 | 何淋波（新胜） 来源|阿里巴巴云原生公众号
随着云原生技术的逐步成熟，阿里云容器服务团队在具体落地实践过程中不断探索云原生技术的应用边界。同时随着物联网和 5G 的迅猛发展，传统的边缘计算架构已经不能满足业务发展的需要。
如何基于云原生技术构建新一代的边缘计算平台成为行业的新焦点。如何解决云边协同，边缘自治等业界难题来帮助开发者轻松完成在海量边，端资源上大规模应用的交付、运维、管控？我们构建并开源了 OpenYurt：业内首个基于原生 Kubernetes 构建的、对于 Kubernetes 非侵入式的边缘计算项目，无缝的融合了云原生和边缘计算，目前已经在万台边缘节点规模场景下落地实践。本文将介绍如何融合云原生技术和边缘计算，解决大规模应用的交付、运维、管控。
边缘计算
![1.png]()
首先，我们从直观感受上看看什么是边缘计算。随着 5G、IoT、音视频、直播、CDN 等行业和业务的发展，我们看到一个行业趋势，就是越来越多的算力和业务开始下沉到距离数据源或者终端用户更近的地方，从而来获得更好的响应时间和更低的计算成本，这明显区别传统的中心式的云计算模式，并越来越被广泛应用于汽车、农业、能源、交通等各行各业。边缘计算，总结为一句话“让计算离数据和设备更近”。
![2.png]()
再从 IT 架构上看边缘计算，可以看到它具有明显的按照业务时延和计算形态来确定的分层结构，这里分别引用 Gartner 和 IDC 对边缘计算架构的解释：Gartner 将边缘计算分为“Near Edge”、“Far Edge”、“Cloud”三部分，分别对应常见的设备终端，云下 IDC/CDN 节点，以及公共云/私有云；而 IDC 则将边缘计算定义为更直观的“Heavy Edge”、“Light Edge”来分别表示数据中心维度、低功耗计算的端侧。从图中我们可以看到分层结构中，层层相依，互相协作。这种定义也是现在业界对边缘计算和云计算关系所达成的一个共识，接下来再看看边缘计算的趋势。
![3.png]()
去分析一个 IT 行业的趋势，通常包括业务、架构和规模三个维度；边缘计算的三大趋势是：
-
第一，AI、IoT 与边缘计算的融合，会有种类越来越多、规模越来越大、复杂度越来越高的业务运行在边缘计算场景中，从图上我们也能看到一些非常震撼人心的数字。
-
第二，边缘计算作为云计算的延伸，将被广泛应用于混合云场景，这里面需要未来的基础设施能够去中心化、边缘设施自治、边缘云端托管能力，同样图上也有部分引用数字。
-
第三个场景趋势是基础设施的发展将会引爆边缘计算的增长，随着 5G、IoT、音视频行业的发展，边缘计算的爆发是理所当然，今年疫情期间在线直播、在线教育行业的爆发式增长也是一个例子。
![4.png]()
随着架构的共识形成，落地过程中我们发现，边缘计算的规模、复杂度正逐日攀升，而短缺的运维手段和运维能力也终于开始不堪重负，那么如何去解这个问题呢？“云边端一体“的运维协同是目前比较能形成共识的一种方案。
云边一体的边缘云原生
作为云原生领域的从业人员，我们试着从云原生的角度来思考和解决这些问题：
![5.png]()
首先我们一起回顾下云原生的定义和技术体系，眼下，云原生已经作为一系列的工具、架构、方法论而深入人心，并广泛使用；那么云原生到底是如何定义的呢？早期，云原生含义包括：容器、微服务、DevOps、CI/CD；18 年以后 CNCF 又加入了服务网格和声明式 API。而回过头，我们再粗线条的看看云原生的发展历史，早期因为 Docker 的出现，大量的业务开始容器化、Docker 化，容器化通过统一交付件、隔离性从而带来了 DevOps 的快速发展；Kubernetes 的出现让资源编排调度与底层基础设施解耦，应用和资源的管控也开始得心应手；随后，以 Istio 为代表的服务网格技术解耦了服务实现与服务治理能力。越来越多的企业、行业开始拥抱云原生。
![6.png]()
接下来聊下阿里云的云原生产品家族。阿里云作为云原生的践行者，不论是集团内部全面上云，还是为广大的客户提供丰富的云原生业务，都是拥抱云原生最好的佐证；我们坚信云原生是未来；云原生技术已经无处不在, 作为云原生服务的提供者，我们认为云原生技术会继续高速发展，并被应用于“新的应用负载” ，“新的计算形态”和“新的物理边界”；从阿里云云原生产品家族大图中我们可以看到：容器正被用于越来越多类型应用和云服务中；并且通过越来越多的计算形态承载，如 Serverless，函数计算等等；而丰富的形态也开始从传统的中心云走向边缘计算，走向终端。
![7.png]()
在中心云的标准托管架构下，我们抽象出了云边端协同的云原生架构：在中心（云），我们保留了原汁原味的云原生管控和产品化能力，通过云边管控通道将之下沉到边缘，使海量边缘节点和边缘业务摇身一变成为云原生体系的工作负载，通过服务流量和服务治理更好的和端进行交互；从而完成业务、运维、生态的一体化。
![8.png]()
那么，通过云边一体架构我们可以有哪些收益呢；首先，云上云下通过云原生体系实现云边一体化融合，从而为用户在任何基础设施上提供和云上一致的功能和体验，实现云边端一体化的应用分发，容器化的隔离特性、流量控制，网络策略等等能力让工作负载的运行更加安全；“云边端一体”有云原生的加持，将会更好的加速多云，云边融合进程。
![9.png]()
聊完云边一体的云原生基础设施之后，接下来聊下云原生和边缘计算融合的难点，在实际落地过程中，我们主要识别了下面几个问题：
-
边缘计算规模和业务复杂，采取原生 Kubernetes 的 workload 管理模型远不能满足现实需求。
-
云边网络通过公网相连，网络连接有很大不可控因素，可能带来边缘业务运行的不稳定因素。
-
由于边缘节点一般位于用户网络的防火墙内部，从而造成云边网络只能单向连通的客观条件，因此给原生的 Kubernetes 运维监控带来很大挑战。
-
最后是边缘资源种类多样，系统可能是 Linux/Windows，架构也可能是 amd64/arm/arm64 等等，从而给边缘标准化支持带来巨大挑战。
OpenYurt 边缘计算云原生平台
接下来我们看下 OpenYurt，业界首个非侵入式 Kubernets 的边缘计算云原生开源平台。
![10.png]()
OpenYurt 是一个典型的“中心-边缘”简洁架构。如架构图所示：边缘和云之间通过公网连接，其中蓝色框是原生 Kubernetes 的组件，橙色框是 OpenYurt 的组件。基于 Kubernetes 强大的插件化，Operator 能力，OpenYurt 保证对 upstream kubernetes 的零修改，因此保证了 OpenYurt 可以跟随社区同步演进，并且保证和云原生社区主流技术的兼容。OpenYurt 项目在 2020 年 9 月份已经捐给 CNCF，也保证了项目的中立性。同时 OpenYurt 目前在阿里内部已经大规模使用，管理了数百万核的规模，场景上覆盖了 CDN，物联网，音视频，边缘AI等多种场景。也意味着 OpenYurt 的品质和稳定性已经有足够验证。
![11.png]()
OpenYurt 目前已经发布三个版本，具备如下能力：边缘单元化、边缘自治、云边协同、无缝转换能力、异构资源（amd64/arm/arm64）支持能力、云上云下业务弹性和互通能力等。
![12.png]()
单元化管理能力用于解决前面提到的融合难点 1，主要是对节点提供分组、批量管理能力，并在分组内对应用编排部署、业务流量做更精细化管控，比如为了业务流量的安全、效率考虑可以将业务流量现在在某一个单元内；或者为了批量管理某一个区域内的节点，打标签，配置调度策略等等；相关能力由 yurt-app-manager 组件提供。
![13.png]()
边缘自治能力用于解决前面提到的融合难点 2，主要是云边网络断开或者连接不稳定时，确保边缘业务可以持续运行；相关能力由 yurt-controller-manager 和 YurtHub 组件提供。另外下个版本中还会继续增强边缘自治能力。
![14.png]()
云边协同能力用于解决前面提到的融合难点 3，主要是由于边缘节点位于用户内网，无法从云端访问时，造成原生 Kubernetes 运维能力（如 kubectl logs/exec/port-forward，Prometheus 等）无法支持。云边协同能力通过云边隧道解决云边网络只能单向通，从而支持原生 Kubernetes 运维能力。相关能力由 tunnel-server/tunnel-agent 组件提供。
![15.png]()
无缝转换能力用于部分解决融合难点 4，主要用于标准 Kubernetes 和 OpenYurt 集群之间的一键式转换，目前在 Minikube，Kubeadm，ACK 等工具部署的集群上完整验证过。也欢迎有兴趣的同学来支持和贡献其他工具部署的集群。相关能力由 yurtctl 组件提供。
OpenYurt 案例介绍
接下来我们介绍一下 OpenYurt 的实践案例。
![16.png]()
第一个，是盒马鲜生基于边缘云原生实现的“人货场”数字化融合转型，通过云原生体系将多种类型的边缘异构算力统一接入、统一调度，包括：ENS（阿里公共云边缘节点服务、线下自建边缘网关节点，GPU 节点等）。获取了强大的资源弹性和业务混编带来的灵活性。
![17.png]()
第二个，是交通领域的视频上云场景，通过云边端一体化协同，融合了中心云大交通智慧能力，边缘 CDN/ENS 等算力资源，给业务提供就近接入的资源能力；视频采集端设备的统一管理。边缘云原生的调度、编排、服务管理等能力穿插其中，三层融合。
最后，OpenYurt 还是一个比较初期的 CNCF 官方边缘计算云原生项目，需要大家的支持和帮助，也欢迎大家参与 OpenYurt 社区共建。
Q & A
Q：YurtHub 代理实现机制，需要修改什么配置吗？ A：主要是边缘节点上组件的云端访问地址需要调整为本地 YurtHub 监听地址（http://127.0.0.1:10261），其他配置不用修改。
Q：和 KubeEdge 的优劣对比分析？ A：首先这个问题可能第三方来评价会客观一点，有兴趣看下知乎这篇文章：《家里的树莓派，如何加入阿里云搭建的 K8s 集群？》。不过站在程序员或者云原生开发者角度，也可以谈一点个人的看法：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 年的行业^-^！
分享人简介
何淋波（花名：新胜），来自于阿里云容器服务团队，OpenYurt 作者&初创成员之一。2015 年开始从事 Kubernetes 相关产品的设计，研发，开源等工作，先后负责和参与物联网边缘计算，边缘容器服务，OpenYurt 等相关项目。
内容来源：Dockone
点击访问“Kubernetes 与云原生应用更多开源实践”大讲堂，4 次开源技术直播， 60+ 节 Kubernetes 经典课程，3 本云原生电子书，将前沿的容器技术和开源实践一网打尽!
