业务有诉求，资源会响应：TKE 智能调度实践​

赵贇，腾讯云高级开发工程师，主要负责 K8s 调度相关研发工作。

孟凡杰，腾讯云原生调度负责人，Crane项目发起人。

李佳南，腾讯云高级产品经理，主要负责 K8s 调度、AI 相关产品工作。

从割裂到协同：PlacementPolicy破局之道

现代企业的容器化架构中存在清晰的职责边界：业务研发团队专注于应用功能开发与性能优化，基础设施运维团队则负责资源可用性管理与成本控制。这种分工本应提高组织效率，但随着规模扩大，Kubernetes原生调度机制无法将业务意图自然映射为资源分配决策。这种割裂增加了管理复杂度，制约了云环境资源效能。PlacementPolicy是TKE提供的一种智能调度策略，旨在弥合业务需求与资源分配之间的鸿沟，促进研发与运维团队高效协作。

本文从Kubernetes原生调度机制的痛点入手，详细探讨了PlacementPolicy的价值。接着提供详细实施方法，并通过企业案例验证了其在不同场景下的应用价值，展示了PlacementPolicy如何帮助企业实现资源调度的精细化管理和业务价值最大化。

Kubernetes原生调度的痛点：为何需要PlacementPolicy？

业务场景与调度能力错配

在企业应用架构中，系统通常划分为不同的功能层级，每层对资源的需求各不相同。以典型三层架构为例：接入层（如API网关、负载均衡）对网络性能和连接数要求高；逻辑层（如业务处理服务）对计算性能敏感；存储层（如数据库）则需要稳定的I/O性能和高可用保障。

图片

企业应用架构

Kubernetes原生调度器并不理解这些业务层级的差异化需求。当企业试图表达"API网关需要高带宽节点"或"数据库服务需要分布在不同可用区以提高可用性"这类业务意图时，缺乏直观的表达方式。调度器既不能识别出核心交易服务更应优先获得资源，也无法理解为什么数据处理任务应该优先调度到具有本地存储的节点上。 这种不匹配导致资源分配决策与业务价值脱节。随着业务复杂度增加，这种脱节愈发明显，运维团队需要投入大量精力去"翻译"业务需求为调度器能够理解的语言，使得业务意图难以准确传达到资源分配层面。

云资源特性与调度策略割裂

云计算环境下，节点资源呈现出多样化特性，包括预付费与按量付费的成本差异，标准型、计算型、内存型、GPU加速型等性能特点，以及不同可用区的部署位置。

这些特性直接影响业务性能、可用性和成本效益，但Kubernetes原生调度器对这些云资源特性的感知能力十分有限。它将各类节点视为同质化的资源池，仅关注资源量是否满足Pod需求，而忽略了节点类型与业务特性的匹配关系。这导致无法优先利用成本较低的预付费资源，计算密集型服务可能被调度到内存优化型节点造成浪费，有状态服务在扩缩容时无法保持云盘与节点的亲和性影响数据访问效率。 

尤其在多云或混合云环境中，各云厂商的资源特性和计费模式差异显著，更需要调度机制能够理解并利用这些差异来优化部署，而传统的调度机制难以应对如此复杂的资源特性，使企业无法充分发挥云资源的价值潜力。

配置复杂与变更风险

Kubernetes提供了丰富的调度机制，但随之而来的是配置复杂度的激增。企业试图通过组合使用nodeSelector、affinity、topologySpreadConstraint等规则来实现业务需求，但这些原子化的调度规则缺乏层次结构和业务语义，导致配置难以维护和理解。 

更严重的是，调度规则的调整与业务连续性存在根本冲突。由于规则通常嵌入在Pod规范中，任何调度策略的变更都需要重建Pod才能生效。对于生产环境的关键应用而言，这意味着要么保持次优的调度策略牺牲资源效率但避免服务中断，要么重建Pod应用新策略提升效率但承担服务波动风险。 

