【Day 28】雲端託管 K8s 實戰：AWS EKS vs. GCP GKE 架構比較與架構選型

2026 iThome 鐵人賽

DAY 23

Kubernetes

18th鐵人賽

94 瀏覽

今日目標

理解從「自建 K8s（Self-Hosted / Minikube）」走向「雲端託管 K8s（Managed K8s）」的商業與維運價值。
掌握公有雲兩大龍頭：AWS EKS (Elastic Kubernetes Service) 與 GCP GKE (Google Kubernetes Engine) 的架構核心差異。
深入探討雲端原生的身分整合機制（AWS IRSA vs. GCP Workload Identity）與網路/儲存抽象。
提供企業在多雲環境下的架構選型與成本最佳化策略。

在 Day 03 中，我們學到了 Kubernetes 的大腦——Control Plane（API Server, etcd, Controller Manager, Scheduler）。

如果你在實體機或自建雲（EC2 / GCE）上自建集群：

etcd 的維護惡夢：etcd 是一個分散式強一致性資料庫，需要奇數台節點維護 Raft 共識。一旦硬碟 I/O 不足或網路抖動導致 etcd 腦裂，整個集群會瞬間癱瘓。
升級風險高：每三個月發布一次的 K8s 小版本升級，需要手動逐一升級 Control Plane 各元件，容錯率極低。
高可用性（HA）成本昂貴：為了保證高可用，光是 Control Plane 就要配置 3 到 5 台專用主機，維運人員需要 24 小時待命。

雲端託管服務（Managed Kubernetes） 徹底解決了這個問題：

AWS 與 GCP 作為雲原生領域的領頭羊，各自有著截然不同的設計哲學：

評比維度	AWS EKS	GCP GKE
誕生背景	偏向企業保守與既有 AWS 生態相容	Kubernetes 本就是 Google 內部開源，原生血統最純正
開箱即用度	較為繁瑣，需手動配置 VPC CNI、EBS CSI Driver、IAM Role 等 Add-ons	極高，預設已整合 Cloud Monitoring、Cloud Logging 與 Ingress
運行模式	Standard（自管/託管 Node Group）與 Fargate（Serverless Pod）	Standard 與 Autopilot（全託管 Serverless 模式，完全無需管 Node）
網路整合	AWS VPC CNI（Pod 直接取得真實 VPC 內部 IP）	VPC-native 集群（Pod 擁有 GCP 虛擬 VPC 次級 IP 範圍）
控制平面費用	固定約 $0.10 USD / 小時 / 集群（約 $73 USD / 月）	每個帳號享有第 1 個集群免費，後續集群約 $0.10 USD / 小時

在 K8s Pod 內部的程式碼若要讀取雲端資源（例如讀取 AWS S3 Bucket 或 GCP Cloud Storage），最危險的作法是把 AccessKey / SecretKey 寫在 Secret 裡。

現代雲端架構均採用「Pod 身分直接綁定雲端 IAM 角色」的零信任架構：

在雲端運行 Kubernetes，算力成本佔了 80% 以上。常見的三大省錢絕招包括：

最佳化策略	原理說明	節省效益
Spot 實例（競價實例）	將無狀態或具備容錯能力的 Deployment 排程到雲端釋出的閒置算力（Spot / Preemptible VM）。	最高節省 70% - 90% 算力成本
Karpenter / Cluster Autoscaler	根據 Pod 的 pending 需求，動態開關 Worker Node，避免機器空轉。	避免浪費閒置 Node
HPA + PDB (Pod Disruption Budget)	在保證高可用的前提下精準控制副本數，並確保節點退役時服務不中斷。	資源利用率最大化

選擇 AWS EKS 的時機：
- 企業既有的核心基礎設施（如 RDS、S3、DynamoDB、Redshift）已經重度綁定 AWS。
- 團隊對 AWS IAM、CloudWatch 與 VPC 架構非常熟悉。
- 需要高度客製化的網路與硬體配置（如 AWS Inferentia / Trainium AI 晶片算力群）。
選擇 GCP GKE 的時機：
- 追求極致的雲原生體驗，希望將維運負擔降到最低（強烈推薦 GKE Autopilot 模式）。
- 大量使用 BigQuery、Vertex AI 或大規模分散式機器學習運算。
- 團隊規模精簡，不想花大量時間配置複雜的底層 K8s Add-on 元件。