OpenYurt：延伸原生 Kubernetes 到边缘场景下的落地实践
如何基于云原生技术构建新一代的边缘计算平台成为行业的新焦点。如何解决云边协同，边缘自治等业界难题来帮助开发者轻松完成在海量边，端资源上大规模应用的交付、运维、管控？我们构建并开源了 OpenYurt：业内首个基于原生 Kubernetes 构建的、对于 Kubernetes 非侵入式的边缘计算项目，无缝的融合了云原生和边缘计算，目前已经在万台边缘节点规模场景下落地实践。本文将介绍如何融合云原生技术和边缘计算，解决大规模应用的交付、运维、管控。
边缘计算
第一，AI、IoT 与边缘计算的融合，会有种类越来越多、规模越来越大、复杂度越来越高的业务运行在边缘计算场景中，从图上我们也能看到一些非常震撼人心的数字。
第二，边缘计算作为云计算的延伸，将被广泛应用于混合云场景，这里面需要未来的基础设施能够去中心化、边缘设施自治、边缘云端托管能力，同样图上也有部分引用数字。
第三个场景趋势是基础设施的发展将会引爆边缘计算的增长，随着 5G、IoT、音视频行业的发展，边缘计算的爆发是理所当然，今年疫情期间在线直播、在线教育行业的爆发式增长也是一个例子。
随着架构的共识形成，落地过程中我们发现，边缘计算的规模、复杂度正逐日攀升，而短缺的运维手段和运维能力也终于开始不堪重负，那么如何去解这个问题呢？“云边端一体“的运维协同是目前比较能形成共识的一种方案。
云边一体的边缘云原生
作为云原生领域的从业人员，我们试着从云原生的角度来思考和解决这些问题：
聊完云边一体的云原生基础设施之后，接下来聊下云原生和边缘计算融合的难点，在实际落地过程中，我们主要识别了下面几个问题：
边缘计算规模和业务复杂，采取原生 Kubernetes 的 workload 管理模型远不能满足现实需求。云边网络通过公网相连，网络连接有很大不可控因素，可能带来边缘业务运行的不稳定因素。由于边缘节点一般位于用户网络的防火墙内部，从而造成云边网络只能单向连通的客观条件，因此给原生的 Kubernetes 运维监控带来很大挑战。最后是边缘资源种类多样，系统可能是 Linux/Windows，架构也可能是 amd64/arm/arm64 等等，从而给边缘标准化支持带来巨大挑战。OpenYurt 边缘计算云原生平台
接下来我们看下 OpenYurt，业界首个非侵入式 Kubernets 的边缘计算云原生开源平台。
无缝转换能力用于部分解决融合难点 4，主要用于标准 Kubernetes 和 OpenYurt 集群之间的一键式转换，目前在 Minikube，Kubeadm，ACK 等工具部署的集群上完整验证过。也欢迎有兴趣的同学来支持和贡献其他工具部署的集群。相关能力由 yurtctl 组件提供。
OpenYurt 案例介绍
接下来我们介绍一下 OpenYurt 的实践案例。
第二个，是交通领域的视频上云场景，通过云边端一体化协同，融合了中心云大交通智慧能力，边缘 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
扫一扫，关注我们
