雲端K8s省錢工程
Che Chia Chang
大綱
- 公有雲的費用
- 節省算力成本
- 監控是成本控管的基礎
- 導入成本分析與預測工具
- 自動化資源使用建議
- Saving Plan/Committed Usage
- Spot Instance 與微服務
- Autoscaling: HPA / VPA
- Q&A
動機
- 公司希望賺錢，節省成本
- 團隊希望控制成本
- 個人產生 Credit 與團隊 Impact
公有雲的費用
打開公有雲的 billing
- 算力成本 Compute Resource (cpu, memory)
- 儲存成本 Storage (Disk, EBS, S3…)
- 網路 Networking
今天只會講這個算力成本
- 算力成本 Compute Resource (cpu, memory)
- 今天只會講這個
算力成本
網頁服務的微服務系統，都需要算力
- api server
- cronjob
- business logic job
- 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 監控是成本控管的基礎
- 監測是成本控管的基礎
- 沒有監測就沒有 p99 cpu time / memory usage，也沒有 SLI/SLO
- 沒有檢測下做成本精簡，會碰壞服務
- 如果沒有監測先補檢測
監測：調整前設定目標基準線
- 設定節省目標：ex. 過去 3 個月的 p99 資源用量
- 99% 的時間，memory 使用量都在這條線以下
- 99% 的時間，cpu throttling 在這條線以下
- 多餘的算力 = (分配的 resource - p99)
- 那如果我們把 cpu / memory 降低到 p99 / p99.9 服務品質會受到影響嗎？
監測: 調整後
- 資源用量是否有變化
- 確定沒有改壞東西，有壞要有及時的 alert
- 效能表現：有可能沒壞，但是變很慢
導入成本分析與預測工具
- 有了 prometheus 後，我們知道短期/長期的資源使用狀況
- 要把資源使用轉成成本，需要一個成本計算工具
- 評估是否要做成本精簡，能夠減少多少錢
- 管理上的考量：投資人力成本，與預期回報
成本分析：公有雲 billing
- 計算長時間的費用趨勢
- 適合當作成本精簡後的成果回報
- 不適合當做調整的依據
- 時間計算較長，反饋時間長，不及時，項目不夠精細
- 有無更即時的成本分析工具？
- 有提供 UI
- 基於 prometheus
- 可以針對 allocation 做成本分析 Cost Allocation
- 可以透過 cloud provider 去撈雲端的使用資料
- 設定 target utilization
- request / allocatable
- dev 80%+
- prod 60%
推薦工具: KRR
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
- 根據 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 Saving Plan / Reservation
Spot Instance
Spot Instance: 如何開始
重啟不影響服務品質的
- 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