Kubernetes调度：分类、现存问题与挑战

Kubernetes调度：分类、现存问题与挑战
研究报告
引言
Kubernetes作为容器编排的事实标准，具有灵活、高效和可扩展的调度机制，为云原生应用和微服务架构提供了强大的支撑。随着异构硬件、分布式架构和边缘计算等新需求的不断涌现，Kubernetes调度正面临日益复杂的应用场景与资源约束。
在此背景下，这份报告深入研究其调度原理与分类方法，旨在为后来者提供较为系统的背景与思考，对发现问题与应对挑战具有重要意义。
下面先提炼原文内容，再按照原文标题中的Taxonomy, Ongoing Issues and Challenges三个方面来分别探讨Kubernetes当今的应用和未来的发展方向。

原文提炼
章节标号与原文一致。
2 背景、术语和现有的技术
2.1 操作系统级虚拟化
操作系统级虚拟化是一种在共享操作系统内核的基础上创建多个隔离计算环境（即容器）的技术。在Linux系统中，常用的工具包括cgroups、namespaces和chroot。这些技术使得容器能够提供轻量级且高效的资源隔离，适用于云服务中的容器即服务（CaaS）模型。主要的容器运行时如containerd和CRI-O实现了开放容器倡议（OCI）标准，确保了容器的可移植性。Docker作为最知名的容器管理工具，通过其守护进程（Docker Daemon）和容器管理接口，简化了容器的生命周期管理。然而，随着容器数量的增加，手动管理变得复杂，因此需要自动化的容器编排工具来优化资源分配和管理。
2.2 容器编排
容器编排系统负责在大规模集群中自动化部署、管理、扩展和网络连接容器化应用。Kubernetes、Docker Swarm和Mesos是其中较为知名的编排工具。Kubernetes因其广泛的行业采用和主要云服务提供商（如Google Kubernetes Engine、Microsoft Azure Kubernetes Service、Amazon Elastic Kubernetes Service）的支持，成为事实标准。编排器的核心任务之一是调度器，它负责将物理资源分配给容器，直接影响资源利用率、能耗和服务质量（QoS）。容器编排还包括自动扩展、负载均衡、监控和持续集成/持续交付（CI/CD）等功能。编排系统可以分为本地部署的解决方案（如Kubernetes、Mesos）和由云提供商管理的托管服务，用户无需自行维护基础设施。
2.3 Kubernetes 架构
Kubernetes架构由多个组件组成，旨在提供高效、可扩展和弹性的容器管理。其核心组件包括：
• Master 节点：负责集群的管理和调度任务。主要组件有API服务器（API Server）、控制器管理器（Controller Manager）、调度器（Scheduler）和etcd（分布式键值存储）。
• 工作节点（Worker Nodes）：运行实际的容器化应用。每个工作节点包含kubelet（负责与Master通信并管理容器生命周期）、容器运行时（如containerd或CRI-O）以及kube-proxy（负责网络代理和服务发现）。
• Pod：Kubernetes中最小的可部署单元，一个Pod可以包含一个或多个紧密关联的容器，共享存储和网络资源。
• 服务（Service）：定义了一组Pod的访问策略，提供负载均衡和服务发现功能，确保应用的高可用性。
• etcd：一个分布式键值存储系统，用于保存Kubernetes集群的所有状态数据，确保数据一致性和高可用性。
3 Kubernetes 中的资源管理分析
3.1 Kubernetes 中的调度：用户规范
在 Kubernetes 中，用户可以配置多种选项来指定调度器应满足的条件。这些用户规范定义了不同类型的约束，起到了控制准入的作用。这些约束可以在节点级别、命名空间级别或 Pod 级别进行设置。
节点级别的约束主要通过亲和性（Affinity）和污点（Taint）来实现。亲和性属性吸引 Pod 被调度到特定的节点，而污点则相反，阻止 Pod 被调度到带有特定污点的节点。此外，容忍性（Tolerance）是与污点相互补充的属性，每个节点都有一个容忍性设置，如果 Pod 的容忍性高于节点的污点，调度器会将其调度到其他容忍性更高的节点上。
Pod 级别的约束允许用户指定每个容器所需的资源量，包括 CPU 和内存（RAM）。通过设置资源请求（Request）和资源限制（Limit），用户可以控制 Pod 运行所需的最小和最大资源量。资源请求是严格的，调度器会确保节点有足够的资源来满足新的 Pod 请求，而资源限制则防止单个容器过度占用资源，避免影响集群中其他应用的正常运行。
命名空间级别的约束通过资源配额（ResourceQuota）和限制范围（LimitRange）来实现。这些机制可以限制一个命名空间内所有 Pod 的总资源使用量，确保资源在多个团队或项目之间的公平分配。资源配额可以包括 CPU 和内存的总量限制、Pod 数量限制、存储资源限制等，从而防止某个命名空间过度消耗资源，影响其他命名空间的资源可用性。
通过这些用户规范，Kubernetes 提供了灵活且细粒度的资源管理能力，帮助管理员和开发者根据具体需求优化资源分配，提升集群整体的资源利用率和应用性能。
3.2 Kubernetes 中的调度：内部工作流程
Kubernetes 的资源管理过程可以简化为以下几个步骤：当用户请求创建一个具有特定计算资源的 Pod 时，Kubernetes 的主节点接收该请求，并将其转发到 API 服务器和调度器（kube-scheduler）。调度器负责确定哪个工作节点（物理或虚拟服务器）最适合运行该 Pod，并通知运行在该节点上的 kubelet 代理创建 Pod。
3.2.1 默认调度器
默认调度器是 Kubernetes 的核心组件之一，作为单一调度器实例运行在主节点上，负责将 Pod 分配到最合适的工作节点。其生命周期如下：

  1. 监听 Pod 队列：调度器维护一个 Pod 队列（podQueue），持续监听 API 服务器中的未绑定 Pod。
  2. 过滤阶段：调度器从 Pod 队列中提取 Pod，并根据预定义的策略过滤出符合条件的节点。这些过滤条件包括资源可用性、节点标签、端口是否可用等。
  3. 排名阶段：对过滤后的节点进行评分，依据节点的资源使用情况、当前负载等因素为每个节点赋予一个分数。
  4. 绑定 Pod：将 Pod 绑定到得分最高的节点，并更新 etcd 中的绑定信息，通知对应节点上的 kubelet 创建 Pod。
    默认调度器使用的是基于策略的调度方法，允许用户通过配置文件或调度配置（scheduling profiles）自定义调度策略。例如，可以使用 LeastRequestPriority 策略基于节点上的剩余资源进行调度，或使用 BalanceResourceAllocation 策略实现资源的均衡分配。
    3.2.2 扩展 Kubernetes 调度器
    Kubernetes 调度器的功能可以通过多种方式进行扩展，以满足特定的调度需求：
  5. 添加新谓词和优先级：用户可以向默认调度器添加新的过滤器（Predicates）和评分函数（Priorities），然后重新编译调度器。
  6. 调度器扩展器：通过实现调度器扩展器（Scheduler Extender），用户可以在调度周期的过滤和排名阶段调用外部服务。这种方法通过配置 Webhook 实现，但存在集群状态未共享和通信成本的问题。
  7. 调度框架：Kubernetes 官方推荐使用调度框架（Scheduling Framework）作为扩展调度器的方式。调度框架引入了新的扩展点（如队列排序、预过滤、过滤、评分、预留等），允许用户以插件的形式集成自定义调度逻辑，无需修改调度器的源码。
    通过这些扩展机制，用户可以根据具体需求定制调度器的行为，实现更加灵活和智能的资源分配。例如，可以开发特定的插件来实现基于机器学习的调度决策，或集成第三方策略以满足特定的业务需求。
    4 其他容器编排引擎分析
    4.1 行业主要容器编排工具概述
    除了 Kubernetes，当前业界还广泛使用多个容器编排框架，如 Google 开发的 Borg、Apache Mesos 和 Docker Swarm。这些工具各自具有独特的架构特点和调度技术，满足不同生产环境的需求。
    Borg 是 Google 首个统一的容器管理系统，最初用于管理内部的大规模应用。它能够同时处理长期运行的服务和批处理任务，这些任务在之前由两个独立的系统管理。Borg 采用主从架构，拥有集中化的控制器和运行在每台机器上的代理进程，能够扩展到数万台机器。
    Apache Mesos 是一个开源的集群管理器，采用两层架构。它通过中央资源管理器动态控制每个框架调度器所拥有的资源。Mesos 支持多种框架，如 Hadoop、MPI 和 Marathon，使多个框架能够共享同一个集群资源。
    Docker Swarm 是 Docker 的原生集群管理和编排解决方案，集成在自 Docker Engine 1.12 版本中。Swarm 提供集群管理、自动扩展和故障转移功能，适用于快速部署和管理 Docker 容器，但在企业级扩展性和监控能力上相对不足。
    4.2 各编排工具的架构特点
    Borg 采用单片架构，调度器由单一实例组成，处理所有任务请求并维护系统的全局状态。当提交任务时，Borgmaster 将任务持久化到 Paxos 存储中，并将任务添加到待处理队列。调度器异步扫描队列，根据优先级和轮询机制将任务分配到合适的机器上。
    Apache Mesos 的两层架构包括中央的资源管理器和各个框架的调度器。资源管理器使用 Dominant Resource Fairness（DRF）算法动态分配资源，框架调度器根据各自的调度策略在代理节点上分配任务。每个代理节点定期向资源管理器报告可用资源，确保资源分配的公平性和效率。
    Docker Swarm 集成在 Docker Engine 中，采用集中化的集群管理和调度模块。Swarm 的调度器通过过滤和调度策略选择最合适的节点分配容器。支持三种调度策略：spread（均匀分布）、binpack（尽量打包）和random（随机分配），以满足不同的资源分配需求。
    4.3 调度技术比较
    不同的容器编排工具在调度算法和策略上具有显著差异：
    • Borg 使用基于优先级的轮询调度，兼顾公平性和效率，通过全局状态视图优化资源分配。
    • Mesos 依赖于各框架的调度器，采用 DRF 算法确保资源分配的公平性，同时支持多种调度策略以适应不同应用需求。
    • Docker Swarm 提供多种调度策略，如 spread、binpack 和 random，用户可以根据具体场景选择最合适的策略进行资源分配。
    4.4 比较总结
    下表对比了 Kubernetes、Borg、Apache Mesos、Hadoop YARN 和 Docker Swarm 等容器编排引擎的多个特性：
    框架 Kubernetes Borg Apache Mesos Hadoop YARN Docker Swarm
    容器技术 CRI API, OCI-compliant cgroup-based Mesos container cgroups-based, docker docker
    调度架构 集中式集群 单片集中式 两层架构 集中式集群 集中式集群
    调度算法 轮询分发、过滤与排名 优先级轮询 DRF，基于框架 FIFO 轮询，公平 过滤与调度策略（spread-binpack-random）
    支持的应用类型 全部（多任务共置） 全部（独立任务） 单任务 批处理应用 长期运行应用
    Mesos 允许多个框架共享一个集群，采用分布式方法管理大量节点，但缺乏 Kubernetes 的一些功能，如外部存储上的持久卷和默认 IP 分配功能。相比之下，Docker Swarm 提供更快速的部署和更易用的管理体验，但在自动扩展、原生日志和监控组件以及集群状态管理的可扩展性方面不足。
    4.5 基于 Kubernetes 的发行版
    除了原生的 Kubernetes 之外，还有一些基于 Kubernetes 的发行版，如 K3s 和 KubeEdge，进一步巩固了 Kubernetes 作为事实标准编排器的地位。
    KubeEdge 是 CNCF 孵化项目，基于 Kubernetes 扩展到边缘计算环境。它通过 EdgeController 插件管理边缘节点和云端虚拟机，将容器应用跨边缘和云端进行调度和管理，保持统一的 API 接口。
    K3s 是 Kubernetes 的简化版本，专为物联网（IoT）和边缘应用设计。它通过优化插件结构和使用轻量级数据库（如 sqlite3），减少了资源需求，同时保持与原生 Kubernetes 相同的调度、网络和集群逻辑，适用于资源有限的环境。

