📚 课程目录第4章容器化应用的资源建模

4. 成本感知的容器调度策略：Kubernetes 调度器原理、成本感知调度插件、节点池与 Spot 实例的成本优化

在 FinOps 驱动的云原生架构中，Kubernetes 调度器是成本优化的核心执行引擎。默认的调度策略仅关注资源充足性与亲和性，而成本感知调度则需要在调度决策中引入实时价格、Spot 中断概率、节点池效率等财务维度。本章将深入剖析调度器原理，并给出可落地的成本优化方案。

4.1 Kubernetes 默认调度器原理与成本盲区

Kubernetes 默认调度器（kube-scheduler）通过两阶段决策（Filtering + Scoring）为 Pod 选择最优节点。其核心流程如下：

  调度阶段：

  1. 过滤（Predicates）：排除不满足 Pod 资源请求（CPU/Memory）、端口冲突、污点容忍等硬性条件的节点。

  2. 打分（Priorities）：对剩余节点按资源利用率、亲和性、拓扑分布等策略打分，选择最高分节点绑定。

成本盲区分析：默认调度器不考虑节点单价、Spot 实例中断风险、跨可用区网络费用等财务指标。这会导致以下典型浪费场景：

场景	默认调度行为	成本后果
Spot 实例优先	同等打分，可能优先调度到按需节点	错失 60-90% 的 Spot 折扣
节点池混合	不考虑节点池单价差异	高成本节点池负载过高
跨可用区流量	忽略 Pod 间跨 AZ 通信成本	产生额外数据传输费用
预留实例覆盖	不感知已购买的预留实例（RI/CUD）	预留实例闲置，按需实例超支

FinOps 建议：在默认调度器基础上，通过调度插件（Scheduler Plugin）或自定义调度器注入成本权重，是当前业界最成熟的成本感知方案。

4.2 成本感知调度插件架构与实现

Kubernetes 从 1.19 版本开始支持 Scheduling Framework，允许开发者通过插件扩展调度器的 Filter/Score/Bind 阶段。成本感知调度插件的核心架构如下：

关键插件实现要点：

Filter 插件：在过滤阶段排除当前 Spot 中断概率 > 20% 的节点，以及单价超过预算上限的节点池。
Score 插件：对剩余节点按 CostScore = (按需价格权重 × 0.3) + (Spot折扣权重 × 0.4) + (中断概率权重 × 0.2) + (预留实例匹配权重 × 0.1) 打分。
数据源集成：通过 Prometheus + Cloud Provider API 获取实时价格与中断事件。

注意：成本感知插件不应完全替代默认调度策略。建议将成本权重控制在 30-50%，避免因过度追求低成本导致调度失败或性能瓶颈。

4.3 节点池策略与 Spot 实例成本优化

节点池（Node Pool）是云服务商提供的节点分组管理机制，结合 Spot 实例可以显著降低计算成本。以下是基于 FinOps 原则的节点池设计策略：

节点池类型	实例来源	适用负载	成本优化幅度
按需节点池	按需实例	关键业务、有状态服务	基准（0%）
Spot 节点池	Spot 实例	无状态批处理、CI/CD、Web 前端	60-90%
预留实例节点池	预留实例（1年/3年）	稳定长期负载	30-60%
混合节点池	按需 + Spot 按比例混合	弹性扩缩容业务	40-70%

4.4 Spot 实例中断处理与调度策略

Spot 实例的最大风险是中断回收（通常提前 2 分钟通知）。成本感知调度需要配合以下机制：

调度策略优化清单：

优先级调度：为 Spot 节点池设置较低优先级，确保关键 Pod 优先调度到按需节点。
拓扑分布约束：将 Spot 实例分散到多个可用区，降低单区域中断影响。
成本阈值告警：当 Spot 节点池使用率超过 80% 时，自动扩容按需节点池作为缓冲。
预留实例兜底：为 Spot 节点池配置预留实例作为“备用容量”，避免中断后全部回退到高价按需实例。

FinOps 指标：监控 Spot 利用率（目标 > 70%）和 Spot 中断率（目标 < 5%），这两个指标直接反映成本优化效果。

4.5 实战：基于成本感知调度的节点池配置示例

以下是一个结合成本感知调度与节点池策略的 YAML 配置示例：

apiVersion: karpenter.sh/v1beta1
kind: NodePool
metadata:
  name: cost-optimized-pool
spec:
  template:
    spec:
      requirements:
        - key: "karpenter.sh/capacity-type"
          operator: In
          values: ["spot", "on-demand"]
        - key: "node.kubernetes.io/instance-type"
          operator: In
          values: ["m5.large", "m5.xlarge", "c5.large"]
      kubelet:
        maxPods: 58
  disruption:
    consolidationPolicy: WhenUnderutilized
    expireAfter: 720h
  limits:
    cpu: 1000
    memory: 4000Gi
  weight: 50
---
apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: spot-priority
value: 500
globalDefault: false
description: "Priority for spot instance workloads"
---
apiVersion: v1
kind: Pod
metadata:
  name: batch-job
spec:
  priorityClassName: spot-priority
  tolerations:
    - key: "spot"
      operator: "Exists"
      effect: "NoSchedule"
  containers:
    - name: worker
      image: my-batch-worker:latest
      resources:
        requests:
          cpu: "1"
          memory: "2Gi"
        limits:
          cpu: "2"
          memory: "4Gi"

  关键配置说明：

  - NodePool weight：设置权重 50，表示该节点池在调度打分中具有中等优先级。

  - PriorityClass：为 Spot 工作负载设置优先级 500，确保非关键任务优先使用 Spot 实例。

  - Tolerations：允许 Pod 调度到带有 Spot 污点的节点，同时通过成本感知插件控制调度比例。

通过上述策略，企业可以在保证业务稳定性的前提下，将计算成本降低 40-70%。下一节将深入探讨如何通过性能分析工具验证成本优化效果。