【论文】略读笔记64-前沿-边缘联邦集群框架
📖《Oakestra: A Lightweight Hierarchical Orchestration Framework for Edge Computing》
2023 年发表于 CCF-A 类会议 ATC。
🎯需求
边缘计算旨在通过利用部署在离用户更近的多样化、动态和可能受限环境中的资源,实现对延迟有严格要求的应用。
- 边缘计算诞生近十年来,已在行业和研究领域找到了广泛的用例,尤其是在支持 AR/VR、实时视频分析等延迟关键型服务方面。
🚧现状
尽管人们对边缘技术兴趣浓厚,但迄今为止,现实世界中的边缘技术演示却屈指可数。原因是多方面的,在技术方面可能包括以下几点。
- 1)首先,边缘资源的能力和异构性远低于数据中心–通常具有较小的外形尺寸和专用硬件,例如英特尔 NUC、Coral AI 板、Jetson Xavier、Raspberry Pis 等。许多此类设备都设计为部署在用户附近,利用带宽有限、延迟较高的不可靠(无线)网络作为主要通信媒介。此外,边缘的优势只有在需要大量投资和规划的计算资源密集可用时才能显现出来。
- 2)其次,大多数流行的协调框架,如 Kubernetes、K3s、KubeFed等,都是解决方案的分支,其设计初衷就是为了在受管理的数据中心网络中良好运行。
- 这些框架对底层基础设施(尤其是网络)的一致性可靠性和可达性做出了强有力的假设,而在资源更为分散的边缘,这种假设并不一定成立。
- 例如,最近对 Kubernetes 运行的调查发现,它依赖于通过 etcd 在数据存储中保持强大的一致性,加上其有限的可扩展性,导致在边缘环境中出现严重的可用性和效率问题。
- 此外,此类框架的核心组件包含许多重量级操作,限制了它们在受限硬件上的使用。
- 此外,几乎所有现有解决方案目前都无法支持边缘在硬件、网络和资源可用性方面的异构性。
- 这些框架对底层基础设施(尤其是网络)的一致性可靠性和可达性做出了强有力的假设,而在资源更为分散的边缘,这种假设并不一定成立。
更具体地说:
- 现有的先进编排框架(如 Kubernetes)在边缘计算中表现不佳,因为它们是为可靠、低延迟、高带宽的云环境而设计的。
- 地位:Kubernetes 已成为生产中最流行的编排系统,在最近的一项调查中,59% 的受访者都使用了该系统,许多人将其视为边缘计算的主要解决方案。
- 机制:它将应用程序(节点)的执行运行时与全局集群决策(控制平面)分离开来。其最小的可部署计算单元是 Pod,这是一组容器化服务。节点嵌入 Pod 的执行运行时,以及平台的网络和监控组件。控制平面为开发人员和外部工具提供 API,监控和同步节点,并对集群事件(如部署、扩展和故障)做出反应。
- 问题:
- 1)Kubernetes 专为数据中心环境设计,它假定节点是由可靠的低延迟网络互连的高端托管资源。该平台通过名为 etcd 的分布式键值存储,在复制控制平面设置中保证集群状态和资源的强一致性。
- 最近的研究发现,在移植到异构和多样化的边缘基础设施时,etcd 的强一致性要求是其主要限制因素。在资源有限的情况下,这对可扩展性有明显的影响,会拖慢整个基础设施的运行速度。
- 2)如现有文献所示,即使在 Kubernetes Federation 中,网络分区和多集群仍然至关重要。特别是,分布式地理区域缺乏合作和对剩余基础设施的感知。因此,集群间通信需要额外的工具,如 Submariner,它需要全局状态传输同步,阻碍了可扩展性。
- 3)Kubernetes的轻量级发行版,如KubeEdge、K3s和Microk8s,要么继承了kubernetes的强假设,要么是为了在小规模集群上有更好的表现,正如我们后来的评估所示。一般来说,虽然扩展 Kubernetes 或重新架构其组件是一个可行的选择,但我们认为,重新设计众多核心组件的工作量会很大,而且还要重新制定其一些基本假设。
- 因此,Oakestra 采用了一种不同的方法,从头开始构建时就考虑到了边缘需求,它为当前的 Kubernetes 开发人员提供了一个熟悉的环境,同时还提供了灵活性,以利用接近客户和地理分布式多所有者基础设施部署的优势。Oakestra 的目标不是取代 Kubernetes 的功能集,而是填补在 Kubernetes 不适用的情况下发现的空白。我们正在探索如何整合基于 Kubernetes 的云集群。
- 1)Kubernetes 专为数据中心环境设计,它假定节点是由可靠的低延迟网络互连的高端托管资源。该平台通过名为 etcd 的分布式键值存储,在复制控制平面设置中保证集群状态和资源的强一致性。
- 在文献中,我们还可以找到其他一些探索有效边缘协调的系统。
- 第一类:从任务调度的角度来看,我们可能会涉及到不同的分层调度器方法,这些方法在云-边缘连续体上分配任务。不过,这些解决方案的重点是服务调度,而在我们的工作中,我们必须将调度问题整合到提供服务和资源管理的综合协调框架中。
- CloudPath设想通过多层路径计算,将无状态功能部署到更靠近客户端的地方;
- HeteroEdge或SpanEdge专门针对流媒体应用;
- FogLamp侧重于数据管理;
- 而VirtualEdge只考虑蜂窝网络中的边缘服务器。
- 第二类:与我们的工作最接近的是 OneEdge,因为它提供了一个混合的双层控制平面,用于管理地理分布式边缘基础设施。不过,我们认为 Oakestra 是 OneEdge 的超集,因为前者是一个通用的模块化框架,允许开发人员将地理(和其他)管理约束表达为调度器插件。我们通过与 OneEdge 类似的 LDP 调度器插件(第 3.2 节)展示了 Oakestra 的这种可扩展性,该插件可对地理和延迟约束进行优化。因此,整合仍是一种可能性,我们将在未来的工作中加以考虑。
- 第一类:从任务调度的角度来看,我们可能会涉及到不同的分层调度器方法,这些方法在云-边缘连续体上分配任务。不过,这些解决方案的重点是服务调度,而在我们的工作中,我们必须将调度问题整合到提供服务和资源管理的综合协调框架中。
🛩创新
在这项工作中,我们提出了一个灵活的分层协调框架–Oakestra,它克服了上述诸多挑战。
- a. 从概念上讲,Oakestra 允许广大地理区域内的多个运营商向联合基础设施贡献资源,从而减少了在边缘实现密集计算结构的投资。
- b. 此外,Oakestra 的实现是轻量级和可扩展的,使其能够有效管理受限和异构的边缘基础设施。
我们提出的 Oakestra 是一个用于边缘计算的分层、轻量级、灵活且可扩展的协调框架。通过新颖的联合三层资源管理、委托任务调度和语义叠加网络,Oakestra 可以灵活地整合多个基础设施提供商,并支持边缘动态变化的应用。
具体来说,我们的贡献包括:
- 1)我们将边缘基础设施整合到一个逻辑三层层次结构中。
- 由一个根协调器管理多个资源集群,每个集群由一个集群协调器控制,从而实现基础设施联合。集群协调器行使本地细粒度控制,但只向根节点发送集群使用情况的汇总统计数据(第3节)。
- 在设计上,Oakestra 隐藏了每个集群的内部基础架构细节,允许许多提供商参与而不暴露内部配置。应用提供商可通过在根节点指定高级限制(硬件、延迟、地理位置)在边缘部署服务。Oakestra 采用委托调度机制,只在根节点做出粗粒度的集群选择,将细粒度的资源调度留给集群,从而将任务分配分离开来。
- 2)我们设计了一种新颖的语义覆盖网络,它能透明地实现面向边缘的负载平衡策略(例如,连接到最近的实例),可直接使用具有语义能力的IPv4地址和主机名进行寻址(第3、4节)。这支持了云原生应用的可移植性,确保了应用开发人员优化边缘服务间交互的灵活性。该覆盖还允许 Oakestra 根据基础设施的变化(如迁移、故障等)动态调整通信端点,确保不间断的服务交互。
- 3)Oakestra的轻量级模块化实现与大多数流行的云技术兼容,允许开发人员扩展内部组件,例如调度程序,而无需太多开发开销(第5节)。Oakestra 是一个开源项目 (https://www.oakestra.io/),其所有组件均可从 https://github.com/oakestra 获取。
- 1)我们将边缘基础设施整合到一个逻辑三层层次结构中。
📊效果
- 我们对照最先进的技术进行了全面评估,结果表明 Oakestra 具有显著优势,它通过减少管理开销将资源使用量降低了约十倍,并通过在受限硬件上轻量级运行将应用性能提高了 10%。
- 我们在高性能计算和边缘基础设施中进行的广泛评估证明了Oakestra的能力,因为它的性能始终(且显著)优于流行的生产框架(如Kubernetes及其衍生产品)。我们的结果显示,CPU 开销降低了 10 倍,服务部署时间缩短了 60%,应用性能提高了 10%。在重负载情况下,与最接近的竞争对手K3s相比,Oakestra的资源利用率降低了≈20%。
⛳️未来机会
- 1)我们计划为 Oakestra 添加几项功能扩展。例如,我们计划通过分布式领导者选举,在故障切换时动态分配集群协调者角色。
- 2)我们还打算利用最新的边缘研究解决方案扩展 Oakestra 的调度和网络功能,如截止日期感知调度、多级隧道等。
- 3)为了提供更好的 QoS 保证,我们还打算支持和比较更新颖的应用运行时,如 unikernels、demikernels 或 Akka。
- 4)最后,我们还试图探索将 Kubernetes 部署纳入 Oakestra 集群的可能性,以实现现有云部署的集成。
🧠疑问
- 边缘的特点是什么?
- 无法保证强一致性
- 为什么不基于k3s开发?理论上k3s也做了很多轻量化优化
- K8S及其衍生品都基于etcd的强一致性假设,若修改则需要进行大量重构,因此选择
- 边缘的不稳定性是如何解决的?
- 解决异构性的难点是什么?只要设计一个抽象框架就行?
- 原语义覆盖网络的缺点是什么?作为创新点有点突兀?
- 组件轻量化的方法是什么?
- 一大亮点是多运营商联合(Sky Computing),难点在于?
- 为啥能发A?
- 希望这篇博客对你有帮助!如果你有任何问题或需要进一步的帮助,请随时提问。
- 如果你喜欢这篇文章,欢迎动动小手 给我一个follow或star。
🗺参考文献
- 标题: 【论文】略读笔记64-前沿-边缘联邦集群框架
- 作者: Fre5h1nd
- 创建于 : 2024-09-26 11:05:25
- 更新于 : 2024-09-26 11:55:40
- 链接: https://freshwlnd.github.io/2024/09/26/literature/literatureNotes64/
- 版权声明: 本文章采用 CC BY-NC-SA 4.0 进行许可。
评论