Kubernetes 网络感知调度的研究进展 #
随着云原生应用复杂度提升，多微服务应用或 NFV 服务链对网络性能敏感。传统 Kubernetes 调度器只关注 CPU/内存，很少考虑网络延迟和带宽。近年来，社区与研究界提出了多种网络感知调度方案：如正在发展的 Scheduler Plugins 项目下的 “Network-Aware Scheduling” KEP，目标在 Pod 调度时纳入网络拓扑和带宽因素 scheduler-plugins.sigs.k8s.io
例如，Santos 等提出的 Diktyo 框架通过自定义 AppGroup 和 NetworkTopology CRD，结合 TopologicalSort（拓扑排序）和 NetworkOverhead 插件来减少微服务间的网络开销 scheduler-plugins.sigs.k8s.io scheduler-plugins.sigs.k8s.io 。此外，Kubernetes 1.23 开始支持拓扑感知路由（Topology Aware Routing），在服务发现时优先选择同可用区的 Endpoints，以降低跨区通信延迟 kubernetes.io 。K8s 原生的 Pod 亲和/反亲和也可指定节点、可用区等拓扑键，实现应用对网络拓扑的基本约束 kubernetes.io kubernetes.io 。 Koordinator (阿里云开源) 则在 QoS 调度层面引入网络控制：1.5 版合作支持 Terway CNI 的网络 QoS，允许为 Pod 或 QoS 类别设置带宽上限，并支持动态调整，使得在多业务共存时可限制 Pod 带宽防止相互干扰 koordinator.sh 。Volcano（批处理调度器）最新版本已内置“网络拓扑感知调度”功能，在分布式训练等场景下考虑节点间通信拓扑来降低跨节点开销 volcano.sh 。此外，Kubernetes 生态中还有针对 NUMA 拓扑（CPU/内存亲和）的插件（如 LeastNUMANodes Scoring），但它们主要关注节点内资源亲和，与网络感知调度侧重点不同。 网络信息感知与获取 要实现网络感知调度，首先需收集底层网络拓扑和性能指标。常见方法包括：一方面通过主动探测和监控采集网络延迟与带宽，例如 Diktyo 中的 netperf 组件会定期测试可用节点间的时延，并将结果写入 ConfigMap scheduler-plugins.sigs.k8s.io 。NetworkTopology 控制器读取这些测量值，计算不同区域/可用区之间的网络代价和可用带宽，并更新自定义的 NetworkTopology CRD scheduler-plugins.sigs.k8s.io scheduler-plugins.sigs.k8s.io 。为了降低全节点对测量开销，该方案假设同一区内延迟相近，仅对跨可用区链路进行网速测试 scheduler-plugins.sigs.k8s.io 。另一方面，CNI 插件也可提供网络性能数据。例如 Kubernetes 社区提供的带宽 CNI 插件（如 Calico 内置的 bandwidth plugin）支持对 Pod 网络流量进行入口/出口限速，通过在 Pod 注解中设置 kubernetes.io/ingress-bandwidth 和 egress-bandwidth 来强制带宽上限 scheduler-plugins.sigs.k8s.io scheduler-plugins.sigs.k8s.io 。同时，调度器可将节点物理网络带宽声明为扩展资源（例如 network.aware.com/bandwidth），并据此进行调度算分 scheduler-plugins.sigs.k8s.io 。此外，在 SDN 或云数据中心环境下，也可通过网络控制器（如 OpenFlow/OVS 查询）或链路探测协议获取拓扑信息；高级 CNI（如 Cilium/Hubble）提供流量和延迟监控，可为调度决策提供实时网络指标（如延迟、丢包率、吞吐量等）。 网络相关调度策略与算法 在调度策略层面，研究和实践结合了多种网络因素： 延迟感知调度：优先考虑微服务间通信延迟。在多层应用或 NFV 服务链中，将强依赖的服务副本调度到网络距离较近的节点上。例如 Diktyo 中的 TopologicalSort 插件依据服务拓扑（AppGroup 中定义的依赖顺序）排序 Pod，配合 NetworkOverhead 插件在筛选/打分时偏向于网络开销小的节点 scheduler-plugins.sigs.k8s.io scheduler-plugins.sigs.k8s.io 。这种做法旨在减少链路延迟，参考了服务功能链 (Service Function Chaining) 的思想 scheduler-plugins.sigs.k8s.io 。 带宽感知调度：将网络带宽作为受限资源纳入调度。调度器在节点过滤和评分时，优先满足带宽需求高的 Pod。具体而言，可将节点的可用网络带宽作为扩展资源（extended resource）在调度请求中声明，例如 Diktyo 框架将带宽容量以 network.aware.com/bandwidth 的形式暴露 scheduler-plugins.sigs.k8s.io 。这样，像 PodFitsHostResources 或 BalancedAllocation 这样的算分策略都能使用带宽维度进行评估。配合 CNI 带宽限速插件，还可实现对 Pod 带宽配额的管理，避免网络拥塞 scheduler-plugins.sigs.k8s.io scheduler-plugins.sigs.k8s.io 。 网络亲和/反亲和：利用 Kubernetes 原生亲和性规则根据网络拓扑分组 Pod。用户可指定 podAffinity 或 podAntiAffinity，设定“如果某 Pod 在 X 拥有标签 Y，则本 Pod 应（或不应）也部署在同一拓扑域 X 内”，其中 X 可是同一节点、同一可用区、同一机架等 kubernetes.io 。最新的拓扑感知路由功能则在服务层面优先选择同可用区内的 Endpoint，尽量让流量“留在原区域”以降低跨区通信开销 kubernetes.io 。 服务链调度：对于网络功能虚拟化 (NFV) 中的服务链或多微服务事务，需要考虑端到端路径。调度时可将组成链的微服务视为一组，根据它们之间的调用关系进行联合调度。例如，在 Diktyo 框架中，通过 AppGroup CRD 定义微服务拓扑，TopologicalSort 插件会按照该服务链顺序下发 Pod scheduler-plugins.sigs.k8s.io ；确保链上节点间网络开销最小，从而满足业务的时延要求 scheduler-plugins.sigs.k8s.io scheduler-plugins.sigs.k8s.io 。类似地，Network Service Mesh 等方案也着重在多节点网络上创建可编排的服务链路。 NFV与边缘场景的网络感知调度 在边缘计算和 NFV 场景下，网络感知调度需求更为突出：边缘节点网络条件多变（带宽低、延迟高），NFV 服务链对 QoS 要求严格。近期研究针对这些场景提出了专门方案。例如，邱颖等人针对边缘节点网络差异大、服务链通信密集的特点，提出了基于 TOPSIS 的 NACS 算法。该算法动态获取集群节点的实时网络与资源信息，按低时延、低丢包目标进行综合评估，将链路延迟和带宽纳入调度考量 link.springer.com 。实验证明，与默认调度相比，NACS 可显著改善网络性能，在实际工作负载下 Web 服务和 Redis 吞吐量分别提升约26%和29.6% link.springer.com 。另一个例子是 Tsokov 等提出的 Kinitos 框架，专注于移动集群环境（如车辆、无人机组网）。它在 Kubernetes 调度器基础上增加了动态 反调度（迁移）机制，可在节点位置变化或网络变差时，将依赖微服务迁移到更优网络位置，保障链路性能 colab.ws 。此外，在 5G MEC（多接入边缘计算）和跨区域云边协同部署中，调度器需考虑更大范围的拓扑（如跨地区节点通信），并结合网络监测数据选择就近计算资源，以满足低时延和可靠性需求。 面临的挑战与优化方法 将网络纳入调度决策带来了诸多挑战：网络状态的时效性和可观测性较差，网络性能（延迟、带宽）会随流量、链路拥塞或节点移动快速变化，使得实时监测与反馈难度大。主动探测大规模集群中的全对节点网络参数开销极高，因此必须简化测量策略（如只对关键路径或跨区链路采样） scheduler-plugins.sigs.k8s.io 。调度算法变得多目标更复杂，需要在 CPU/内存资源和网络指标之间权衡；如果只优化网络，可能导致计算资源利用率下降。因此，多目标优化或加权评分常被采用，在满足网络需求的同时兼顾资源利用。 另外，现有 Kubernetes 特性有时与网络感知调度相冲突。例如默认的 Service 负载均衡会打破稳定的网络路径：Pod 间流量被随机分发，多跳网络环境下难以计算确定的带宽需求。Moeyersons 等人指出，为保证端到端带宽需要，必须禁用自动负载均衡，将流量静态路由到固定节点对 imec-publications.be 。同时，他们总结了在无线网格网络上使用 K8s 的问题：如多跳网络中获取吞吐量指标非常困难 imec-publications.be 、环境干扰使网络极易变化 imec-publications.be 等。 为了克服这些问题，已有工作采取了多种优化措施。典型做法是将网络度量采集与调度解耦：例如上述网格网络方案引入了独立组件——**网格拓扑控制器（mesh topology controller）配合各节点上的 agent 定期测量延迟和带宽，并更新专用的拓扑 CRD imec-publications.be ；同时使用网格连接控制器（mesh connection controller）**在网络中建立或维护静态路由，将数据流限制在预定路径 imec-publications.be 。这种设计可以使调度器仅关注经处理后的网络信息，减轻自身负担。另外，利用 CNI 插件的 QoS 能力也是关键手段：如使用 Calico 带宽限速确保各 Pod 带宽可控 scheduler-plugins.sigs.k8s.io 。Kubernetes 原生的拓扑路由特性也可在网络层面提供改进，通过优先同区流量降低时延 kubernetes.io 。综合来说，目前的研究主要通过多组件协同（度量采集器 + 调度插件 + 网络控制器）和算法优化，尽可能在动态网络下为调度器提供稳定的网络视图，降低调度决策和网络实现间的矛盾。 参考文献： 已引用文章和项目均为近年成果，包括 KEP 文档 scheduler-plugins.sigs.k8s.io scheduler-plugins.sigs.k8s.io 、Koordinator 博客 koordinator.sh 、Volcano 官网 volcano.sh 、相关研究论文 link.springer.com imec-publications.be 等。以上资料从学术论文、开源实现到官方文档，全面反映了 2023–2025 年期间网络感知调度的最新进展。