AWS Kubernetes 讓集群變成可管路徑

我把 AWS 的 Kubernetes 頁面拆成可執行的選型筆記：EC2、EKS、ECR 各管什麼，怎麼分責任，最後附可直接貼進設計稿的模板。

我用 Kubernetes 在 AWS 上跑過一陣子了。模型沒有問題，工具也都接上了，但總覺得哪裡卡卡的。很多平台頁面都寫得像在安撫人：你只要把容器丟上去，剩下交給雲端。聽起來很順，真的上線就知道不是這回事。你要管的是誰負責控制平面、誰顧節點、誰處理映像、誰扛 DNS 跟流量，還有半夜出事時到底是誰先醒來。我看 AWS 這頁的時候，最有感的不是它講了什麼，而是它終於把責任邊界講得夠清楚，至少沒假裝 Kubernetes 會自己變簡單。

我這次拆的是 AWS 的 Kubernetes on AWS 頁面。它沒有給我什麼神奇數字，也沒塞一堆空話，反而是很老實地把 EC2、EKS、ECR 這幾個東西擺在同一張圖上。這種頁面真正的價值，不是教你「什麼是 Kubernetes」，而是讓你看懂 AWS 想把哪一段麻煩收走、哪一段還是你自己扛。旁邊我也會一起對照 Amazon EKS、Amazon EC2、Amazon ECR 跟官方 Kubernetes components 文件。

先別把 Kubernetes on AWS 當成一個產品

“You can choose to manage Kubernetes infrastructure yourself with Amazon EC2 or get an automatically provisioned, managed Kubernetes control plane with Amazon EKS.”

翻譯一下就是：AWS 不是在賣你一個單一答案，它是在給你一條分岔路。左邊是你自己管，右邊是 AWS 幫你把控制平面收掉。這差很多，真的差很多。很多團隊會把「上了雲」誤認成「少做事」，結果最後還是每天在處理同一堆 cluster 雜務，只是票單從 on-prem 換成雲端而已。

我以前也踩過這個洞。以為只要用了 Kubernetes，就能把部署、擴縮、容錯都交給系統，結果實際上只是把複雜度從應用層搬到平台層。AWS 這頁最值得看的地方，就是它沒有騙你。它直接告訴你，EC2 路線是你自己管理 Kubernetes 基礎設施；EKS 路線則是把 managed control plane 交給 AWS。也就是說，你不是在選「能不能用 Kubernetes」，你是在選「哪些麻煩要留在自己手上」。

實操上，我會先寫責任分工，不會先開 Terraform。因為如果團隊連誰管升級、誰管節點、誰管映像都講不清楚，後面所有架構圖都只是裝飾。這件事我看過太多次：圖畫得很漂亮，incident 來的時候每個人都說自己只負責一半。

• 想要完全掌控，選 EC2，但要接受更多運維工作。
• 想把控制平面從日常雜務裡拿掉，選 EKS。
• 映像儲存和發佈要一起想，直接把 ECR 納進流程。

Pod 才是 Kubernetes 真正在意的單位

“Containers are run in logical groupings called pods and you can run and scale one or many containers together as a pod.”

翻譯一下就是：Kubernetes 不是先想「一個 container」，它先想「一組一起活、一起死的東西」。這是很多人一開始最容易誤解的地方。你如果只把 pod 當成容器外面的殼，後面一定會卡。因為真實世界裡，應用程式旁邊常常還有 sidecar、log collector、proxy、metrics exporter，這些東西不是裝飾品，是要一起共存的。

我之前就犯過這個錯。那時候我把 pod 想成「一個 app 放一個 container」的簡單映射，結果一旦要加共用網路、共用 storage、或是要讓輔助程序跟主程序共享生命週期，整個模型就開始漏水。AWS 頁面講得很白：一個 pod 可以跑一個或多個 container，而且 Kubernetes 會用 pod 這個單位來排程與重啟。也就是說，你真正要設計的不是某個 binary，而是它的 runtime 邊界。

實操上，我會先決定每個 workload 是單容器 pod 還是多容器 pod。要不要 sidecar，不是看潮不潮，是看它們是不是必須共享網路命名空間、生命週期、或本地通訊。如果要，就老實把它們收進同一個 pod；如果不要，就別硬湊，免得未來 debug 時自己打自己臉。

