OpenYurt v1.2 新版本深度解读（一）: 聚焦边云网络优化

> **本文作者：** > > ***信**，OpenYurt Member，Apache dubbo PMC，专注于云原生边缘计算的系统架构和解决方案 > > **张逸飞**，OpenYurt Member，浙江大学 SEL 实验室 云原生边缘计算智能开源平台 CNCF OpenYurt 于近期发布了 v1.2 版本。OpenYurt 是业界首个对云原生体系无侵入智能边缘计算平台，具备全方位的“云、边、端一体化”能力，能够快速实现海量边缘计算业务和异构算力的高效交付、运维及管理。 在 v1.2 版本中，OpenYurt 遵循社区提出的“节点池治理”理念，新增组件 Pool-Coordinaotr，提出了一套针对云边场景的资源、网络、应用、监控等角度的边缘治理方案。本文首先聚焦云边场景下的网络优化问题的解决进行解读，敬请持续关注。 ## Pool-Coordinator 节点池治理及其对云边网络的优化 ### 组件背景 早在去年年初，社区就提出了 “节点池治理” 的概念。节点池为 OpenYurt 生态概念，表示集群内一组网络互通的边缘机器节点。在云边协同场景，边缘 IOT 设备与算力往往依赖多台机器节点工作，节点池概念为 OpenYurt 生态在边缘算力的管控粒度方面增加了一个维度。而“节点池治理”，专注于边缘机器的资源、网络、生命周期、可观测指标等等角度，提供了边缘测视角与管理思路。 Pool-Coordinator 在社区内首次践行了这一概念，提出了一套针对云边场景的资源、网络、应用、监控等角度的边缘治理方案，具备高可用能力。 ### 边缘基础组件对云边网络的需求与挑战 边缘基础组件对于边云网络的要求，驱使着 OpenYurt 为开发者提供更合理、更优化的解决方案。 首先是云边网络带宽基础条件的问题。在云原生边缘计算的场景中，云边网络通路带宽往往受到各个方面的限制，例如机器资源，物理距离，资金成本等，这就导致对于部分厂商和用户，其云边网络条件带宽较低，甚至在各别特定环境的节点池带宽极低。 其次是集群资源数据量的问题。边缘集群往往覆盖较多地域、机器节点与物理设备，相比于普通集群，其覆盖地域广阔，规模较大，集群整体资源量也就相对较多。对于部分集群基础组件，例如代理组件、CNI 组件、DNS 组件，甚至部分业务组件，例如设备驱动程序，边缘基础架构中间件等，需要在启动时通过 K8S List/Watch 机制来拉取全量资源并监听，这个过程对网络要求较高。 再者是边缘基础组件的重要性，在新节点纳管入边缘集群时，初始化程序会拉起一系列 OpenYurt 边缘基础组件与配置，待顺利初始化，才会调度业务程序至节点。一旦边缘基础组件由于带宽原因，拉取依赖资源失败，会导致边缘机器业务应用无法启动，边缘节点算力扩容失败。另一方面，处于运行中的边缘基础组件，如果长时间拉取资源失败，可能造成网络、代理、存储资源与中心不同步，造成业务风险。 ### 能力、架构实现与工作方式 #### 3.1 Pool-Scope（节点池维度）资源缓存 Pool-Coordinator 会为节点池维度的资源提供边缘侧缓存，从而降低因为这些资源的大量 list/watch 请求造成的云边网络带宽问题。 在部署阶段，开发者可以通过安装 Chart 包的方式，将 Pool-Coordinator 组件安装至集群，该过程利用了 OpenYurt 生态的 YurtAppDaemon 资源，将这一组件以节点池粒度部署至所有的边缘节点池，每个节点池一个实例。 待 Pool-Coordinator 实例启动，会由选主机制选出的 Leader YurtHub 将 Pool-Scope 资源，例如 endpoints/endpointslice 拉取至边缘，进而同步至 Pool-Coordinator 组件，缓存起来，以供节点池内全部节点使用。  节点池内全部节点上运行的 YurtHub，将 Pool-Scope 资源读请求代理至 Pool-Coordinator。理论上，针对一个资源的全量请求，一个节点池只需要一条云边长链接即可，节点池内的这些资源的读请求，都交由 Pool-Coordinator 向下提供服务，从而极大程度降低云边网络消耗。特别是在具有带宽要求的弱网络场景，Pool-Coordinator 可以削弱由于边缘基础容器启动/重建导致的大量请求，以及减少运行时期的云边资源下发量。 Pool-Scope 资源默认定义为 endpoints 和 endpointslices 两种资源。这两种资源在 YurtHub 代理的云边流量中占比较高，这在规模较大集群中体现的更为明显；另外 Pool-Scope 资源要求为节点池内公用的资源，与调用方所属节点无关，这也适配于上述两者。Pool-Scope 资源可由用户配置其他资源，例如 Pods，Node，以及 CR，以应对在特定资源量大的网络优化场景。 #### 3.2 YurtHub 的初始化、选主与容灾机制 当新的节点池创建并添加算力时，YurtHub 作为边缘机器节点的底层进程将最先启动。其优先直连 APIServer，执行正常的初始化逻辑。待节点加入集群，OpenYurt 组件 Yurt-App-Manager 将按需调度边缘节点池组件 Pool-Coordinator 至该机器。等到 Pool-Coordinator 成功启动，YurtHub 将探知其可用状态，与之建联交互。YurtHub 提供 --enable-coordinator 启动参数，将该参数置为true时，YurtHub 会对节点池 Pool-Coordinator 组件进行探知，为节点池内灵活的切流、按需启动提供了支持。 一个节点池内的全部 YurtHub 实例存在读写冲突问题，我们指定这些 YurtHub 通过 Pool-Coordinator 内的分布式锁执行选主，只有 Leader YurtHub 负责缓存资源写操作。其他 Follower 将时刻监听 Pool-Coordinator 内保存的 Leader Lease 资源，从而确定是否 Leader 存活，只有存活的 Leader 才能保证缓存资源的正确性和时效性。当 Leader YurtHub 因为某些原因，例如和中心网络断开，以及自身原因而退出，将由其他 Follower YurtHub 中重新选主，保证边缘缓存的可用性。 这个过程我们提供了 Grace Period 机制，即当短暂的云边网络故障导致的 Leader YurtHub 不健康状态，不会导致边缘节点池切流至云端，当超过一定时间之后再进行切流，以防网络抖动和大量节点切流导致带宽彻底打满。  当 Pool-Coordinator 因异常原因退出后，边缘 YurtHub 将感知，并将代理请求转发至云端，从而获得正确响应。待 Pool-Coordinator 重建后，会重启选主机制，重建边缘缓存，降低云边带宽消耗。 ### 证书与鉴权 Pool-Coordinator 套件提供完备的证书管理机制，并保证在流量转发过程的权限正确。 在系统初始化阶段，会由 Yurt-Controller-Manager 签发证书，该证书被 YurtHub 和 Pool-Coordinator 获取，保证 YurtHub 有权限，并可以安全读写缓存。 对于 Pool-Scope 资源请求转发缓存的过程中，会进行 Token 替换，保证这次请求带有缓存读写权限。  ## 展望 随着 v1.2 版本的发布，Pool-Coordinator 在后续将继续着重于稳定性建设和生态组件建设，包括可观测能力、网络抖动的鲁棒性优化、断网自制能力、Pool-Coordinator 容器运维能力等。Pool-Coordinator 组件也将会工业生产中的大规模落地实践，并像其他 OpenYurt 生态组件一样在生产过程中迭代和优化，提升系统稳定性。 欢迎有更多的贡献者与用户参与 Pool-Coordinator 的建设！如果您对于 OpenYurt 有任何疑问，欢迎使用钉钉扫描二维码或者搜索群号（12640034121）加入钉钉交流群。  戳[此处](https://github.com/openyurtio/openyurt)，立即了解 OpenYurt 项目