跳轉到

13.3 成本治理 FinOps：混部與資源利用率#

雲帳單刺客：為尖峰買單、為閒置付費#

大促備 1000 核，平時只用 200 核——800 核的閒置就是利潤黑洞。FinOps 不是「省錢運動」，而是讓成本可見、可歸屬、可優化的工程實踐：誰用的資源、值不值、花在哪裡。

利用率三板斧：請求值、混部、彈性#

1. 把 request 設對：request 是調度的「訂位」，設太大等於包場吃一半扔一半。用 VPA 推薦值收斂：

# 看實際用量 vs 申請量（Prometheus）
# container_memory_working_set_bytes / kube_pod_container_resource_requests
kubectl top pods -n prod --sort-by=memory | head -20

# VPA 推薦（先用 Off 模式只看建議）
kubectl get vpa order-svc -n prod -o yaml | grep -A8 recommendation

2. 混部（Colocation）：在线服務的碎片資源跑離線/低優任務。K8s 手段是 QoS + 搶佔：

# 在線服務：Guaranteed（request=limit），優先保障
# 離線任務：BestEffort + 低優先級，可被驅逐
apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: batch-low
value: -1000
globalDefault: false
---
apiVersion: batch/v1
kind: Job
metadata:
  name: offline-report
spec:
  template:
    spec:
      priorityClassName: batch-low     # 資源緊張時先被驅逐
      containers:
      - name: report
        image: registry/shop/report:v2

3. 彈性跟隨負載：HPA 跟流量、KEDA 跟佇列（見 11.2 節），閒時縮、忙時擴。

成本分攤：一張表讓各團隊認帳#

標籤（Label） 用途 範例
team 歸屬團隊 team=search
service 歸屬服務 service=order-svc
env 區分環境 env=prod
charge-type 計費模式 包年包月 / 按量 
# OpenCost / Kubecost：按 label 分攤 namespace 成本
kubectl apply -f https://raw.githubusercontent.com/opencost/opencost/develop/kubernetes/opencost.yaml

# 例行 FinOps 報表三問：
# 1) 上週 TOP5 燒錢服務是誰？ 2) request/limit 利用率 <30% 的是誰？
# 3) 有無可轉 Serverless/Spot 的閒置？

2025–2026：FinOps 遇上 GPU 與 AI#

AI 推理把 FinOps 難度拉高一級：GPU 一卡難求、一卡千金。對應手段（見 14.2、14.5 節）：vGPU/MIG 切分、GPU 共享調度、閒時跑 Batch 推理混部、按 Token 計費透傳到業務方。原則不變：可見（每千 Token 成本）→ 優化（共享+彈性）→ 治理（預算與配額）。

本章小結#

  • FinOps 循環：可見 → 優化 → 治理；先分攤認帳，再談優化
  • 優化三板斧：request 收斂（VPA）、混部（QoS+PriorityClass）、彈性（HPA/KEDA）
  • 成本分攤靠 Label + OpenCost/Kubecost；例行三問抓浪費
  • GPU 時代 FinOps 延伸到算力切分、共享與 Token 成本透傳

想一想#

  1. 為什麼 FinOps 第一步是「分攤認帳」而不是直接降配？沒有歸屬會發生什麼？
  2. Guaranteed vs BestEffort 在混部中各扮演什麼角色？誰該被驅逐？
  3. 若 GPU 成本佔你帳單 70%，你會先做切分共享、閒時混部、限流配額中的哪一項？為什麼？