Cluster Autoscaler Node Protection¶
概念概覽
雙重保護機制設計¶
核心知識¶
雙重保護機制設計¶
方案 A（主動防禦）: safe-to-evict=false annotation
→ CA 分析 node 時直接跳過帶有此 annotation 的 pod
→ CA 不會嘗試 drain 此 node
方案 B（被動防禦）: PDB minAvailable=1
→ 若 CA 仍嘗試 drain，eviction 請求被 PDB 拒絕
→ drain 失敗，CA 退縮
只有 PDB 時：CA 仍週期性嘗試 drain，有短暫 disruption 風險，影響 QA 測試穩定性。
PDB + safe-to-evict=false：CA 連嘗試的動作都不會發生，node 完全透明於 CA 的縮減邏輯。
safe-to-evict annotation 設定方式¶
# 設定在 pod 上（透過 deployment annotation）
kubectl patch deployment -n ps <name> \
-p '{"spec":{"template":{"metadata":{"annotations":{"cluster-autoscaler.kubernetes.io/safe-to-evict":"false"}}}}}'
何時必須用雙重保護¶
當 node 資源利用率遠低於 CA 縮減門檻時（如 cpu 15-19%、memory 7%），CA 「必然」嘗試縮減該 node。實際案例驗證：qa-test node 的低利用率，在沒有 safe-to-evict 保護的情況下，數分鐘到數小時內必被 CA 縮減。
經驗教訓¶
-
只有 PDB 時 CA 仍會週期性嘗試 drain，必須搭配 safe-to-evict=false 才能完全阻止 CA 動作
-
低資源利用率的 node（cpu < 50%）必然是 CA 縮減目標，不能期待 CA 自然放過
-
safe-to-evict 是 annotation 設定在 pod 上，不是設在 node 上
常見陷阱¶
-
誤以為只有 PDB 就足夠：CA 仍會嘗試 drain，PDB 只是讓 drain 失敗，不是讓 CA 不嘗試
-
safe-to-evict=false 的副作用：即使 qa-test 站點完全閒置，CA 也無法回收此 node
最佳實踐¶
-
監控 CA 日誌確認 CA 確實因 safe-to-evict 跳過 qa-test node，而非其他原因
-
PDB 與 safe-to-evict 搭配使用：前者被動防禦，後者主動防禦
相關概念¶
- Cluster Autoscaler ASG Tag Mechanism
- EKS Node Group Creation with eksctl
- EKS Node Group Migration Runbook
- EKS NoExecute Taint Toleration Scheduling
相關視角¶
以下頁面與本概念共享主題，但從不同角度切入。保留獨立視角同時提供交叉參考：
- EKS Auto Mode NodePool 與 Cluster Autoscaler 衝突 — 共享：
cluster-autoscaler,pdb/ 獨特：auto-mode,bottlerocket
來源 Sessions¶
| 日期 | Session | 貢獻摘要 |
|---|---|---|
| 2026-03-24 | 6faf05ec-5823-4354-9fcd-f9c48bb322ca | 記錄了 CA 雙重保護機制（PDB + safe-to-evict=false）的實際效果差異，以及為何只靠 PDB 不夠。 |