KubeSummit 2025: 從資源浪費到節能自治：讓你的 K8s 不再像開著 N 個分頁的瀏覽器

當我們將服務搬上 Kubernetes，挑戰從「能跑」變成「跑得好」，而現在又多了一個挑戰：「跑得省」。



在這場分享中，我們將以 GreenPod 為主軸，探討目前在 Kubernetes 生態中，如何用實際可落地的工具（如 kube-green、Descheduler）打造節能導向的資源調度策略，並搭配我們對 Smart HPA 的探索與實驗想法，展示未來可能的智能擴縮架構。內容將涵蓋：

👉 傳統 HPA 在實務上的限制與踩坑案例
👉 GreenPod 的核心概念與落地工具介紹：kube-green、Descheduler...等
👉 如何設計節能調度模式並導入至真實叢集
👉 Smart HPA 是什麼？有什麼是目前可以嘗試的？有什麼坑是必須避開的？
👉 「綠能擴縮」背後的價值不只是省錢，而是工程團隊的新挑戰與成就感

1. 從資源浪費到節能自
治
讓你的 K8s 不再像開著
N 個分頁的瀏覽器
KubeSummit 2025

2. Hello! I’m smalltown
MaiCoin Group 打雜小弟大叔
主要涉略範圍： SRE, IT, Data, QA
時常擔任組織首位推動 DevOps 的人
我不是財務，但我時常都在看帳單

3. 你以為 Kubernetes 跟你沒關係？
每個 Pod 都說自己還在用，沒人敢關

4. 每個月的服務帳單讓人懷疑人生
AWS 帳單
- EKS xxx
- RDS xxx
- …
AWS 美東壞掉了，然後最近 Oracle 業務一直聯絡我

5. 我們都只是雲端世界打工仔
雲端不是免費的，打工仔也不是！

6. 自動化 ≠ 聰明化
讓帳單金額自動化上升

7. FinOps GreenOps
●成本透明化
●精準觀測與報告
Conscience Time
從能跑到要跑得省
●節能文化
●調度與休眠機制
●良知運行時間
●穩定與節能取得平行
救地球，從節省一個 Pod 開始

8. 揪竟是什麼原
因？

9. HPA 沒有反應真實需求
HPA 覺得沒事 使用者已崩潰
HPA：我很好，你們先忙

10. 離峰時段：節點還在加班
它不是敬業，是沒人教它下班

11. 不同工作負載互搶資源
白天跑 API，晚上跑夢想（ ETL）

12. 自動化沒有
完全解決問題

13. 再加上還有
文化問題
A: 其實不知道哪些 Pod 真正重要。
B: 怕砍錯服務，所以不敢動設定。
C: 反正服務帳單又不是我要付的。

14. 讓叢集不只是能跑，還要像個負責任的公民
每個 Pod 都該學會守法（ Resource Quota）

15. GreenPod：讓叢集學會自治
自治叢集： Pod 也要投票選市長

16. 自律 透明
叢集自我調整
永續
三個核心價 值
可觀測 & 可預測 節能 & 穩定

17. Pod=居民、節點 =建築、Scheduler=市政中心
連小小的 Pod 都買得起房了

18. 手動操作
單人決策
Command Automation Consensus Autonomy
自治叢集：從命令到共識
透過腳本
減少錯誤
跨團隊溝通
建立標準
共同運作
透明決策
以前靠 kubectl，現在靠 EQ

19. 第一步：讓 K8s Cluster 好好睡一覺
K8s 也需要良好的睡眠品質

20. kube-green：設定範例
這一段 YAML，讓 K8s 比我還準時上下班
apiVersion: kube-green.com/v1alpha1
kind: SleepInfo
metadata:
name: nightly-sleep
namespace: dev
spec:
weekdays: ["Mon", "Tue", "Wed", "Thu", "Fri"]
sleepAt: "22:00" # 每晚 10 點關閉 Pod
wakeUpAt: "07:30" # 早上 7 點自動喚醒
timeZone: "Asia/Taipei"
excludeRef:
- kind: Deployment
apiVersion: apps/v1
name: "alertmanager" # 關鍵服務不進入睡眠

