EKS Add-on Upgrade¶
概念概覽
PRESERVE vs OVERWRITE¶
核心知識¶
PRESERVE vs OVERWRITE¶
# PRESERVE：保留使用者自訂設定，但在 ARM 架構容易 timeout
aws eks update-addon --resolve-conflicts PRESERVE
# OVERWRITE：覆蓋自訂設定，ARM 架構建議直接使用
aws eks update-addon --resolve-conflicts OVERWRITE
PRESERVE在 ARM 架構（c7g.2xlarge）下可能超過 31 分鐘 timeout 仍無法完成- 腳本 timeout 時 add-on 狀態仍是
UPDATING而非FAILED，需用describe-addon確認 - 建議 ARM 架構預設使用
OVERWRITE
aws-node CrashLoopBackOff 根因¶
add-on 卡在 UPDATING 的根本原因可能是特定節點的 aws-node Pod 無法啟動：
# 診斷指令
kubectl get pods -n kube-system -l k8s-app=aws-node -o wide
# 若看到 1/2 Ready → 表示 CNI gRPC 健康檢查失敗
kubectl logs <aws-node-pod> -n kube-system
# 錯誤特徵：grpc-health-probe :50051 失敗
coredns ContainerCreating 快速解法¶
不需修好問題節點的 aws-node，直接讓 coredns 繞過：
# 1. Cordon 問題節點
kubectl cordon <problem-node>
# 2. 刪除卡住的 coredns pod
kubectl delete pod <stuck-coredns-pod> -n kube-system
# 3. 等新 pod 在健康節點啟動（Deployment 自動重排程）
kubectl get pods -n kube-system -l k8s-app=coredns -w
# 4. 確認後 uncordon
kubectl uncordon <problem-node>
經驗教訓¶
-
Add-on 升級後要監控所有 add-on，不只是目標 add-on（aws-ebs-csi-driver 可能意外 UPDATE_FAILED）
-
aws-node ½ Ready 是 CNI gRPC 問題的信號，會導致整個 add-on 升級卡住
-
coredns 重新排程比修復問題節點快，是更實用的臨時解
常見陷阱¶
-
PRESERVE 模式在 ARM 架構超過 31 分鐘是常見 timeout，不代表失敗
-
只關注目標 add-on 狀態，忽略其他 add-on 的 UPDATE_FAILED
最佳實踐¶
-
ARM 架構 Add-on 升級預設使用 --resolve-conflicts OVERWRITE
-
升級腳本 timeout 後主動執行 aws eks describe-addon 確認實際狀態
-
使用 check_addon_status.sh 持續監控所有 add-on
相關概念¶
- EKS Cluster Version Upgrade
- eks-node-group-rolling-upgrade----dangling-------dangling---
- Istio EKS ARM64 Installation
來源 Sessions¶
| 日期 | Session | 貢獻摘要 |
|---|---|---|
| 2026-03-19 | 7f62faa7-a87f-4880-845e-714dc32b3241 | 深入記錄 ARM 架構下 EKS Add-on 升級的 timeout、CrashLoopBackOff 根因與 coredns 重排程解法 |