Cluster Autoscaler ASG Tag Mechanism

概念概覽

CA 管理 NG 的 Tag 機制

核心知識

CA 管理 NG 的 Tag 機制

CA 判斷條件 CA 只要看到 ASG 同時有以下兩個 tag，就會管理該 NG： - k8s.io/cluster-autoscaler/enabled = true - k8s.io/cluster-autoscaler/<cluster-name> = owned

propagateASGTags 的副作用 exsctl YAML 設定 propagateASGTags: true 後，這兩個 tag 會被自動傳播到 ASG。無法在 eksctl YAML 中阻止這兩個 tag 被 propagate，只能在 NG 建立後請管理員手動從 ASG 刪除這兩個 tag。

三層架構職責

CA（控制器）
  └─ 偵測 ASG tag，決定是否管理此 NG
ASG（縮放執行層）
  └─ 定義 min/max/desired，執行實際縮放
NG（EKS 抽象層）
  └─ 管理 EC2 lifecycle 和 Kubernetes node registration

保護策略 移除 CA tag 後，CA 看不到此 NG，縮容完全由 minSize 控制。若設 minSize=1，即使無 workload 也能保持最少一台 node，是 QA 環境保底的正確做法。

annotation 確認方式 cluster-autoscaler.kubernetes.io/scale-down-disabled annotation 必須用 jsonpath 確認：

kubectl get node <node> -o jsonpath='{.metadata.annotations.cluster-autoscaler\.kubernetes\.io/scale-down-disabled}'

直接看 kubectl annotate 的輸出訊息不可靠。

經驗教訓

• NG 建立後必須立即用 verify 腳本確認 CA tag 是否存在，存在就請管理員刪除

• annotation 確認要用 kubectl get node -o jsonpath，不能信 kubectl annotate 的輸出

• QA 專屬 NG 移除 CA tag 後，用 minSize=1 作為保底機制

常見陷阱

• propagateASGTags: true 無法在 eksctl 層阻止 CA tag 傳播，只能事後移除

• kubectl annotate 輸出訊息不代表 annotation 實際狀態，必須用 jsonpath 查詢確認

最佳實踐

• 建立 NG 後立即執行 verify_qa_ng_protection.sh，若 CA tag 存在馬上請管理員刪除

• CA tag 移除後用 minSize=1 保底，確保 QA NG 不會被縮到 0

相關概念

• Cluster Autoscaler Node Protection
• EKS Cluster Version Upgrade
• EKS Node Group Creation with eksctl

相關視角

以下頁面與本概念共享主題，但從不同角度切入。保留獨立視角同時提供交叉參考：

• EKS Node Group Migration Runbook — 共享：asg, eks, eksctl / 獨特：cloudformation, migration

來源 Sessions

日期	Session	貢獻摘要

| 2026-04-09 | 9678fdc0-346d-4959-94b9-7caae9731d2f | 釐清了 propagateASGTags 導致 CA 意外管理新 NG 的完整機制，以及三層架構（CA/ASG/NG）的職責分工 |

---

本概念頁面由 Semi-Brain Wiki 系統自動維護

最後更新: 2026-04-09