【论文】略读笔记28-前沿-复杂拓扑云调度

📖《Diktyo: Network-Aware Scheduling in Container-Based Clouds》

🎯需求

• 容器彻底改变了当前云平台中的应用部署和生命周期管理。应用程序已从单一的单体发展为松散耦合微服务的复杂图。此外，最近的应用对延迟越来越敏感，要求依赖的微服务之间的延迟更低。然而，由于微服务之间存在复杂的相互依赖关系，如何高效分配基于微服务的应用程序是一项挑战。
  • 微服务架构已逐渐成为现代云平台应用部署的事实范式。传统的大型单体被分解成多个松散耦合的微服务，独立实施和部署。随着容器的日益普及，当前云平台（如 Kubernetes (K8s)、亚马逊 AWS）中基于微服务的应用需要高效的协调策略。
  • 然而，下一代应用要求依赖的微服务之间的延迟更低，从而进一步推动了云基础设施的发展。多层网络服务、物联网（IoT）、视频流服务和数据库等应用领域对延迟非常敏感，需要亚毫秒级的端到端（E2E）延迟才能正常运行。

🚧现状

• 流行的容器编排平台中的调度策略主要是为了提高基础设施的资源效率，但对于延迟敏感型应用来说却不够。
  • 目前流行的协调平台中的调度方法主要集中在优化基础设施（如 CPU 和内存）的资源利用率上，不足以满足这些应用的严格要求，尤其是在延迟和带宽方面。K8s 是目前最流行的容器编排平台。它能自动处理容器化应用生命周期中的多个流程，包括部署和扩展。然而，K8s 中缺少网络感知调度策略，无法在容器云中对长期运行应用程序的依赖微服务进行网络感知部署。
• 物联网和多层网络服务等应用领域将受益于在调度过程中考虑网络延迟和带宽的网络感知策略。以往的研究都是通过理论公式或基于启发式的方法来研究网络感知调度，并通过模拟或小型测试平台进行评估，因此很难将其完全应用于流行平台。
  • 减少延迟是一个首要目标，因为用户在使用多层应用时通常会遇到延迟问题，从而影响整体应用性能。这些应用通常包括数十到数百个微服务，它们之间存在复杂的相互依赖关系。
    • 网络延迟通常是罪魁祸首，因为这些微服务在基础设施中调度时没有考虑延迟问题，导致分配依赖微服务的服务器之间距离过远。
    • 此外，带宽优化也起着关键作用，特别是对于那些在微服务间进行大量数据传输的应用。例如，
      • 数据库应用中的多个副本可能需要频繁复制以确保数据一致性。
      • Spark 作业可能需要在映射器和还原器之间定期传输数据。
        • 节点间链路的网络容量不足会导致延迟增加或数据包丢失，从而进一步降低应用程序的服务质量（QoS）。
  • 网络感知调度策略，除了计算资源（如 CPU 和内存）外，还能根据延迟和带宽指标确定服务位置，这将使这些应用受益匪浅。
    • 集群节点之间链路的网络延迟和可用带宽会因节点在底层基础设施中的位置而异。在没有延迟和带宽意识的情况下，在不同节点上部署依赖性微服务会严重影响应用程序的响应时间和整体 QoS。例如，
      • 在 Redis 集群应用中，主节点需要定期与从节点同步数据。在调度过程中，需要考虑主节点和从节点之间的依赖关系。否则，主节点和从节点之间的高延迟或低带宽会导致创建、读取、更新和删除（CRUD）操作缓慢。
      • 同样，在典型的多层网络应用程序（如在线精品电子商务应用程序）中也存在若干依赖关系。在远离依赖微服务的地方部署微服务实例会影响在线精品店的 E2E 延迟。
  • 以往关于网络感知调度的研究主要集中在理论公式或基于启发式的算法，通常通过模拟或小型测试平台进行评估，从而限制了其在生产系统中的适用性。

🛩创新

