Predictive and Adaptive Resource Scheduling for Kubernetes–Ceph Hyperconverged Infrastructure on Proxmox VE

想象一座繁忙的城市，道路、电网和供水系统都生活在同一个社区内。在现代计算领域，这被称为“超融合架构”（Hyperconverged Infrastructure）。它不像传统的做法那样将服务器（计算）、硬盘（存储）和网络电缆分开建设，而是将一切紧凑地封装在相同的物理机器中。这种方式既高效又节省空间，但也制造了一个棘手的交通问题：如果一辆大型货车（数据密集型程序）试图在施工队（存储任务）就在路边作业时驶过街道，一切都会陷入瘫痪。

为了管理这座数字城市，我们使用一种名为 Kubernetes 的系统。你可以把 Kubernetes 想象成这座城市的交通指挥官。它的职责是决定哪栋建筑（服务器）应该接收哪辆新的交付货车（软件程序，或称“Pod”）。然而，标准的交通指挥官有些过时了——他只看“当下”。他看到一栋建筑目前是空的，就会说：“太好了，把货车发过去吧！”但他并不知道，由于附近的施工项目，这栋建筑的电网已经在苦苦支撑，或者这辆货车即将抵达，其载荷会在五分钟后引发一场交通大堵塞。这种“反应式”的风格往往导致一些建筑被过载的工作压垮，而另一些建筑却处于闲置状态，同时“道路”（数据存储）也会变得拥堵，从而拖慢整体速度。

这正是来自乌兹别克斯坦和罗马尼亚大学的研究团队决定解决的难题。他们问道：如果我们的交通指挥官能窥见未来呢？如果他能在交通拥堵发生之前就预见到它们，并据此调度货车呢？在他们的论文中，他们构建了一个更智能的、“预测性且自适应”的系统，该系统不仅对现状做出反应，还能为即将来临的时刻做计划。通过将一个简单的预测工具与一种新的程序放置方式相结合，他们成功地平息了测试城市中的混乱，证明了有时，一点点“远见”比一个超级复杂的“大脑”更为有效。

问题所在：反应式交通指挥官

在数字世界中，研究人员使用三个主要工具搭建了一个“超融合”测试平台：Proxmox VE（承载服务器的基础设施）、Ceph（作为巨大共享硬盘的存储系统）以及 Kubernetes（交通指挥官）。

在标准设置下，Kubernetes 表现得非常保守。它会等待一个服务器正在运行某个程序时，检查其 CPU（脑力）和内存（短期记忆）的使用情况，然后决定下一个程序放在哪里。这就像一个交通警察，只能看到当前路面上的车辆。如果一辆车看起来还没满，警察就会把车派过去。但在超融合系统中，“车”可能需要访问该服务器上的“存储”（硬盘）。如果警察不知道该服务器的存储已经很忙了，新来的车就会被卡住，从而导致延迟。

研究人员发现，这种“反应式”方法会导致三个大麻烦：

1. 资源争用（Resource Contention）： 过多的程序在同一时间争夺相同的 CPU 或存储资源。
2. 负载不均衡（Load Imbalance）： 一些服务器正满头大汗（运行在 95% 的容量），而另一些则在打盹（运行在 40% 的容量）。
3. 存储延迟（Storage Latency）： 由于存储系统不堪重负，读取或写入数据的时间变慢了。

解决方案：水晶球与灵活的地图

该团队提出了一个新模型，它就像一个拥有水晶球和灵活地图的交通指挥官。他们的系统由四个协同工作的部分组成一个循环：