欄位 說明 範例
weekdays 定義執行週期
平日工作時段 啟用、週末
休眠
sleepAt /
wakeUpAt
休眠與喚醒時間
Cluster 夜間自動關機、
早晨自動復活
excludeRef 永遠清醒的服務 像是監控系統、登入 API

21. kube-green：導入挑戰
其實要讓 Pod 睡著，還是比哄小孩簡單
挑戰 問題類型 建議處理方式
應用相依性 A 依賴 B 無法喚醒 label 分組控制
喚醒延遲 冷啟動造成體驗不佳 提前喚醒、預留 Pod
排程與例外衝突 夜間任務中斷 專用 namespace

22. Kube-green：最佳實踐 I
選對 Namespace
不是每個 namespace 都適合午休
類型 是否適合休眠 範例
✅ 非即時服務 Web staging、internal API 測試或預覽環境可休眠
?????? 即時或常駐服務 Login API、監控系統 永遠清醒（ excludeRef）
⚙ 資料任務類 Batch / ETL / CronJob 視執行時段設定 wake-up 時間

23. Kube-green：最佳實踐 II
設定時間區段
讓 K8s 有個規律的作息時間
團隊類型 推薦設定 理由
台灣在地團隊 sleepAt: 22:00, wakeUpAt: 07:30 符合上班時段
全球分布團隊 每區各自設定 timeZone避免跨區誤觸關機
實驗環境 白天關、晚上開 測試夜間批次任務

24. Kube-green：最佳實踐 III
觀測與驗證
讓 K8s 有好的起床儀式
●監控 scale-down / scale-up 成功率
○可用 Prometheus + Alertmanager 確保睡眠任務執
行無誤。
●檢查事件日誌
○kube-green 會寫入 SleepInfo event，可用來追蹤喚
醒狀態。
●搭配 KEDA / HPA 結合使用
○避免白天突發流量時無法即時回應。

25. 第二步：讓 K8s 資源會流動
Descheduler aka Pod 的搬家達人

26. Descheduler 怎麼運作
Descheduler 不幫你搬家，它只是通知房東有惡房客 ...
apiVersion: descheduler/v1alpha1
kind: DeschedulerPolicy
strategies:
"LowNodeUtilization":
enabled: true
params:
nodeResourceUtilizationThresholds:
thresholds:
cpu: 20
memory: 20
targetThresholds:
cpu: 60
memory: 60


策略名稱 功能 適用場景
RemoveDuplicates 移除重複的 ReplicaSet Pod 避免同服務 Pod 都被排到同一節點
LowNodeUtilization 釋放過度使用的節點 自動平衡節點負載
RemovePodsViolati
ngInterPodAntiAffin
ity
修正違反 anti-affinity 規則的 Pod 當調度器當初「將就」放錯地方時
RemovePodsViolati
ngNodeTaints
修正違反 taint/toleration 的 Pod 節點標記變更後保持一致性
RemovePodsViolati
ngNodeAffinity
修正違反 node affinity 的 Pod 節點拓樸或標籤更新時
PodLifeTime 移除超時運行的 Pod 用於短期任務、節省資源

27. Descheduler 的設定與限制
設定不難，難的是你敢不敢讓它動
●1⃣ 非即時調度器
○它是週期性執行（ Interval Based），不是事件觸發。 ➡ 適合用來「調
整體質」，不適合即時修復。
●2⃣ Eviction 風險
○若策略過 aggressive，可能造成短暫服務中斷。 ➡ 建議先 dry-run、
再逐步放寬條件。
●3⃣ 與其他元件衝突
○若同時搭配 Cluster Autoscaler / HPA，需確保節點擴縮與再平衡時
序一致。 ➡ 否則可能出現「 Descheduler 移出 ➡ Autoscaler 先擴
後縮 ➡ Scheduler 卡住」的輪迴地獄。
●4⃣ 缺乏即時可視化
○原生無 dashboard ➡ 建議整合 Prometheus event metrics 或 Loki
日誌觀察。