这种"全有或全无"的变更模式违背了云原生环境中推崇的渐进式变更理念，限制了企业持续优化资源分配的能力。特别是在大规模部署场景下，无法对新创建的Pod应用更优策略而保持存量Pod不变，使得调度策略优化成为高风险操作，企业不得不保守行事，错失资源效率提升机会。

PlacementPolicy破解调度难题

业务导向的调度策略

运维团队可以定义如"高可用业务优先使用多可用区部署"、"成本敏感应用优先使用预付费资源"这样的策略，而无需深入技术细节。这种业务语义层的抽象降低了技术门槛，使业务人员无需理解复杂的Kubernetes调度机制，即可参与资源策略决策。同时，策略以业务目标而非技术参数表达，便于跨团队理解和沟通，避免了不同团队、不同应用采用不一致的调度规则，提高了资源治理水平。例如，金融行业客户可以简单表达"支付系统需要跨可用区高可用部署，同时优先使用性能稳定的专有节点"，系统自动将这一业务需求转化为精确的调度决策，确保业务可靠性同时优化资源使用。

高效的职责分工

PlacementPolicy建立了一种新型协作模式，让运维与研发各自专注于自己的核心职责。运维团队从繁琐的调度规则配置转向战略性资源管理，定义符合企业整体目标的资源策略；研发团队则摆脱复杂的调度参数配置，只需通过简单标签表达应用特性，即可享受合理的资源分配；策略的集中定义与管理避免了分散决策带来的低效和不一致。这种分工使运维团队能够建立全局资源视角，统筹考虑成本、性能和可靠性，而研发团队则能够专注于业务逻辑开发。通过减少两个团队在调度配置上的协调成本，企业整体研发效率得到提升，加速应用交付流程。

渐进式变更保障

PlacementPolicy使调度策略变更只影响新创建或重建的Pod，现有服务保持稳定运行。企业可以先在非关键业务验证新策略效果，确认无误后再扩大应用范围。随着新Pod创建和旧Pod自然更新，系统逐渐向更优资源配置演进，而无需进行大规模停机迁移。这种渐进式变更大大降低了优化资源分配的风险成本，使企业能够更加积极主动地进行策略调整。例如，当企业发现某类新型云实例性价比更高时，可以立即调整策略让新创建的工作负载优先使用这类资源，而无需担心对现有业务造成冲击。这种"安全优先"的演进模式特别适合对业务连续性要求高的企业环境。

智能调度策略驱动三步曲

构建调度策略体系

有效的资源策略需要建立在对资源特性和业务需求的全面理解上。运维团队首先应进行云资源特征分析，系统评估企业云资源池的运行状况。可以借助TKE Insight工具建立资源监控体系，同时结合kubecost、Crane等Kubernetes成本分析工具，全面掌握资源使用情况。

通过这些工具的组合使用，运维团队建立完整的资源使用视图能够。其次，根据业务特性进行评估，利用Skywalking、Jaeger等APM工具，从技术层面和业务价值层面对业务进行评估。技术层面上，分析各应用的资源使用模式、性能特征；业务价值层面，评估服务对营收的贡献度、对用户体验的影响程度。 基于这些分析，运维团队可以设计分层的调度策略体系。最基础的是全局默认策略，通常以成本优化为主要目标。

在此基础上，针对特定业务需求制定差异化策略，如为交易系统提供高可用保障，为数据分析任务分配性能适配的资源。这种分层策略既保证了整体资源分配的一致性，又满足了不同业务的特定需求。策略制定应遵循"粗粒度到细粒度"的原则，再针对特殊场景进行微调。典型的策略层次可包括：

• 全局基线策略：适用于大多数的常规工作负载，以资源利用率和成本效益为主要优化目标。
• 业务域策略：为不同业务域（如支付、搜索、内容）提供差异化资源保障。
• 特殊场景策略：针对促销活动、数据迁移等特定时段和场景的临时策略。
• 例外处理策略：为特殊应用（如遗留系统）提供的定制化调度规则。

