最新要闻

广告

手机

iphone11大小尺寸是多少?苹果iPhone11和iPhone13的区别是什么?

iphone11大小尺寸是多少?苹果iPhone11和iPhone13的区别是什么?

警方通报辅警执法直播中被撞飞:犯罪嫌疑人已投案

警方通报辅警执法直播中被撞飞:犯罪嫌疑人已投案

家电

速看: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)加入钉钉交流群。

戳此处,立即了解 OpenYurt 项目

关键词: 治理方案 工作方式