昨天我們聊了 Istio 與 Service Mesh 的概念，今天要回到 EKS 本身的維運工作 —— 升級。

這裡的「升級」其實分成兩個層次，很多人第一次接觸時會混在一起：

• Kubernetes 升級：跟著社群版本走，從 1.28 → 1.29 → 1.30… 直到最新的 1.32，這是我們 cluster 實際跑的 Kubernetes 版本。
• EKS 升級：比較像是 AWS 提供的 Control Plane 服務功能更新（內建功能與 API 的演進），例如 aws-auth ConfigMap → Access Entry，或後來 IRSA → Pod Identity 的改變。

兩者的出發點和影響範圍完全不同，所以必須分開理解。

Kubernetes 升級（1.28 → 1.29 實戰）

這次我們的實戰是把 cluster 從 1.28 升到 1.29。升級前要先確認幾件事：

1. 確認 Upgrade Insights

   在 AWS Console 裡檢查 Upgrade Insights，確保所有項目都 Pass。

   

2. 檢查並更新相依 Addons

   • 找出與 1.28 不相容、需要更新才能支援 1.29 的版本：VPC CNI、CoreDNS、EBS CSI driver。

   • 例如查詢 vpc-cni 可支援的版本：

     aws eks describe-addon-versions --addon-name vpc-cni --kubernetes-version 1.28 | jq -r '.addons[].addonVersions[].addonVersion'
     

3. 升級 Cluster 版本

   把 Control Plane 從 1.28 升到 1.29，驗證 Node Group 是否正常滾動升級。

實際上，從 1.28 → 1.29 的流程跑過一次後，我們對後續的升級（一直到 1.32）都會遵循相同的模式。差別只是在每個版本要檢查的 Addon 相容性不同。

👉 懶人包流程：

確認 upgrade insight 都被解決 → 升版 addons 到「當前 K8s 支援最大版」 → 升版 cluster。

EKS 升級：aws-auth ConfigMap → Access Entry

另一個不同的面向是 EKS 本身的升級。這裡說的不是 cluster 版本，而是 AWS EKS Control Plane 提供的新功能與行為改變。Control Plane 的新功能版本也會反映在 Terraform EKS module 上，因此以下談的都是針對 Terraform EKS module 的升級。

AWS 在 v20 的 EKS module 引入了 Access Entry，取代過去的 aws-auth ConfigMap。

• aws-auth ConfigMap：要新增一個 IAM Role 的存取權限，需要同時改三個地方：

  1. 在 AWS 建立 IAM Role。
  2. 修改 aws-auth ConfigMap，把 IAM Role 對應到 EKS 裡的 group。
  3. 在 Kubernetes 宣告 Role/ClusterRole，對應這個 group。

  這個流程繁瑣、容易出錯，還沒辦法透過 API 管理，更別提 CloudTrail 也無法追蹤。

• Access Entry：

  可以直接透過 AWS API 建立 Access Entry，指定 IAM principal、綁定的 policies、存取範圍（cluster 或 namespace），所有紀錄都會保存在 Control Plane。

• 直接來 Console 看會有以下的畫面：

  • 如果是在 access entry 釋出前建立的 cluster，預設會使用 ConfigMap 進行權限管理

    

  • 切換成 access entry 之後，會從 ConfigMap 自動生成 access entry 的紀錄

    

  • 建立 access entry 時，需要選擇要連接哪個 IAM principal

    

  • 還有他應該要被貼上哪些 policies，以及存取的範圍（可選全 cluster / namespaces）

    

  • Terraform 的設定方式可以參考官網的文件

這個改動的意義在於：EKS 權限管理開始原生化到 AWS API，不再完全依賴 k8s RBAC + ConfigMap，對大型團隊來說更安全、更好治理。

其他具體 Terraform module 應該要調整哪些設定，可以去看官方提供的 Upgrade from v19.x to v20.x 升級指引，同理 v20 → v21 也有對應的升級指引哦。

Pod Identity 的演進 (v20 → v21)

EKS Terraform module 現在已經到 v21，根據 release note，Pod Identity 已經成為預設的驗證方式（之前預設是 IRSA）。如果對這部分還不熟，可以回去看看我在 Day 9 提到的權限管理方式 —— IRSA 與 Pod Identity 就是這個脈絡下的不同選項。我們團隊目前還沒正式 survey v21 的改動，不過可以預期未來 Pod Identity 可能會逐步成為主流。

結語

總結一下，Kubernetes 升級和EKS 升級是兩件完全不同的事：

• Kubernetes 升級：跟著社群版本走，主要影響 Control Plane、Node Group、Addon 相容性。
• EKS 升級：AWS Control Plane 的功能演進，牽涉到 IAM、權限管理模式（Access Entry、Pod Identity）等。

如果把兩者混為一談，很容易在升級過程中忽略關鍵細節。

我的建議是：

1. 把 Kubernetes 升級流程 run 熟（Upgrade Insight → Addon → Cluster）。
2. 另外關注 AWS 帶來的 Control Plane 新功能，像 Access Entry 與 Pod Identity，提早納入團隊的規劃。

接下來就是本系列的最後一篇 —— Day 30。在這一天，我會把焦點轉回基礎建設即程式（IaC）工具選型，比較 TypeScript CDK 和 Terraform 各自的優缺點，以及我們在實務中使用的心得。

這會是本系列的收尾，也希望能幫助到同樣在雲端基礎建設上做決策的你 >.O