• 單容器 pod 適合簡單、獨立、沒有額外輔助程序的服務。
• 多容器 pod 適合要共享生命週期或本地通訊的工作負載。
• 不要因為「Kubernetes 就該這樣」而用 pod，先看需求再決定。

控制平面是你最晚看到、但最先出事的地方

“Kubernetes control plane software decides when and where to run your pods, manages traffic routing, and scales your pods based on utilization or other metrics that you define.”

翻譯一下就是：控制平面不是跑你業務邏輯的地方，但它決定你的業務邏輯能不能正常活著。這個東西平常存在感很低，一出事就會讓整個 cluster 像中邪。排程卡住、API 慢、deployment 卡在半路、autoscaling 沒反應，最後你會發現不是 app 壞，是那個「決定 app 何時能跑」的腦袋在抽風。

AWS 的頁面其實有把這件事講清楚。它把 cluster 分成 control plane 跟 data plane，前者管排程、API、流量路由與擴縮，後者才是 workload 真正落地的地方。這個切法很重要，因為它直接影響你要不要自己扛 master instances、etcd、升級節奏、健康檢查。我看過很多團隊把注意力全放在節點規格，結果控制平面一出問題，整個系統就像少了方向盤。

實操上，我會把 control plane ownership 寫進架構文件。用 EKS 的話，就明確列出 AWS 管什麼、我自己管什麼；用 EC2 的話，就把升級、備份、API 可用性檢查、故障切換寫死。不要模糊。模糊最貴，尤其是在 Kubernetes 上。

如果你想對照更底層的概念，我會直接看官方 Kubernetes components。AWS 的頁面是導覽，Kubernetes 官方文件才是機械結構圖。

EC2 給你控制，也順便把瑣事一起塞回來

“Consider using Amazon EC2 if you want to fully manage your Kubernetes deployment.”

翻譯一下就是：你要的是完全控制，那就別幻想會比較輕鬆。EC2 路線的好處很直接，你可以自己挑 instance family、自己控節點行為、自己決定怎麼做 scaling 跟 patching。壞處也很直接，這些事大多數都得你自己做。AWS 沒有在這裡包裝成什麼輕盈的體驗，它只是很誠實地說，這條路就是 fully manage。

我不是反對控制。某些情境你真的需要它，例如特殊網路需求、合規限制、或你們平台團隊本來就很成熟，已經有能力把節點層玩得很細。這時候 EC2 不是退而求其次，而是刻意選擇。但如果你的理由只是「我們想比較專業」，那我會直接勸你停一下。專業不是自己多養幾台機器，專業是知道哪裡值得自己管，哪裡不值得。

實操上，我會把 EC2-based Kubernetes 留給需要特殊 node 行為、特殊網路拓撲、或要深度掌握平台細節的團隊。其他情況，我不會先選它。因為我很清楚，所謂的自由，最後常常只是更多 on-call。

• 適合：有明確客製化基礎設施需求。
• 適合：平台團隊成熟，能承接更多運維責任。
• 不適合：想把維運面積縮到最小的應用團隊。

EKS 的價值不是省錢，是把麻煩收斂到你看得懂的地方

“Amazon EKS is a certified conformant, managed Kubernetes service.”

翻譯一下就是：AWS 不是做一個像 Kubernetes 的東西，它是說自己跟 upstream 相容，而且把 control plane 這段收走。這點我很在意。因為我不想用一個 managed service，結果它的行為像 Kubernetes，但只有在文件寫得很漂亮的時候才像。

AWS 還特別提到，EKS 不需要你自己 provision 或管理 master instances 和 etcd。這句很直白，但我覺得它是整頁最有分量的一句。因為 master 跟 etcd 就是那種「重要但不該成為你每天主要工作」的東西。你當然要理解它們，但不一定要親手養它們。這就是 managed service 的價值：不是幫你變強，而是幫你少碰那些不該天天碰的部分。

實操上，我幾乎會先預設 EKS，除非有很具體的理由不選。理由要能寫進文件，不是寫在 Slack 裡的感覺。像是合規、特殊節點控制、或某些平台限制，這些都算理由；「我們比較喜歡自己弄」不算。這種偏好通常會在第三次升級事故後被現實修理。

如果你要看服務本體，我會直接從 Amazon EKS 產品頁接下去。那裡才是 managed service 細節的主場。

真正麻煩的是網路、身份、映像和服務發現