28. Descheduler 實務建議
別讓兩個 scheduler 打架
場景 推薦做法 理由
節能 + 再平衡併用 先 kube-green → 再 Descheduler 讓喚醒後的 Pod 自動重新分佈
搭配 Cluster Autoscaler
錯開排程時間（例： Autoscaler 5min、
Descheduler 1h）
避免同時縮容造成震盪
搭配 HPA 固定最小副本數（ minReplicas）
避免 Descheduler 移動剛被 HPA
縮掉的服務
節點維護／升級
手動觸發 Descheduler 或使用策略
RemovePodsViolatingNodeTaints
自動幫你清空節點，像滾動升級助
手
觀測整合
加入 Prometheus
metrics：descheduler_evictions_total
追蹤搬遷次數與頻率

29. 第三步：讓 K8s 學會『更聰明地擴縮』
傳統 HPA：食量大的狂夾菜，廚
房忙翻天，還是有人吃不飽
從「各自擴縮」到「資源共享」
Smart HPA：食量小的讓出菜，
大家都吃得飽、也不浪費

30. Smart HPA：讓叢集學會協調資源
監控 → 分析 → 協調 → 執行 → 回饋

31. Smart HPA 的成果與評估
在論文裡，它贏了； 在正式環境裡，大家還在等有勇者試
Overutilization
Overprovision
Underprovision
Allocation
Efficiency

32. Smart HPA：現況 × 啟示
?????? 現況
●目前仍屬學術研究階段，尚未進入商業生 產應用。
●作者團隊已於 GitHub 開源原型： hussainahmad05/smart_hpa。
●評估環境： AWS EKS + Online Boutique benchmark，展現顯著資源效率。
?????? 未來方向
研究方向 說明
AI-based 預測 導入 ML / RL 模型，讓 HPA 能主動預測負載
縮短 Container 啟動時間 改善冷啟動效能，加快自動擴縮反應
多維度 Metrics 支援 除 CPU 外，納入記憶體、延遲、網路延遲等複合指標

33. 從節能到自治： GreenPod 的完整藍圖
會節能、會搬家、還會開會的 K8s
Green Pod
kube-green
Descheduler
HPA, KEDA, AutoScaler,Karpenter, … Smart HPA

34. 落地前的三個現實檢 查 I
自動化不是萬靈丹，沒共識的自動化只會更快吵架
●?????? 現實檢查 #1：組織準備度（ Readiness）
○你的團隊願意「讓服務休息」嗎？
○有共識定義哪些服務能睡、哪些不能？
○有專人維護這類自動化策略嗎？

35. 落地前的三個現實檢 查 II
如果你看不到浪費，就永遠省不了錢
●?????? 現實檢查 #2：觀測能力（ Observability）
○能清楚看到每個 namespace 的 CPU / Memory 利用率？
○能追蹤節能成效（例如節點關閉時的帳單變化）？
○監控與告警是否會在夜間休眠時誤報？

36. 落地前的三個現實檢 查 III
當工程師開始問『這 Pod 要花多少錢？』， 才算準備好
●?????? 現實檢查 #3：成本意識（ FinOps Mindset）
○你的組織真的在意服務帳單嗎？
○是否有建立節能 KPI？（例：月度節省率、 node idle ratio）
○是否能將節能成果「回饋」給團隊？（例如績效或獎勵）

37. 從 FinOps 到 GreenOps
FinOps 解決帳單壓力， GreenOps 解決良心壓力
Responsible Governance

38. Responsible Governance
K8s Cluster 的公民化運動

一個成熟的 Pod，不只是穩定運作，更懂得為自己
的存在付出責任

39. 永續的系統
來自有意識的工
程

40. CREDITS: This presentation template was created
by Slidesgo, including icons by Flaticon, and
infographics & images by Freepik
THANKS!
Do you have any
questions?

41. We’re Hiring!
●Senior Site Reliability Engineer
●Blockchain Engineer (Wallet Team)
●(Senior) Backend Engineer
●Micro Service Software Engineer
●Security Researcher
我們需要更多有趣的人來一起節能減碳