《Computers》：Enhancing the Kubernetes Scheduler: A State-of-the-Art Review from Cloud to Edge
编辑推荐：
云-边连续体的快速扩展要求容器化应用能够在高度异构和资源受限的环境中动态扩展。作为容器编排的事实标准，Kubernetes（简称K8s）高度依赖其调度子系统来管理这些复杂的分布式环境。然而，默认的调度方法本质上是为同构云数据中心设计的，在边缘拓扑中使用时会带来
云-边连续体的快速扩展要求容器化应用能够在高度异构和资源受限的环境中动态扩展。作为容器编排的事实标准，Kubernetes（简称K8s）高度依赖其调度子系统来管理这些复杂的分布式环境。然而，默认的调度方法本质上是为同构云数据中心设计的，在边缘拓扑中使用时会带来重大的部署挑战。尽管已经提出了许多自定义调度器、插件和扩展来弥补这一差距，但仍需对现有方法进行综述以评估现有方法并捕捉最新趋势。在本综述中，研究人员对2023年1月至2026年1月期间发表的Kubernetes调度策略进行了全面综述。研究人员建立了一个多维度分类法（taxonomy），根据共同目标、修改方法、优化方法论、目标工作负载、评估方法、调度范围和性能指标对调度方法进行分类。研究人员研究了不同计算范式下出现的开放挑战，并强调了Kubernetes调度领域的最新趋势和未来研究的可能方向。
论文主体部分总结如下：
**1. 引言**
云计算是一种服务模型，使客户能够按需使用可扩展资源来部署和管理应用。随着雾计算和边缘计算的引入，计算格局正在发生变化，这些技术将计算资源更靠近数据源。Kubernetes（K8s）作为开源容器编排平台，已成为事实标准，在分布式环境中的资源管理和工作负载分配中发挥关键作用。开发Kubernetes调度算法需要理解kube-scheduler的工作原理，包括默认调度器和高级调度器的约束、可能的修改方法以及需解决的问题。
**1.1. 相关工作与贡献**
已有许多综述关注容器编排，但未深入探讨Kubernetes调度。部分综述虽聚焦Kubernetes，但未专门研究调度。三项相关综述（文献[17-19]）覆盖了2023年之前的文献，已过时。近期工作（文献[20]）虽综述调度提案，但语料库有限且缺乏结构化多维度框架。本研究通过分析2023年1月至2026年1月的最新贡献，扩展了先前综述，采用系统方法和主题分类，从多个维度（共同目标、调度技术、修改方法、目标环境、工作负载类型、调度范围、评估方法和性能指标）呈现发现，并识别趋势和未来方向。
**1.2. 研究问题与方法论**
为回答定性（Q1–Q7, Q11–Q12）和定量（Q8–Q10）研究问题，采用系统方法，步骤包括：1）识别与策略：在ACM Digital Library、Elsevier ScienceDirect等平台搜索，关键词为“kubernetes scheduler”或“k8s scheduler”或“Kube-scheduler”，限2023年1月至2026年1月；2）筛选与选择：筛选标题和摘要，纳入直接扩展、修改或替换默认K8s调度机制的定制调度器，排除仅使用K8s作为执行后端或依赖标准API的工作；3）合成与讨论：按主题分类组织结果。图2显示出版物数量稳步增长。
**2. 背景、术语与可用技术**
**2.1. 虚拟化与容器编排框架**
虚拟化通过将物理机分割为虚拟机（VM）或容器来运行应用服务。容器基虚拟化将应用及其依赖封装到共享宿主操作系统的隔离环境中。容器编排平台（如Kubernetes、Docker Swarm、Apache Mesos）自动化容器部署。Kubernetes是实践中的事实标准，提供更灵活的调度器配置。
**2.2. Kubernetes架构**
K8s集群由主节点和工作节点组成。主节点包括Kube-APIServer（前端）、Etcd（分布式键值存储）、Kube-Scheduler（负责将未调度的Pod分配到合适的工作节点，本综述重点关注此组件）和Kube-Controller-Manager（维护集群期望状态）。工作节点包括Kubelet（代理）、Kube-Proxy（网络规则）、Container Runtime（容器运行时）和Pods（最小部署单元）。
**2.3. Kube-Scheduler与可能的修改方法**
**2.3.1. Kube-Scheduler概述**
默认调度器kube-scheduler根据硬约束（过滤阶段）和软约束（评分阶段）将Pod分配到最合适的工作节点。硬约束包括资源需求、节点亲和性、Pod反亲和性、污点和容忍度。软约束包括工作负载均衡等偏好，大多数优化提案针对评分阶段。
**2.3.2. 可能的修改方法**
Kubernetes提供四种定制调度行为的方法：（1）配置默认调度器（MA1）：修改默认调度器参数，但灵活性降低且维护开销增加；（2）实现自定义调度器（MA2）：从头设计或修改现有调度器与默认调度器并行运行，增加系统复杂度；（3）调度器扩展器（MA3）：通过HTTP/HTTPS回调扩展默认调度器，但仅限过滤和评分阶段，缺乏共享缓存，效率较低；（4）调度框架（MA4）：基于插件的扩展机制，在调度管道的各个扩展点（PreFilter、Filter、PostFilter、PreScore、Score、Reserve、Permit、Bind）注入自定义逻辑，克服了扩展器的局限性。
**2.3.3. 调度范围**
调度范围分为四个层次：Pod级（单个Pod到节点）、应用级（一组相关Pod）、集群级（所有Pod和节点）、系统级（跨多个集群、自动缩放、节点配置和云级优化）。
**3. 分类法与论文分类**
建立了多维度分类法，以优化目标作为主要分类轴，包括性能导向、资源导向、可扩展性导向、可持续性导向、成本导向和安全导向。每个目标进一步细分为问题类别。图8显示135篇论文的分布，其中性能导向（52篇）和资源导向（44篇）占主导，可持续性导向（21篇）呈增长趋势，成本导向（10篇）、可扩展性导向（7篇）和安全导向（1篇）相对未充分探索。
**4. 最新文献分析与分类**
自定义Kubernetes调度器旨在解决默认调度器的局限性，映射为六个优化目标。
**4.1. 性能导向优化**
**4.1.1. 干扰问题**：多个工作负载共享物理资源时性能下降。关键解决方案包括：按资源使用强度分组工作负载（如对DL任务分组）；使用机器学习（LSTM、Mondrian Forests）预测性能；使用低层硬件性能计数器（如指令每周期、缓存未命中）识别竞争；Linux内核SCHED_DEADLINE策略保证时序隔离；凸优化缩减SLA违规；强化学习（RL）优化加速器空间复用。开放问题：离线分析过时需在线自适应；多维度干扰建模效率低；跨异构硬件需轻量级可迁移方法。
**4.1.2. 缺乏数据局部性意识**：Pod与数据源物理距离导致性能下降。解决方案包括：集成领域特定加速器到计算存储驱动器；考虑对象位置元数据实现零拷贝数据共享；移动边缘计算中使用自注意力机制（如Vision Transformer）考虑镜像局部性和地理分布。开放问题：动态数据放置、冷启动延迟。
**4.1.3. 缺乏Pod间依赖意识**：默认调度器忽略微服务间通信依赖。解决方案包括：使用图算法（如Girvan-Newman）将高流量Pod分组到一个节点；模糊聚类允许高利用率微服务多实例运行；图注意力网络（GAT）结合深度Q学习捕获依赖；多层级感知识别耦合；强化学习（RL）代理优化地理分布环境中的位置；邻域和位置感知机制。开放问题：有状态应用需实时迁移；在线自适应更新。
**4.1.4. 缺乏批调度**：默认调度器逐Pod处理，忽略批量需求。解决方案包括：计算连续体中的贪心算法和回溯/遗传算法；ML管道的遗传算法考虑资源利用和镜像局部性；5G网络切片中遗传算法决定是否部署整个切片。开放问题：动态工作负载下保持批量最优性。
**4.1.5. 缺乏拓扑意识**：默认调度器忽略网络跳数。解决方案包括：动态拓扑发现（Dijkstra算法）；去中心化网络坐标系统估计往返时间；eBPF服务网格收集实时指标；卫星集群中深度Q网络学习放置策略；TOPSIS多准则决策；层次化强化学习平衡延迟、成本和能效；哨兵副本测量端到端延迟。开放问题：MILP计算开销大；反应式框架需AI驱动预测；有状态迁移支持不足。
**4.1.6. 缺乏层感知调度**：容器镜像层可共享减少下载成本。解决方案包括：基于缓存层重叠评分节点；集成层局部性插件与网络感知评分；动态调整层共享权重（如LR2Scheduler）；Quicklayer用层感知版本替换默认镜像局部性插件。开放问题：静态权重需动态优化；跨集群层共享；缓存流行度预测；安全隔离。
**4.2. 资源导向优化**
**4.2.1. 缺乏实际负载意识**：默认调度器基于声明资源请求而非实际使用。解决方案包括：实时Prometheus集成动态调整权重；历史数据调整初始请求；DRL学习最优放置策略；仿真调度器加速训练；去调度器（descheduler）通过驱逐和重调度迁移Pod；按应用类型分组排序；处理突发应用（KS-surge）；平衡CPU-GPU分配。开放问题：ML模型在边缘资源受限；集中式模型难以分布式决策。
**4.2.2. 加速器利用效率低**：默认调度器将GPU视为整体，导致资源浪费。解决方案包括：动态划分GPU计算和存储百分比；GPU范围抽象支持GenAI工作负载；解耦模型训练与硬件分配；NPU虚拟抽象；FPGA单内核虚拟化；DL学习结合重调度减少碎片；TOPSIS优化多维资源碎片；监控实际GPU内存使用。开放问题：TPU、SmartNIC虚拟化缺失；多资源维度相互约束；碎片化需要运行时迁移。
**4.2.3. 不支持异构资源**：默认调度器难处理CPU、GPU、NPU、FPGA等异构资源。解决方案包括：GPU-CPU资源分配插件；考虑通信延迟；指数移动平均捕获节点性能趋势；亲和性批量映射调度器；K-means聚类分组节点。开放问题：需扩展至TPU和FPGA。
**4.2.4. 缺乏多维资源意识**：默认调度器忽略网络带宽和磁盘I/O。解决方案包括：eBPF/XDP捕获实时网络指标；双深度Q网络学习放置策略；神经网络预测响应时间；改进粒子群优化（PSO）处理多维需求；RDMA感知调度监控带宽和延迟；工作负载分类区分通信密集型任务；网络SLO感知架构动态调整CPU分配。开放问题：调度开销随租户和节点增加而扩大。
**4.3. 可扩展性导向优化**
**4.3.1. 缺乏超大规模可扩展性**：集群超过5000节点时调度延迟高。解决方案包括：分布式共享状态架构（多实例调度器）；增量快照更新减少同步成本；数据库技术（增量视图维护）缩减问题规模；层次化资源流模型结合时间序列预测。开放问题：最优并发度未确定。
**4.3.2. 缺乏多集群支持**：默认调度器只支持单集群。解决方案包括：AI学习最优放置策略；归一化性能模型跨集群公平匹配；延迟监测实现QoE感知调度。开放问题：同步产生网络流量；集中式服务器瓶颈。
**4.4. 可持续性导向优化**
**4.4.1. 缺乏能效意识**：默认调度器忽略能耗指标。解决方案包括：阈值调度器开关节点；预训练模型估计功耗增加；多目标优化平衡能效与性能；ML功率预测器；图神经网络（GNN）建模异构组件；计算卸载最大化可再生能源可用性；增量功耗模型结合延迟和流量；太阳能预测结合超量订阅。开放问题：缺乏统一框架整合云边异构；实时电价未考虑；功率模型仅关注CPU。
**4.4.2. 缺乏碳排放意识**：默认调度器忽略碳排放。解决方案包括：GreenCourier基于实时碳效率数据调度；CASPER基于预测碳强度和延迟约束调度；时间窗口调度非关键任务；多目标整数规划结合时空因素。开放问题：时空整合不足；短任务未处理；碳强度预测简单；异构工作负载未同时考虑。
**4.5. 成本导向优化**
**4.5.1. 缺乏成本意识**：默认调度器忽略节点成本。解决方案包括：资源适应度算法结合模拟退火；DRL权衡可靠性与成本混合竞价实例；运行成本模型和优先级感知机制；MILP基于设施位置优化；多目标ILP减少服务中断；处理节点价格和网络成本。开放问题：成本与延迟、可靠性平衡；静态定价假设；在线重调度需满足SLO。
**4.6. 安全导向优化**
**4.6.1. 缺乏坏邻居意识**：默认调度器忽略共存工作负载的安全风险。解决方案包括：seccomp系统调用过滤；自动生成应用特定seccomp配置；应用级内核或硬件隔离；系统调用感知调度（Extraneous System Call Exposure, ExS）共置相似系统调用配置的容器。开放问题：运行时自适应分析；安全与性能协同优化；异常检测；机密计算感知调度缺失。
**5. 定量分析与评估实践**
提取了135篇论文的性能指标，归为8个高层类别（表22）。延迟和响应时间几乎普遍报告，而可靠性和质量指标显著不足报。表25-26和图9显示各优化目标的主导技术、目标环境和修改方法。启发式方法平衡可部署性和计算效率；数学方法适合小规模；机器学习适应动态负载；元启发式适合组合问题；混合方法有前景。K3s是最常用的K8s发行版，其次MicroK8s和RKE2，反映边缘偏好。
**6. 生产生态系统与工业验证**
生产级开源框架如Volcano（批调度、公平共享队列）、Koordinator（QoS感知共置）、YuniKorn（层次化队列资源管理）解决了与本综述学术提案类似的挑战。Kubeflow、Ray、KServe、MLflow等AI平台定义了调度需求。多集群调度框架如Karmada、Liqo、Admiralty、Clusternet处理跨集群工作负载放置。
**7. 开放挑战与未来方向**
表28总结了九个开放挑战，包括：干扰建模与多资源竞争；有状态工作负载与依赖意识；动态数据局部性；异构加速器支持；拓扑与网络感知编排；可扩展性与多集群环境；能效与碳感知调度；动态定价下的成本感知调度；安全与性能协同优化。AI驱动调度趋势显著，约38篇论文使用机器学习，其中DRL最广泛，GNN也在兴起。但LLM和可解释AI在调度中的应用仍缺失，多数ML方法验证于小规模集群。
**8. 结论**
本综述对2023年1月至2026年1月间的135篇Kubernetes调度贡献进行了结构化分析，采用多维度分类法，以六个优化目标为主维度。重要趋势包括：调度框架（Scheduling Framework）成为首选扩展机制；ML和DRL方法采纳增加；延迟和响应时间普遍报告，可靠性和质量指标不足。九个开放挑战和未来方向包括可解释AI调度和LLM驱动自主调度，安全导向调度仍是最未充分探索的目标。