一、调度分类（Taxonomy）
在Kubernetes的复杂生态中，调度器是核心部件，负责决定哪些Pod应被分配到哪些节点上运行。为了更好地理解不同的调度策略及其适用范围，我们可以将Kubernetes调度划分为以下几个维度：基础设施、集群结构、调度算法、应用需求、性能评估。
1.1 基础设施视角
在Kubernetes中，调度器需要平衡物理层面与虚拟化层面。物理层面包括GPU、FPGA等异构加速硬件、网络拓扑及各种节点的分布。若无法识别GPU或其它专用硬件的可用性，就难以发挥其加速优势。同时，当多个容器共享节点时，CPU、内存、网络与存储I/O的争夺会导致性能干扰。边缘计算则强调节点间的网络延迟、带宽限制，这些因素都会显著影响调度效率。
虚拟化层面主要依靠cgroups与namespaces来达成资源隔离。针对多租户场景，需要考虑容器彼此之间在安全、网络策略和访问控制方面的互不干扰。Kubernetes当前支持多种插件和扩展机制，让用户可自定义资源类型（如GPU插件）或通过Node Affinity指定Pod的部署位置，但想要同时兼顾所有物理与虚拟因素，往往需要更灵活的调度框架。
1.2 集群结构视角
集群视角主要关注调度架构的设计、联邦调度与节点类型管理等方面。
在集群规模较小时，集中式调度架构能有效控制全局，并做统一资源管理。但当节点数快速增长后，集中式调度器可能成为性能瓶颈，导致任务排队延迟或系统不稳定。分布式调度通过为节点分配独立调度单元来分担压力，却可能面临全局视角不足、任务在不同节点间迁移开销过高等问题。
另外，Kubernetes联邦（Federation）在多集群场景下开始应用。不同区域或不同云服务供应商可能拥有不一样的配置与拓扑，如何在规模更庞大的多集群环境中有效地调度Pod，实现数据合规与负载均衡，是业界和学术界都在积极研究的重要方向。此外，在将Kubernetes伸展到边缘或混合云场景时，节点类型繁多（如云端节点、边缘节点、工业物联网节点），调度逻辑会随之更加复杂。
1.3 调度算法视角
Kubernetes默认的调度流程可分为“筛选（Filter）和打分（Score）”两个阶段。
筛选会排除不满足资源请求、亲和性或污点容忍度等条件的节点；打分则基于剩余可用资源、优先级策略等对合格节点进行排名。该方法灵活易扩展，却在应对异构硬件及多目标优化时可能力不从心。
因此，机器学习与智能化调度逐渐进入人们视野。利用深度强化学习或遗传算法等方法，可以根据集群表现与历史调度效果，动态调整策略。但这些模型需要大量训练数据，并且存在可解释性低的问题。在高可用或金融等对稳定性要求极高的环境中，大范围启用自适应算法风险较大，因此依旧需要规则或启发式与智能化方法结合，减小调度波动的概率。
1.4 应用需求视角
应用需求维度强调的是不同类型工作负载所期待的调度特征。
 无状态应用：常见于微服务或批处理作业，对状态管理要求较低，较易实现水平扩缩容。调度时主要关注的是CPU、内存、网络等通用资源指标，以及集群整体吞吐量。
 有状态应用：数据库、缓存等应用需要持久化存储和数据一致性支持。调度器需保证Pod与数据存储节点间的通信成本可控，并在故障恢复时提供可靠的副本管理和数据同步。
 边缘场景：具备高实时性要求的时延敏感应用，可能需要就近调度在网络延迟较小的边缘节点上，以确保良好的用户体验。
 Serverless与混合部署：Serverless应用关注按需弹性与事件驱动，混合部署场景中则多种工作负载混合运行，需要在资源隔离、负载均衡等方面做更多考虑。
