Cost Management of Cloud Kubernetes
雲端K8s省錢工程
Che Chia Chang
Outline
- Cost on Public Cloud
- K8s Compute Resource Management
- Monitoring
- Cost Analysis and Prediction
- Resource Recommendation
- Saving Plan
- Spot Instance
- HPA / VPA
- Q&A
Cost on Public Cloud
open your cloud billing
- Compute Resource (cpu, memory)
- Storage (Disk, EBS, S3…)
- Database (Compute Resource + Storage)
- Networking
Today’s topic
-
Today’s topic
- Compute Resource
- cpu & memory
-
Maybe next time
- Storage (Disk, EBS, S3…)
- Database (Compute Resource + Storage)
- Networking
Cost on Public Cloud
CPU / memory intense web service
- RESTful api
- long-connetion service
- business logic
- save state to disk / database
尋找多餘的算力
- 已有足夠的 cpu / memory，多給也不會增加服務品質的多餘算力
- 多少才是夠？
- 減去多少 cpu / memory，依然不改變服務品質
維持SLO
以維持各個服務元件的 SLO為前提，降低 cpu / memory 使用量
基於 SLO 的成本調降
- 負載穩定的元件，可以抓過去 30d 的 p99 cpu time 或 p99 memory usage + buffer
- 負載不穩定的元件，例如 cpu usage 與受活躍用戶數量正比，需要搭配 HPA 水平拓展
- 負載不穩定的元件，但又不能水平拓展，例如 stateful service，可以考慮 VPA
小結：成本控管的基本概念
- 尋找服務中多餘算力
- 以維持 SLO 為前提
- 降低 cpu / memory 使用量
- 依據元件負載特性，選擇適當的調降方式
- scheduler 依據 cpu / memory request 調度 pod
- container runtime 設定 cgroup
- cpu 使用量依據 request 佔 node 比例分配
- 控制 cpu 用量不超過 limit
- memory 使用 limit，超過 limit 會被 oomkill，並依據設定重啟
- 當前 node memory 不足時，會依據 pod request Evict pod
Monitoring
- Monitoring 是 cost management 的基礎
- 沒有 monitoring 就沒有 p99 cpu time / p99 memory usage，也沒有 SLI/SLO
- 如果沒有 monitoring 先補 monitoring
Monitoring: 調整前
- 過去的 p99 資源用量
- 目前的效能表現
- 多餘的算力 = (分配的 resource - p99)
Monitoring: 調整後
調整前後比較
- 資源用量
- 目前的效能表現
- 確定沒有改壞東西
- 有改壞，要有及時的 alert
Cost Analysis and Prediction
- 有了 prometheus 後，我們知道短期/長期的資源使用狀況
- 要把資源使用轉成成本，需要一個成本計算工具
- 評估是否要做成本精簡，能夠減少多少錢
- 管理上的考量：投資人力成本，與預期回報
Cost Analysis: Cloud billing
- 計算長時間的費用趨勢
- 適合當作成本精簡後的成果回報
- 不適合當做調整的依據
- 時間計算較長，反饋時間長，不及時，項目不夠精細
- 有無更即時的成本分析工具？
- 有提供 UI
- 基於 prometheus
- 可以針對 allocation 做成本分析 Cost Allocation
- 可以透過 cloud provider 去撈雲端的使用資料
kubectl port-forward svc/prometheus 9090
git clone https://github.com/robusta-dev/krr.git
source .venv/bin/activate
python krr.py simple \
-p http://127.0.0.1:9090 \
--mem-min 10 \
--cpu-min 10 \
--history_duration 720 -q
- 根據 krr 計算的結果，手動調整
- 有一些工具有提供自動調整 ex VPA
- 需要先知道 VPA 是什麼
- 直接安裝在 k8s cluster 內
- 透過 Prometheus 資料，推薦適當的資源
- 可以自動化推薦資源，調整運行中的 pod，依照設定重啟 pod VPA mode
- 需要可以參考 helm chart
-
kubecost 需要 helm install，krr 不需要
-
kubecost 產生一個漂亮的 UI，krr 產生 command line 報表
-
VPA 需要 helm install，並且會需要 cluster 權限
-
VPA 可以做到自動化調整，邏輯更複雜，有侵入性，設定有問題會出事
剛上手的做法
沒時間細部研究研究元件的行為，直接調整 request 與 limit
- 先調降 request，不動 limit，對服務衝擊較小
- 用抓比例的方式動態調整，例如目前 request 距離 p99 request 差距 1000Mi，你先收 500Mi 回來試個水溫
- p99 直接使用 tool 計算，細節在後面
- 測試環境先行，有信心在上 production
小結
- 收集目前資源使用資料
- 轉化成公有雲的成本
- 透過 tool 建議適當的資源
- 根據服務品質的要求，調降 cpu / memory
- 回頭檢查 SLO 是否有受到影響
HPA: 考量
元件是否能夠水平拓展
- 啟動的 liveness check / readiness check
- laod balancer
- 需要持續調整 scale up / down 的條件與 time windows
- scale up 對依賴服務的 loading 會有影響 ex. 後面的 db
- 退場機制，要如何安全的中斷連線，紀錄 state
VPA
Saving Plan / RI
- AWS Saving Plan / RI
- GCP Committed Use Discount
- Azure Reservation
Spot Instance
Spot Instance: 分類 workload
interruption 直接影響服務品質的就不宜
不影響服務品質的
- stateless
- batch job
- 將 worklaod 從 monolithic 拆分成小的 batch job
- 測試環境 dev / stag
- CI/CD
小結
- krr 工具調整資源
- HPA 做水平擴展
- VPA 自動化調整資源
- saving plan / RI 長期合約打七折
- spot instance 打一折
展望
- cost awareness development
- find-grade optimization
- automation
小結
- cpu / memory
- 監測是基礎
- 依據監測做預測
- 開始調整
- 長期合約打七折
- spot instance 打一折
- HPA / VPA