“AWS makes it easy to run Kubernetes in the cloud with scalable and highly available virtual machine infrastructure, community-backed service integrations, and Amazon Elastic Kubernetes Service (EKS).”

翻譯一下就是：AWS 想賣你的不只是算力，而是整套周邊。因為 Kubernetes 真正讓人煩的從來不是「能不能跑」，而是跑起來之後怎麼讓別的東西找得到它、怎麼安全地拉映像、怎麼把流量導進來、怎麼把權限切清楚。

這就是我覺得 AWS 頁面還算老實的地方。它有提到 VPC、IAM、service discovery、ECR 這些東西，因為這些才是 production 會出事的地方。很多人一開始只盯著 nodes 跟 pods，等真的上線才發現，最麻煩的其實是 glue layer。不是容器本身難，是容器跟周邊系統怎麼接，這件事最容易爛掉。

實操上，我會把 Amazon VPC、AWS IAM、Amazon ECR 一起納進設計，而不是一個一個補。DNS 和 service discovery 也要早點處理，不要等到上線後才開始用 annotation 補洞。那種補法很常見，也很常死得很慢。

• VPC 管住網路邊界。
• IAM 管住身份與權限。
• ECR 管住映像儲存與發佈。

生態系不是加分題，是你能不能少重造輪子的差別

“A large community of developers and companies build extensions, integrations, and plugins that help Kubernetes users do more.”

翻譯一下就是：Kubernetes 本體只是底座，真正讓它能用的是周邊生態。AWS 這頁提到的那些工具我不覺得是湊數，反而很像在講真話：你不會只用 Kubernetes，你一定會接 ingress、DNS、node provisioning、manifest 管理，甚至是特定工作負載的 controller。

我比較喜歡這段，因為它沒有假裝平台可以包山包海。它直接承認你還是需要工具鏈，只是 AWS 幫你挑了一些跟它家雲環境比較合拍的選項。像 AWS Load Balancer Controller、ExternalDNS、Karpenter、cdk8s，這些都不是裝飾，是把 cluster 變成可操作平台的拼圖。

實操上，我會故意少選工具。不是越多越好，真的不是。Ingress 一套、DNS 一套、節點自動化一套、manifest 管理一套，先這樣就夠了。你如果把每個需求都交給不同插件，最後不是平台變強，是平台變得沒人敢動。

如果你的工作負載是 ML 或模型服務，AWS 還提到 TorchServe。這表示它不是只在講 web service，而是在講容器化工作負載的整體路徑。這點我認同，因為 Kubernetes 真正有用的地方，本來就不是某一種 app，而是那套跑法。

可抄的模板

# Kubernetes on AWS 選型筆記模板

## 我到底要跑什麼
- Workload 類型：
- 流量型態：
- 是否有 stateful 元件：
- 合規 / 隔離需求：

## 控制平面怎麼選
- [ ] EKS
- [ ] EC2 自管 Kubernetes

### 我這樣選的理由
- 如果選 EKS：我希望 AWS 幫我管 control plane 與 etcd。
- 如果選 EC2：我需要完全掌控 cluster 管理與 node 行為。

## Data plane 怎麼做
- Instance family：
- Node group 策略：
- Autoscaling 方案：
- 升級責任：

## Pod 要怎麼切
- 這個 workload 是單容器 pod 還是多容器 pod：
- 需要哪些 sidecar：
- 是否需要共享 storage：
- 是否依賴 localhost 通訊：

## 網路與身份
- VPC 規劃：
- Ingress 策略：
- DNS / service discovery：
- IAM role mapping：

## 映像流程
- Registry：Amazon ECR
- Build pipeline：
- Promotion path：
- Rollback 方式：

## 我允許的 Kubernetes 擴充
- [ ] AWS Load Balancer Controller
- [ ] ExternalDNS
- [ ] Karpenter
- [ ] cdk8s
- [ ] 其他：

## 運維責任
- 誰 patch nodes？
- 誰升級 Kubernetes？
- 誰看 control plane health？
- 誰處理 incident？

## 重新評估條件
我會重看這份設計，如果：
- control plane 負擔變太重
- node 管理太手工
- service discovery 開始脆弱
- 團隊講不清楚部署路徑

我這篇的拆解是從 AWS 的 Kubernetes on AWS 頁面出發，原始架構與產品分工是 AWS 提供的；上面這份責任切法、判斷方式與可抄模板，是我把它翻成台灣開發者比較好直接拿去用的版本。