← 回到筆記2025-07-14

Karpenter Consolidation & Disruption Budget

說明 Karpenter 的 consolidationPolicy 與 disruption budgets 的作用、搭配方式，以及保守到激進三種設定範例。

發佈 ~2 分鐘 #K8s#karpenter

Karpenter 運作原理

Disruption

Karpenter 是 AWS 開源的 Kubernetes 自動擴縮容器排程器，除了能根據工作負載自動啟動/關閉節點之外，還提供了 Disruption Budget 與 Consolidation Policy，讓使用者能更細緻地控制節點調整的「節奏」與「策略」。這兩者是省成本與穩定性的核心平衡器。

先來看範例：

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: general
spec:
  disruption:
    budgets:
      - nodes: 50%
      - duration: 9h
        nodes: 5%
        schedule: 0 9 * * mon-fri
    consolidateAfter: 15m
    consolidationPolicy: WhenEmptyOrUnderutilized
  ...

翻譯成白話文：

  • 每週一到週五、9:00-18:00，只能砍 5% nodes，除此之外的時間可以砍到 50% 的節點。
  • 觀察 15m 後就進行動作
  • consolidationPolicy 意指壓縮會發生在「機器為空、或利用率不足時」

以下是 GPT 幫我整理的理解文件：

一、Consolidation Policy

1. 定義

consolidationPolicy 控制 Karpenter 何時、以什麼標準來收斂節點。簡單說，它回答了問題：「這台機器要不要收掉？」

2. 可選值

  • Never
    • 永不進行 consolidation。
    • 適用情境：
      • 想完全避免因為節點移動造成干擾。
      • 特殊環境（例如金融法遵測試環境）需要長時間穩定。
  • WhenEmpty
    • 只有在節點完全沒有 Pod 時，才會移除節點。
    • 適用情境：
      • 保守策略，不影響業務。
      • 適合剛上線或對穩定性要求高，但仍想避免空跑機器的場景。
  • WhenEmptyOrUnderutilized
    • 節點完全空，或是「利用率不足」時，就會考慮收掉。
    • 判斷標準依據 Pod requests 與節點可用資源。
    • 適用情境：
      • 追求成本最佳化。
      • 批次性工作、流量起伏大的平台。
      • 已對關鍵服務設置好 PodDisruptionBudget (PDB)，能抵禦 Pod 遷移帶來的影響。

二、Disruption Budget

1. 定義

disruption.budgets 用來限制「在同一時間允許多少節點被中斷」。它回答了問題：「一次可以動多少台？」

2. 基本欄位

  • nodes
    • 表示允許同時被中斷的節點比例或數量。
    • 支援：
      • 百分比（例如 20%）
      • 數字字串（例如 '1' 表示最多一台）
  • duration
    • 該規則生效的持續時間。
  • schedule
    • 使用 cron expression 指定觸發時間點。
    • 與 duration 搭配，能形成「時間區間」的限制。

3. 常見設計模式

  • 全域預設 
    - nodes: 20%
    → 平常最多 20% 的節點同時被中斷。
  • 上班時間禁止 
    - duration: 9h
  nodes: "0"
  schedule: 0 9 * * mon-fri
    → 每週一到五早上 9 點開始，9 小時內不允許整併。
  • 低峰時段加強 
    - duration: 12h
  nodes: 50%
  schedule: 0 20 * * * # 晚上 8 點開始
    → 晚上流量低，允許一次動掉一半節點，加速節省成本。

三、如何搭配使用

保守型（穩定優先）

consolidationPolicy: WhenEmpty
budgets:
  - nodes: 10%
  • 只清空機器，不動低利用節點。
  • 適合金融、醫療、政府等高 SLA 場景。

平衡型（一般業務）

consolidationPolicy: WhenEmptyOrUnderutilized
budgets:
  - nodes: 20%
  - duration: 9h
    nodes: 0
    schedule: 0 9 * * mon-fri
  • 平常最多動 20%，但上班時段完全靜止。
  • 適合 SaaS / 電商業務，避免上班時間造成干擾。

激進型（成本優先）

consolidationPolicy: WhenEmptyOrUnderutilized
consolidateAfter: 15m
budgets:
  - nodes: 60%
  • 幾乎即時收斂，且一次可移除大部分節點。
  • 適合批次工作集群、ML/CI/CD 測試環境。
  • 前提是：有設定好 PDB、ReplicaSet/HPA，能自我修復。

四、實務建議

  1. 結合 PDB 與 HPA
    • 讓應用本身具備彈性，才不怕 Pod 被遷移。
  2. 漸進式調整
    • 從 WhenEmpty 開始，再進階到 WhenEmptyOrUnderutilized。
    • Budget 先保守（10~20%），再逐漸放寬。
  3. 利用 schedule
    • 上班時間保守，夜間/假日激進。
    • 配合業務流量型態，成本最佳化。
  4. 監控與回饋
    • 觀察 Node 數量、Cluster Cost、Pod Restart 次數，評估策略效果。
    • 適度調整 consolidateAfter（例如 1h → 15m）。

五、總結

  • Consolidation Policy 決定「什麼情況下」移除節點。
  • Disruption Budget 決定「同一時間可以動**（刪除）**多少節點」。
  • 兩者合用，就像一個「油門」與「剎車」，讓 Karpenter 在 成本 與 穩定性 之間找到平衡點。
  • 選擇策略的關鍵在於：
    • 工作負載是否能承受 Pod 遷移
    • 流量曲線是否有明顯高低峰
    • 成本壓力 vs 穩定性優先度
← 回到筆記