EKS Cluster Version Upgrade¶
概念概覽
四階段升級流程¶
核心知識¶
四階段升級流程¶
Control Plane 升級
- 使用 eksctl upgrade cluster 約需 7 分鐘
- 升級後**無法 rollback**，只能 Blue/Green 切換或重建 nodegroup
- 前置 pre-upgrade-check 約 3 分鐘
Add-on 升級（最多問題）
- ARM 架構（c7g.2xlarge）下，PRESERVE 模式容易 timeout（>31 分鐘）
- 腳本 timeout ≠ 升級失敗，需主動用 describe-addon 確認狀態
- Add-on 卡在 UPDATING 的根因：特定節點的 aws-node CrashLoopBackOff（grpc-health-probe :50051 gRPC 健康檢查失敗）
- coredns ContainerCreating 卡住的快速解法：cordon 問題節點 → delete stuck pod → 讓 Deployment 重新排程到健康節點，不需修好問題節點本身
- aws-ebs-csi-driver 可能意外出現 UPDATE_FAILED，需監控**所有** add-on 而非只關注目標 add-on
Node Group Rolling Upgrade
- eksctl upgrade nodegroup 在 ARM 架構下首次嘗試失敗（NodeCreationFailure）
- 改用 aws eks update-nodegroup-version API 直接觸發更透明可控
- 失敗時透過 CloudFormation stack events 查看 NodeCreationFailure 根因
- 用 ASG activities 監控新節點是否成功 Launching
- CrashLoopBackOff 的問題節點在 rolling upgrade 過程中**自然被替換終止**，可不急於修復
整體時間預估（ARM 叢集）¶
經驗教訓¶
-
ARM 架構（c7g.2xlarge）升級 Add-on 時，直接使用 OVERWRITE 而非 PRESERVE，避免 >31 分鐘 timeout
-
Add-on 卡住時第一步查 aws-node DaemonSet：kubectl get pods -n kube-system -l k8s-app=aws-node -o wide，½ Ready 表示 CNI gRPC 問題
-
coredns 卡在 ContainerCreating 不用修問題節點，直接 delete pod 讓 Deployment 重新排程更快
-
Node Group 升級優先用 aws eks update-nodegroup-version API，比 eksctl 更直接透明
-
Control Plane 升級後不可 rollback，升級前務必完成 pre-upgrade-check
常見陷阱¶
-
腳本 timeout 不等於升級失敗，需主動 describe-addon 確認狀態
-
只監控目標 add-on 不夠，aws-ebs-csi-driver 可能意外 UPDATE_FAILED
-
PRESERVE 模式在 ARM 架構下超過 31 分鐘 timeout 是常見陷阱
-
eksctl upgrade nodegroup 在 ARM 環境不可靠，失敗時難以診斷
最佳實踐¶
-
Add-on 升級全程用 check_addon_status.sh 監控所有 add-on 狀態
-
Node Group 升級失敗查 CloudFormation stack events：--query ResourceStatus==UPDATE_FAILED
-
升級腳本 timeout 對 ARM 架構建議調整至 60-90 分鐘
-
問題節點若即將被 rolling upgrade 替換，可等自然消失而非急於修復
相關概念¶
- aws-node CNI IPAM Daemon Diagnosis
- Cluster Autoscaler ASG Tag Mechanism
- eks-add-on-management----dangling-------dangling---
- EKS Add-on Upgrade
- eks-node-group-rolling-upgrade----dangling-------dangling---
- EKS NoExecute Taint Toleration Scheduling
- eks-qa-nodegroup-debug----dangling-------dangling---
- Istio Cross-Namespace xDS Authentication
- Istio EKS ARM64 Installation
- Jenkins Pipeline Silent Failure
- Kubernetes env vs envFrom Precedence
來源 Sessions¶
| 日期 | Session | 貢獻摘要 |
|---|---|---|
| 2026-03-19 | 7f62faa7-a87f-4880-845e-714dc32b3241 | 記錄了 locust-eks（ARM 架構）從 1.32→1.33 的四階段完整升級流程與各階段踩坑 |