1. 水晶球（预测）： 系统不再仅仅观察当前时刻，而是使用了一种称为“指数加权移动平均”（EWما/EWMA）的数学技巧。你可以把它想象成一名天气预报员，通过观察过去几天的降雨量来猜测明天是否需要带伞。它会预测程序在未来几分钟内需要的 CPU 和存储量。他们发现，这种“预报”的一个特定设置效果最好，预测 CPU 需求的误差约为 8.4%，内存误差为 5.1%，存储需求误差为 12.3%。
2. 灵活的地图（自适应调度）： 一旦系统了解了即将发生的情况，它就不会把程序直接丢给第一台空闲服务器。它会计算每台服务器的“预测负载”。它会问：“如果我把这个程序放在这里，这台服务器会在五分钟后过载吗？”如果答案是肯定的，它就会跳过该服务器并寻找更好的位置。
3. 存储感知决策（Storage-Aware Decision）： 这是核心秘诀。系统不仅查看 CPU，还会检查 Ceph 存储（即 OSD 或存储守护进程）的健康状况。如果一台服务器的存储驱动器很忙，系统就知道要把重型数据程序发送到其他地方，即使那里的 CPU 看起来很空闲。
4. 动态调整（Dynamic Adjustment）： 如果一个程序突然需要比预期更多的动力，系统可以自动调整其限制，而不会导致崩溃或重启，从而保持流程顺畅。

实验：三城测试

为了验证效果，研究人员利用三台物理计算机（节点）构建了一个真实的微型城市。每个节点都配备了强大的处理器、32 GB 内存和两个快速的 NVMe SSD（超高速硬盘）。他们在这座城市中加入了不同类型的交通流：

• CPU 重型货车： 仅进行数值计算的程序（如 stress-ng）。
• 存储重型货车： 进行大量数据读写的程序（如 fio）。
• 混合交通： 兼顾两者功能的数据库和 Web 应用（如 YCSB）。

他们并排运行了两种场景，持续 30 分钟：

• 场景 A（旧方式）： 标准 Kubernetes，没有预测功能。
• 场景 B（新方式）： 他们提出的预测性、自适应模型。

结果：更平滑的街道，更快的交付

结果清晰地显示了新模型的优势，数据生动地讲述了改进的故事。

1. 平衡负载：
在旧方式下，交通极其不均。一台服务器在压力下尖叫，运行容量高达 95.64%，而另一台几乎在闲置，仅为 39.73%。这种“不平衡”（最忙和最闲服务器之间的差距）达到了混乱的 53.29%。
使用新模型后，交通变得非常平滑。最忙的服务器容量降至 67.41%，而最闲的服务器也活跃了起来，达到 56.33%。不平衡度骤降至仅 10.98%。这意味着混乱减少了 79.4%。新系统让所有服务器都维持在 54% 到 68% 之间的一个紧密、愉快的区间内，意味着既没有人过劳，也没有人无所事事。

2. 加速存储：
因为新系统知道哪里存储繁忙，所以它避免了阻塞道路。应用存储变更的平均时间（延迟）从 1.11 毫秒 降至 1.00 毫秒。虽然这听起来差别微小，但在数据世界里，这意味着系统更加一致且可靠。其“最坏情况”下的延迟（第 95 百分位数）也从 1.15 毫秒 改善到了 1.00 毫秒，表明系统能更好地处理重型流量。

3. 无额外成本：
研究人员特别指出，他们并不需要重建整个城市，也不需要使用昂贵复杂的 AI 大脑。他们使用了标准的工具（Kubernetes 和 Prometheus API）以及一种简单的预测方法。他们证明了不需要超级复杂的算法也能获得极佳的效果；你只需要把计算和存储之间的联系连接起来。

总结：集成胜于复杂

这篇论文最令人兴奋的部分不仅在于它奏效了，更在于它为什么奏效。研究人员认为，问题不在于旧的交通指挥官太笨，而在于它只从一个维度看待问题。它看到了 CPU，却忽略了存储。

通过简单地为现有系统增加一层“远见”和“存储感知”，他们实现了巨大的收益。他们证明了架构集成（让计算与存储相互对话）比单纯提高算法复杂度更为强大。即使是一个简单的、轻量级的预测工具，只要结合智能的放置策略，就能解决超融合系统中最大的瓶颈。

最终，这篇论文表明，高效计算的未来不一定在于构建更大、更聪明的“大脑”，而在于确保系统的不同部分能够手牵手、并肩向前看。交通指挥官不需要成为天才，他只需要知道拐角处即将发生什么。