1.5 性能评估视角
性能评估是Kubernetes调度研究中不可或缺的一环。由于目前尚缺乏通用统一的评估标准，研究者往往通过基准测试、真实集群实验或模拟器进行评估。
 基准测试使用标准负载生成工具（如sysbench）或微服务集合，来考察CPU、内存、I/O、网络等单项指标，也可利用典型微服务组成的测试平台进行系统级评测。
 真实集群实验即在生产环境或接近生产环境的集群中部署应用，配合全面的监控与日志追踪来观察调度效果。更贴近实际部署场景，但难度和成本也更高。
 模拟器通常针对特定研究需求而设计，能大规模快速试验不同参数配置，但也无法完整还原现实的系统复杂度，有时会与真实结果存在偏差。

二、现存问题（Ongoing Issues）
在了解了Kubernetes调度的主要分类后，我们需要进一步探讨各个层面尚待解决的具体问题，为后续研究与实践提供指引。
2.1 异构硬件支持不足
虽然Kubernetes对GPU、FPGA等硬件提供了一定程度的插件式支持，但在实际部署中，各种加速器与主机资源的统一管理仍不够成熟。设备间的可利用带宽、拓扑结构、数据传输需求往往复杂多变，导致调度器难以同时兼顾硬件高效利用与应用稳定性。
2.2 资源隔离与干扰控制挑战
当多个容器共享同一物理节点时，容器间的资源竞争和干扰不可避免。现有的cgroups、Namespace等技术虽为隔离提供基础，但在高负载、多租户等场景下，如何精细地监控并抑制容器间资源争夺，维持稳定的服务质量，依旧是难题。缓存竞争、IO饱和等问题常导致应用性能大幅下降。
2.3 多集群联邦困难性高
跨集群调度不仅需要考虑每个集群内部的资源状况，还需处理地理位置、网络带宽和合规性的差异。联邦集群的可靠性、数据一致性以及分散的控制机制会产生更高的运维难度。另外，不同集群在版本、配置、网络策略上的不一致，也会影响跨集群负载分配的一致性。
2.4 智能化决策能力有待提升
传统的Kubernetes调度器虽然提供了筛选+打分的灵活机制，但在处理复杂多目标优化任务时，往往依赖静态或半静态的策略。机器学习、智能算法的引入还处于初步探索阶段，普遍存在模型训练数据不足、可解释性不佳等问题。而且在实际运营环境中，为了避免频繁重调度带来的不稳定性，需要更精细的策略来平衡调度效率与系统成熟度。
2.5 统一评估框架缺失
由于社区尚未形成通用的Kubernetes调度评估框架，各类研究成果在测试环境、性能指标、工作负载类型等方面的差异较大，难以形成标准化的横向比较。一些调度算法在小规模模拟环境中表现优秀，但在大规模实际生产环境中可能不尽人意。

