【阅读原文】戳：OpenYurt现状与未来 以及企业级云边一体化最佳实践
前言：大家好，很高兴今天在这里和我的同事一起给大家分享OpenYurt相关的内容。我们今天的分享主要包括两部分：OpenYurt的现状与未来规划、OpenYurt在阿里内部的商业化实践。
OpenYurt现状与未来
OpenYurt是2020年5月份，由阿里云容器服务主导开源的云边端一体化的云原生解决方案，并于同年9月份，成为CNCF沙箱项目。OpenYurt是业界首个对云原生体系无侵入的边缘计算平台，支持从云端对分散的异构资源进行统一管理，帮助用户轻松完成在海量分散资源上的大规模应用交付、运维、管控。
基于Kubernetes生态，OpenYurt采用非侵入地方式实现了云边一体化架构。面向边缘计算场景，OpenYurt重点提供了边缘自治、多地域工作管理、跨地域网络通信、云原生边缘设备管理等核心能力。
在云管边的场景中，位于边缘侧的计算资源与云端管控之间通常需要通过公网建立连接，由于公网的不稳定性以及边缘侧网络环境的复杂性，会出现边缘资源与云端管控网络中断的风险。在原生的Kubernetes中，如果节点失联，节点上的业务会被驱逐，业务的稳定性受到挑战。为此，OpenYurt提供了断网情况下的自治能力，通过在边缘节点增加代理缓存、Pod Ip保持、Mac地址保持等方式，保证了在网络断开时，边缘侧业务的稳定性。
边缘节点一般处于内网环境，从云上的管控无法直接访问边缘资源来做运维动作，包括查看边缘侧业务日志、远程登录、采集监控数据等。为了解决这个问题，OpenYurt社区提供了跨地域的网络通信组件Raven，该组件能够在云边之间构建安全的反向运维通道，云上运维请求通过运维通道下发到边缘侧。
在边缘资源管理的过程中，我们也发现边缘资源具有典型的地域分散的特征，对于同一个应用，在不同的地域可能有不同的配置，包括实例数、镜像版本、存储配置等。如果采用Kubernetes社区原生的Workload，需要对每个地域单独部署对应的Workload，并且需要做好Label、配置管理。
为了简化多地域的业务管理，OpenYurt设计并实现了多地域工作负载管理模型。在该模型中透出节点池的概念，不同地域的节点被划分到不同的节点池中，在节点池之上实现业务的多地域（节点池）分发，当有节点池变化时，自动实现业务的上下线。同时，支持节点池级别的差异化配置，满足不同地域下，业务配置的差异化需求。
提供了业务的多地域部署模型之后，紧接着就会有多地域服务暴露的需求。因为在边缘场景，不通地域之间的网络无法互通，社区原生的服务暴露方式会使得请求的流量在整个集群内转发，从而出现服务不可用的情况。这就需要我们在每个地域都单独提供服务暴露端点，并且每个服务暴露端点只会将流量转发到本地域的服务上。为了保持原生Service使用的一致性体验，OpenYurt支持在Service上通过配置annotation的方式指定服务暴露的地域，并且实现了自动创建地域级别的服务暴露端点以及流量在地域内闭环的能力。
随着OpenYurt在越来越多的边缘场景落地，一些场景开始关注OpenYurt的大规模场景下的表现。在大规模的测试中，我们发现在云边一体化的架构下，如果有大规模的业务发布、更新，会导致云边流量大幅度变化，很容易达到带宽的上限，尤其是在公网通信场景，会带来比较大流量压力和成本。其中主要流量来自部署在边缘侧的系统组件（包括kubelet、coredns、kube-proxy等）在list-watch集群中全量的相关资源（包括：endpointslices、services等）。为此，OpenYurt社区提供节点级别的流量复用能力，使得节点上不同组件对同一资源的全量请求合并为一个请求，大幅度降低云边流量。
未来，OpenYurt会继续深耕在云边一体化场景，致力于解决云原生落地边缘计算的痛点问题，重点提供OpenYurt Local Mode、节点池级别的流量复用、多地域Ingress等新特性，优化现有的自治、网络、设备管理、易用性等能力，以应对更多的边缘计算场景。
企业级一体化最佳实践
在阿里云内部，有一款与OpenYurt对应的商业化产品ACK Edge，ACK Edge的整个架构分为三个部分：第一部分是云上多年积累产品能力、中间是网络层、最下面是边缘侧的资源和业务，借助云和边之间的网络能力，实现云边一体化的管理。云上的能力包括两个方面：一方面借助云管边的通道，将云上现有的产品能力（包括AI套件、日志、监控等）下层到边缘侧，减少在边缘自建常见云服务的成本；另一方面借助云边一体化的能力，将很多云原生的能力（包括容器化、容器编排调度等）下层的边缘，使得边缘侧的资源和业务也成为云原生体系的一部分。再来看中间的网络层，在云管边的架构中，势必需要一个稳定的网络解决方案，来承载云到边的运维流量，甚至说是业务流量，这套解决方案可以是云厂商提供的SD-WAN的方案，也可以是产品里提供的Raven方案。最后看边缘侧，边缘侧也是我们重点在打造的能力，这里也是和云数据中心管理有差异性的地方。边缘侧的资源具有网络环境复杂、资源异构性强、地域分散等特点。面对这些差异，我们提供了边缘网络自治、异构资源接入、单元化管理等重点能力。
云边一体化的架构被实现之后，就可以解决许多边缘场景下的问题，下面我们来看下几个典型的应用场景。
场景一：纳管分散的计算资源，实现云中心对分散在多个地域、不同类型计算资源的统一管理，任务统一调度。在这类场景下，资源呈现明显的地域性特征，每个地域资源规模不大，缺少统一管控，业务的部署和运维挑战大。将这些分散的计算资源接入ACK Edge做统一的管理，借助云原生运维体系，解决大规模业务管理和运维的问题，同时能将云上的产品能力（包括日志、监控告警等）下沉到边缘，保证分布在多地域的业务的稳定性。
场景二：纳管本地数据中心，借助云边专线，实现云上云下能力的无缝融合。在该场景中，边缘侧的资源位于本地的数据中心，规模相对较大，并且与云上有专线打通。这类业务可能是一些在线业务，也可能是批处理的任务以及AI训练推理等。这类场景对资源利用率以及弹性有比较大的需求。借助ACK Edge的云边一体化，使用云上成熟的资源管理能力，可以大幅度提高数据中心资源的利用率，同时与弹性能力无缝融合，很好地满足业务高峰时期对弹性的需求。
场景三：支持轻量化的设备管理，借助云管边的通道，实现业务的云上开发、测试、发布以及运维，提升端侧业务的运维效率。这类场景的资源通常较小，所处的网络环境复杂，缺少远程运维的方式，这些资源可能是交通一体机、场馆验票机、停车场的闸机、甚至车载设备等。通过ACK Edge提供的云边运维通道、边缘网络自治等能力，保证极端场景下业务的稳定运行。
ACK Edge自商业化以来，也支持了许多边缘场景的客户，我这边也有几个典型的客户案例给大家分享。
案例一：基于ACK Edge构建的大规模AI任务的训练以及推理平台。客户在本地数据中心的资源做AI任务的训练和推理时，遇到了资源利用率不高，训练过程缺少监控手段等问题。同时，在提供推理服务的高峰时期，本地数据中心的资源不满足业务高峰的需求。通过ACK Edge，与云上AI套件的能力（像GPU共享调度、数据集加速等）融合，提升了本地资源的利用率；借助云上的弹性能力，满足了推理任务高峰时期的弹性需求。
案例二：冬奥会场馆的智能验票服务。为了提升观众的入场速率，验票服务需要部署在场馆内部，受限于安全的原因，场馆内的资源都没有公网的入口，这对票务系统的开发、测试以及运维都带来了比较大的挑战。为此，借助ACK Edge云管边的能力，将场馆内的资源接到ACK Edge中来统一管理，实现了业务在云上开发以及云上部署和运维，最终，这套系统承载了北京冬奥会所有奥运场馆以及开闭目式的核验票服务。
案例三：专属钉混合云云边协同。专属钉的客户对数据的安全隐私有着极高的要求，为此，专属钉提出了数据在本地存储，应用在云上部署的混合云架构，为了保障这套架构的稳定性，专属钉需要在客户侧部署基础服务（包括流量加速、服务代理、数据库网关等）。随着客户增多，遇到了客户侧环境的异构性强、基础服务本身的管理难等问题。为了解决这些问题，采用ACK Edge来管理客户侧的基础服务以及资源，很好地屏蔽了底层资源的异构性，使得系统兼容性问题降低了99%，同时借助云边的运维能力，使得业务的问题定位效率提升5倍以上。
以上是我们这次的分享，谢谢大家！
我们是阿里巴巴云计算和大数据技术幕后的核心技术输出者。
获取关于我们的更多信息~