在实施过程中，建议采用渐进式方法，先在非核心业务验证策略有效性，再逐步扩大应用范围。建议建立策略效果评估机制，设定明确的KPI，如资源利用率提升10%、运营成本降低15%、关键业务稳定性SLA达到99.99%等，通过数据驱动策略优化。

无侵入式策略关联

PlacementPolicy提供了运维团队主导、对业务无侵入的策略关联机制，这是最常用且推荐的应用方式。该机制设计了多种灵活的关联模式，使运维团队能够根据不同场景、不同粒度精确控制资源分配策略：基于命名空间的批量关联、基于工作负载类型的批量关联以及基于Pod标签的精准关联。 

基于命名空间的批量关联适合按业务域或团队划分命名空间的场景，配置简单且管理集中，特别适合大规模集群。在实际应用中，企业可以定义"prod-"前缀的生产环境命名空间使用高可用策略，"dev-"前缀的开发环境使用成本优先策略，"test-"前缀的测试环境使用动态弹性策略。这种方式大大简化了多环境管理，确保不同环境的资源分配符合其业务特性和重要性。 

基于工作负载类型的批量关联允许运维团队针对不同特性的应用组件制定差异化的资源策略，特别适合多种计费模式并存的环境。例如，可以将所有Job和Deployment类型的应用调度到按量付费节点上，利用这些工作负载可中断、可重调度的特性，充分发挥按量付费模式的成本优势和弹性能力。可以将StatefulSet类型的应用部署到预付费节点上，为这些通常运行关键业务、需要稳定存储和网络标识的有状态应用提供更可靠的基础设施保障。在大数据场景下，可以将CronJob类型的定时分析任务调度到Spot实例上，利用低价资源处理非紧急任务，进一步优化成本结构。 

基于Pod标签的精准关联则适合需要细粒度控制的场景，运维团队可基于已有的业务标签选择器关联调度策略，无需修改工作负载定义。对于生产环境内部的细分策略，可以采用这种模式，根据业务类型、服务等级等维度进行更精细的调度策略匹配。例如，同一命名空间内，标记为"tier=frontend"的交易服务可应用高性能策略，而标记为"tier=backend"的报表服务则应用成本优先策略。 

这些运维主导的关联机制对业务无侵入，无需修改或重建现有工作负载，同时实现了策略的集中化管理，便于审计和治理。更重要的是，它们具备动态调整能力，运维团队可以根据资源使用情况、成本预算变化或业务优先级的调整，灵活更新策略关联关系，而无需业务团队参与。在实践中，这三种关联模式通常结合使用，形成多层次的资源调度体系，既满足了企业资源治理的统一性要求，又为不同业务场景提供了定制化的资源分配方案，实现资源使用效率与业务性能的最优平衡。

标签化表达

通常情况下，业务团队对自身应用的特征和运行场景有更深入的理解，他们清楚知道业务功能的关键性（如交易核心链路或后台批处理）、资源敏感度（CPU密集型或内存密集型）以及可用性要求（如高可用或容灾级别）。业务团队需在应用部署或更新时，通过运维团队已定义的标准化标签体系，以声明式的方式直接表达资源需求。例如，为实时风控服务标记 high-availability: true 和 latency-sensitive: high，或为测试环境标记 environment: dev。这种标签化声明简化了沟通成本，同时为运维团队提供了明确的配置依据。通过这种标准化的标签体系，运维团队可以根据标签将 cpu-intensive 负载调度到不同云环境中的计算优化型节点，由于修改标签需重建工作负载，此方案更适合新应用发布、版本迭代或非生产环境。 

更进一步地，企业可以在CI/CD流水线中集成调度策略选择的功能，提供标准化标签目录。业务团队可以通过下拉菜单选择预定义标签，系统自动将这些标签注入到应用中。更进一步地，系统可以基于应用的历史资源用量，智能推荐调度策略。需要注意的是，企业应通过权限模型控制不同角色的策略访问范围，比如开发人员使用标准化策略，运维团队可调整高级配置等。 

