扩散模型综述：方法与应用

《Applied Sciences》：A Survey of Diffusion Models: Methods and Applications HaoYu Ma and Hon-Cheng Wong

　　

Kubernetes是Google发起的一个开源项目，用于管理和组织云平台上的容器，已成为部署大规模容器化微服务架构的首选。Kubernetes使用一个调度器，该调度器考虑工作负载所有者和集群管理员定义的约束，以确定托管给定任务的最合适节点。尽管可以通过多种方式进行配置，但Kubernetes自带的默认调度器并不能完全有效地处理水平Pod自动缩放（Horizontal Pod Autoscaling, HPA）的需求，特别是在同时部署大量相似Pod时。本文专注于优化Kubernetes调度器，以在快速Pod自动缩放场景中更有效地分配和管理资源。Kubernetes的调度机制具有相当大的改进潜力。本文介绍了一种自定义调度器，它使用缓存机制减少冗余评分步骤，从而加速Pod水平扩展的调度过程。本文从深入的文献综述开始，然后开发新算法以解决默认调度器中存在的空白。然后对自定义调度器进行严格的模拟和测试阶段，以确保其稳健性和效率。实验结果表明，所提出的方法在改进Kubernetes中HPA的调度性能方面是有效的。

随着云计算和容器化技术的广泛采用，Kubernetes已成为部署大规模微服务架构的主流平台。Kubernetes默认调度器在处理水平Pod自动缩放（Horizontal Pod Autoscaling, HPA）引发的突发扩展（burst scale-out）时，面临严重性能瓶颈。当短时间内有大量相似Pod（例如同一Deployment的副本）同时被调度时，默认调度器对每个Pod独立执行完整的过滤（Filter）和评分（Score）流程，导致大量冗余计算。评分阶段需对每个可行节点运行多个评分插件，计算开销随集群规模和节点数量线性增长，显著增加了调度延迟（scheduling latency）和端到端扩展时间。此外，默认调度器缺乏结果复用机制，在突发场景下容易引发队列拥塞，进一步降低系统吞吐量。针对上述问题，研究人员提出了一种基于缓存机制的自定义Kubernetes调度器（cache-scheduler），旨在通过复用评分结果加速HPA突发扩展下的调度过程。该研究在Google Kubernetes Engine（GKE）上进行了实验评估，将所提调度器与默认调度器、Koordinator和YuniKorn进行了对比。结果表明，自定义调度器在调度延迟（mean T_sched降低31.8%）和HPA恢复时间（TTR减少66.8%）上均取得显著改善，且保持了接近默认调度器的放置公平性。论文发表在《Applied Sciences》。

研究人员为开展研究主要用到以下几个关键的技术方法：（1）ScoreKey定义：通过提取Pod的调度相关字段（资源请求、约束哈希等）构建等价签名，用于判定不同Pod是否可共享评分结果；（2）旋转Top-1选择缓存机制（rotating score-cache）：将评分结果按节点分数排序存储为列表，每次调度仅返回当前列表首节点并弹出该元素，避免重复选择同一节点；（3）可行性上下文指纹（feasibleHash）：对可行节点集名称进行排序后哈希，确保缓存仅在当前可行性上下文匹配时复用；（4）消费率刷新阈值（consumption-based refresh）：设置默认τ=0.5，当缓存的节点被消耗超过该比例时触发重算，平衡复用收益与新鲜度。实验在GKE集群（东京区域，5个worker节点）上进行，样本队列来源为研究人员自主部署的GKE node pool。

研究结果如下：

5.3.1. Scheduling Performance Benchmark（调度性能基准测试）
通过将单个Deployment的副本数从0扩展至200（N=200），在5节点集群上比较了四种调度器。结果表明，自定义缓存调度器（Cache-scheduler）的平均调度延迟（mean T_sched）为801.7 ms，相比默认调度器的1175.0 ms降低31.8%，尾延迟p99也从2673.3 ms降至2000.0 ms（降低25.2%）。Koordinator的平均调度延迟为816.7 ms，性能接近；而YuniKorn的调度延迟最高（mean 1955.0 ms）。在就绪延迟（T_ready）方面，缓存调度器略有改进（均值4818.3 ms vs. 4958.3 ms），但尾延迟p99基本持平。放置质量上，缓存调度器保持了与默认调度器相近的近均匀分布（Jain公平指数≈0.992，变异系数CV≈0.091），优于Koordinator（Jain 0.9806, CV 0.141）和YuniKorn（Jain 0.8793, CV 0.370）。

5.3.2. HPA Scenario Benchmark（HPA场景基准测试）
在HPA驱动的工作负载（php-apache）下，设置SLA p99=1.0 s，采用两阶段协议（FIND+HOLD）测量恢复时间（Time-to-Recover, TTR）。所有调度器均在并发度C^★=10时首次违反SLA。缓存调度器实现了最快恢复（115 s），相比默认调度器（346 s）加速3.01倍（TTR降低66.8%），YuniKorn（152 s）和Koordinator（191 s）分别加速2.28倍和1.81倍。进一步分析发现，缓存调度器在系统达到最大期望副本数（20个）后仅需约10 s即恢复SLA，而默认调度器仍需额外约247 s。这表明调度器侧的吞吐量和放置行为对HPA扩展后的服务质量恢复有持续影响。

讨论部分主要总结了研究的局限性与未来方向。局限性包括：（1）ScoreKey采用严格相等定义，语义等价但语法不同的规格可能不匹配，降低缓存命中率；（2）可行性集指纹（feasibleHash）仅检测节点集变化，无法捕捉细粒度分数漂移；（3）Top-1确定性选择减少了默认调度器中同等分数节点间的随机性；（4）依赖重复相似Pod，异构工作负载下缓存收益有限；（5）实验范围有限（GKE 5节点集群）。未来工作方向包括：提升相似性建模的鲁棒性（如规范化约束顺序）；引入更精细的新鲜度控制（如资源头寸哈希）；自适应刷新和多样性策略；在更大集群和更多工作负载下扩展评估；以及工程层面的缓存淘汰策略和可观测性增强。

研究结论翻译如下：
本文提出了一种针对HPA突发扩展工作负载的Kubernetes调度器优化方法，通过减少调度等价Pod间的冗余评分计算来提升性能。主要成果包括：（1）设计并实现了基于评分键（ScoreKey）的评分复用层，集成到kube-scheduler中，可标识调度等价Pod并复用标准框架评分输出，兼容Kubernetes调度框架；（2）采用旋转Top-1选择策略，缓存一个按分数排序的节点列表，每次调度仅返回当前最优节点并将其弹出，从而在突发场景中自然实现放置多样性；（3）通过可行性上下文指纹（feasibleHash）和消费率刷新（默认τ=0.5）实现有界的新鲜度保证，确保在动态集群条件下保持正确性；（4）在真实GKE集群上完成了包括HPA突发场景在内的实验评估，与默认调度器、Koordinator和YuniKorn对比，证明了复用评分结果可在保持放置公平性的同时降低平均调度延迟。