• 本文为流行的 Kubernetes（K8s）平台提出了一种名为 Diktyo 的新型网络感知框架，它能确定长期运行应用程序中依赖微服务的位置，重点是减少应用程序的端到端延迟并保证带宽预留。
  • 受 K8s 最近的调度插件架构的启发，本文为 K8s 平台提出了一个新颖的网络感知调度框架，名为 Diktyo。
    • Diktyo 提出了额外的调度插件，旨在为 K8s 集群上调度的应用程序确定低延迟部署方案。
    • 该框架通过为依赖的微服务选择网络成本低的节点，并根据之前的微服务分配选择带宽容量充足的节点，从而最大限度地减少应用程序的 E2E 延迟。
    • 考虑到应用的微服务依赖性和底层基础架构拓扑，Diktyo 提供了接近最优的容器放置方式。
    • 据我们所知，Diktyo超越了当前最先进的技术，因为它是在未来云原生架构中对依赖性微服务进行可扩展网络感知布局的首次尝试。

1. Diktyo 框架：

• 网络感知调度框架的设计与实现，该框架将控制平面（调度逻辑）与数据平面（即应用程序微服务依赖关系和集群网络拓扑）分离开来。
• 两个异步控制器管理两个自定义资源（CR），定义为 K8s 中的自定义资源定义（CRD）：
  • AppGroup CRD 负责建立应用程序的微服务依赖关系；
  • NetworkTopology CRD 负责缓存和更新 K8s 集群拓扑底层区域和区域之间的网络成本。
• 提议的框架已被 K8s 调度社区开源资源库接纳为替代调度器。研究人员可以使用我们的框架，在 K8s 集群中部署具有网络感知能力的应用程序，并根据当前机制评估其性能。

2. 混合整数线性规划（MILP）：

• 为 K8s 中的容器调度问题制定 MILP 模型，包括应用依赖图和底层集群拓扑的规格说明，以及网络延迟和带宽容量方面的不同链接。
• K8s 允许动态配置不同的插件，以实现有关应用程序调度的不同目标。与最优解决方案相比，之前的工作尚未研究插件组合的性能。
• 我们通过评估由 MILP 公式给出的最优方案来回答这一重要问题，该方案是评估 Diktyo 框架和现有 K8s 调度插件性能的理想基准。
• 模拟结果表明，在应用程序的 E2E 延迟方面，Diktyo 明显优于现有的调度插件。

3. 插件实施：

• 我们为 Diktyo 框架设计了三个调度插件。这些插件的组合旨在逼近 MILP 模型给出的最优解，重点是以可扩展的方式最大限度地减少应用程序的 E2E 延迟。
  • TopologicalSort 插件根据拓扑信息对微服务进行排序，NodeNetworkCostFit 插件根据微服务的依赖关系筛选出节点，NetworkMinCost 插件根据网络权重对节点进行评分，以确保依赖的微服务之间的低延迟。所有插件的性能都与节点和微服务的数量成对数关系。

4. 微服务应用评估：

• 评估考虑了通常用作微服务基准的实际应用：一个名为 “在线精品店”（Online Boutique）的多层网络应用和一个名为 “Redis集群”（Redis cluster）的数据库应用。
• 分布式 K8s 集群的实验表明，Diktyo 使 Redis 的吞吐量提高了 22%，使在线精品店的应用响应时间平均缩短了 45%。

📊效果

• 模拟结果表明，与默认的 K8s 调度插件相比，Diktyo 可以显著降低各种应用在不同基础设施拓扑中的网络延迟。此外，在 K8s 集群中使用微服务基准应用程序进行的实验表明，Diktyo 可以将数据库吞吐量提高 22%，将应用程序响应时间缩短 45%。

🧠疑问

1. 所提出算法为什么随节点增长成对数关系？具体测试过程如何？

---

---

• 希望这篇博客对你有帮助！如果你有任何问题或需要进一步的帮助，请随时提问。
• 如果你喜欢这篇文章，欢迎动动小手 给我一个follow或star。

🗺参考文献

[1] J. Santos, C. Wang, T. Wauters and F. De Turck, “Diktyo: Network-Aware Scheduling in Container-Based Clouds,” in IEEE Transactions on Network and Service Management, vol. 20, no. 4, pp. 4461-4477, Dec. 2023, doi: 10.1109/TNSM.2023.3271415.