需要强调的是，这种业务自主方式是对运维主导模式的补充，在大多数企业场景下，仍推荐以运维主导的无侵入策略关联为主，结合业务标签表达特殊需求。

实践典范：PlacementPolicy破解企业业务难题

电商企业的成本优化之旅

一家电商企业面临着云计算成本持续增长的挑战，特别是在促销期间，资源需求增加导致成本上升。企业IT团队发现，问题之一在于调度系统难以区分不同资源的成本特性，导致资源利用不够均衡——昂贵的按量计费节点使用率不高，而低成本的预付费节点未被充分利用。 

在实施PlacementPolicy后，企业设计了一个成本优化模型，将资源按成本特性排序：预付费原生节点 > 预付费超级节点 > 按量计费原生节点 > 按量计费超级节点。这一策略在应用扩容时会选择经济合适的可用资源，在应用缩容时优先释放成本较高的资源。 

实施几个月后，企业云计算成本有所降低，同时业务响应时间和可用性指标保持稳定。在最近的促销活动中，系统较好地处理了波峰流量，既满足了业务需求，又帮助控制了成本增长。IT团队表示："PlacementPolicy帮助我们将成本控制目标直接转化为技术实施，减少了复杂的手动干预工作。"

教育平台的潮汐波谷征服记

一家在线教育平台的业务负载具有典型的潮汐特性——工作日晚上和周末的学习流量是平常的5倍以上。在传统模式下，企业不得不为峰值负载预留大量资源，导致在低峰期资源严重闲置，而在高峰期仍面临扩容不及时的风险。

图片

潮汐业务的资源特性

采用PlacementPolicy后，企业实施了潮汐业务调度模式。他们为教育服务定义了基础负载（满足日常需求的部分）和弹性负载（应对峰值的部分）。系统自动将基础负载调度到成本固定的预付费节点，将弹性负载调度到按需付费的弹性节点。在周末高峰期，系统通过扩容弹性节点以应对增长的流量；在工作日低峰期，这些弹性资源又会自动释放，避免不必要的支出。 

这一策略使企业的资源利用率有所提高，云计算成本得到了更好的控制。更令人满意的是，运维团队不再需要每周末手动扩容和缩容，大大减轻了工作负担。技术负责人评价道："PlacementPolicy让我们的资源规模能够'呼吸'一样。随着业务需求自然伸缩，既保证了学习体验，又减少了资源浪费。"

金融机构的高可用性实战

金融业务通常需要确保系统的高可用性，即使在部分基础设施故障的情况下也能继续提供服务。同时，金融业务团队也面临着控制IT成本的压力，需要在保障服务质量的前提下优化资源投入。

金融团队采用了PlacementPolicy的高可用模式，确保交易系统的Pod均匀分布在多个可用区，并在每个可用区内优先使用更经济的资源。系统配置了严格的拓扑约束，确保任何单一可用区的故障都不会影响整体服务可用性。同时，通过资源优先级设置，系统在满足可用性要求的前提下，尽可能使用成本效益最高的资源。 

这一策略在一次计划外的可用区维护事件中发挥了关键作用——交易系统保持了服务连续性，客户没有感知到任何异常。同时，通过更精细的资源分配，团队在不影响服务质量的前提下，降低了交易系统的运营成本。架构负责人表示："PlacementPolicy让我们能够将高可用性要求转化为明确的技术策略，同时兼顾成本效益，这在以前几乎是不可能的。"

智能调度演进蓝图

PlacementPolicy代表了Kubernetes资源管理的范式革新，通过连接业务语义与调度机制，使企业能够将策略意图直接转化为资源分配行为。未来，资源调度将向智能化方向深度演进：基于机器学习的自动化策略推荐将助力企业在成本与可用性间寻找最优平衡点；预测性调度则将根据业务流量模式提前精准调配资源，实现“资源走在需求前”。这些智能化能力将构筑更高效、更自主的云资源治理体系。

参考

TKE PlacementPolicy docs：https://cloud.tencent.com/document/product/457/118259