三、挑战（Challenges）
在上述问题的基础上，Kubernetes调度领域还面临多方面的挑战，只有不断拓展研究深度、完善实践方案，才能更好地应对复杂且动态的应用需求。
3.1 跨层协同与系统复杂度
Kubernetes调度并非孤立工作，需要与网络策略、存储系统、安全策略、监控和日志等多方面协同配合。随着系统组件数量和功能的增加，跨层依赖关系会让调度流程更趋复杂，要求研究者与实践者既要兼顾宏观架构设计，也要深入细节实现。
3.2 动态负载与弹性伸缩
云原生应用的弹性伸缩特性意味着负载模式随时可能发生大规模变化。如何在保证系统平稳运行的同时，快速且高效地完成容器伸缩与资源再分配，是Kubernetes调度中始终存在的难题。进一步地，服务级SLA（Service-Level Agreement）对响应时间、吞吐量提出了严格要求，也使得调度过程更为复杂。
3.3 边缘计算与移动端场景
当应用延迟要求极高，或者需要就近处理海量边缘数据时，Kubernetes可能需要部署在位置分散且功耗、带宽受限的边缘节点上。如何在轻量化的控制平面中实现可靠调度、在有限的硬件资源上同时满足多种应用需求，是新的研究与工程挑战。同样地，在移动端场景下，节点间的不稳定网络连接与移动性也会迫使调度器做出更加灵活的决策。
3.4 多目标优化与策略平衡
真实生产环境中，调度需在时间、空间和能耗等维度上做出取舍：既要满足应用的响应时间和资源利用率，也要兼顾绿色节能和降低成本。多目标优化策略往往会引入极高的计算复杂度，让调度器在大规模集群中变得难以实时响应。此外，一些场景还须考虑数据位置、带宽成本和隐私策略，进一步增加了调度决策的维度。
3.5 适应未来硬件与新兴应用
随着硬件技术的快速迭代，新的AI芯片、专用加速器、可重构计算设备不断涌现。Kubernetes如何兼容并支持这些新硬件，使其能够无缝地被应用负载调用，是重要研究方向。与此同时，5G、物联网和边缘AI等新兴应用也在不断提出全新的调度需求，如更低的端到端时延、更灵活的负载分发机制等。

结语
Kubernetes调度在容器编排中举足轻重。我们可分别从基础设施、集群结构、调度算法、应用需求和性能评估等多个维度去理解Kubernetes调度的现状与不足，并聚焦异构硬件支持、资源干扰控制、多集群联邦、智能化算法等亟待解决的问题。
随着行业对智能化、弹性化、跨集群与边缘化的组合需求日益增长，调度策略需要进一步演进，以提升Kubernetes调度的高效性与可扩展性。这需要学术界与工业界通力合作，一方面深入挖掘智能算法与自动化运维的潜力，另一方面在实践层面加快标准化评估框架的建立，与跨层系统组件紧密协同，共同创造出更健壮、更灵活的云原生生态。
随着云计算与容器技术的不断演进，Kubernetes调度也将逐步向更智能、更分布、更具弹性的方向发展，为日益多样化的工作负载提供坚实保障。今后，继续关注前沿方案、不断完善评估方法，并加强跨层协作与标准化建设，将是推动Kubernetes调度研究与应用落地的重要推手。

posted @ 2025-02-16 21:46  全球通u1  阅读(118)  评论(0)    收藏  举报