GKE、EKS、AKS 怎麼選?比較日常維運責任
GKE、EKS、AKS 都提供受管 Kubernetes 控制平面,真正拉開差距的是周邊責任:節點由誰管理、網路如何分配 IP、升級如何排程、身分如何接上既有環境,以及團隊願意承擔多少維運工作。
這篇文章以同層級的模式比較:GKE Autopilot、EKS Auto Mode、AKS Automatic,再對照各平台可深度自訂的標準模式。你將得到:
- 三大平台的責任邊界與核心整合差異
- 版本升級、網路、安全與可觀測性的比較方式
- 不依賴固定月費的總成本模型
- 一套從硬性需求到 PoC 的選型決策流程

GKE、EKS、AKS 的 Kubernetes 核心相同,差異主要長在外圍:GKE 偏自動化與 Google Cloud 整合;EKS 連到 AWS 的服務與網路模型;AKS 擅長 Microsoft 身分、Windows 與 Azure 整合。選型時先比較責任與既有環境,不要只數功能勾勾。
一、為什麼平台選型會影響 Day 2?
能建立叢集只是 Day 1。平台差異通常在升級、IP 容量、身分、監控與成本分攤開始放大;若沒有先把這些條件寫清楚,同一個 Kubernetes API 仍可能帶來完全不同的營運負擔。
流程圖暫時無法顯示。可先查看下方的流程與節點文字,或重新整理頁面後再試。
查看流程與節點文字
箭頭表示流程方向;方括號與引號內是節點名稱,可搭配下方圖解閱讀。
flowchart TB
A[選型前假設] --> B{有沒有用 PoC 驗證?}
B -- 沒有 --> C1[既有 IAM、<br/>網路與資料<br/>整合成本被低估]
B -- 沒有 --> C2[Pod、節點<br/>與升級 surge<br/>IP 容量被低估]
B -- 沒有 --> C3[節點、<br/>附加元件與政策<br/>責任邊界不清]
C1 --> D[故障排除時間增加]
C2 --> D
C3 --> D
D --> E[SLO、交付速度<br/>與總成本受影響]
B -- 有 --> F[用相同工作負載<br/>量測與記錄證據]
F --> G[依證據選模式與平台]
classDef decision fill:#fef3c7,stroke:#d97706,color:#78350f
classDef risk fill:#fee2e2,stroke:#dc2626,color:#7f1d1d
classDef outcome fill:#f3e8ff,stroke:#9333ea,color:#581c87
classDef good fill:#dcfce7,stroke:#16a34a,color:#14532d
class B decision
class C1,C2,C3,D,E risk
class F,G good 三大平台的定位
| 平台 | 優先評估的既有條件 | 可降低維運責任的模式 | 需要深度控制的模式 |
|---|---|---|---|
| GKE | Google Cloud IAM、VPC、資料與 AI 服務 | Autopilot | Standard |
| EKS | AWS IAM、VPC、EC2、ELB 與既有 AWS 平台工程 | Auto Mode | 標準 EKS + Managed/自管節點 |
| AKS | Microsoft Entra ID、Azure 網路、Azure Monitor、Windows | Automatic | Standard |
表格超出欄寬時,可左右捲動;鍵盤可聚焦表格後用左右方向鍵查看。
Fargate 與 AKS Virtual Nodes 仍各有用途,但它們不是完整接管叢集基礎設施的對等方案,因此本文不再拿它們和 Autopilot 做主比較。
二、先比較共同責任

三個平台都託管控制平面,但不會接管應用、政策與資料。節點、升級與附加元件由誰負責,會隨 Autopilot、Auto Mode、Automatic 或 Standard 改變。
流程圖暫時無法顯示。可先查看下方的流程與節點文字,或重新整理頁面後再試。
查看流程與節點文字
箭頭表示流程方向;方括號與引號內是節點名稱,可搭配下方圖解閱讀。
flowchart TB
subgraph PROVIDER[雲端供應商]
CP[控制平面可用性與修補]
NODE[自動化模式的節點生命週期]
CORE[模式涵蓋的核心網路、儲存與負載平衡元件]
end
subgraph PLATFORM[平台團隊]
CFG[叢集與網路設定]
POLICY[IAM、准入、網路與成本政策]
OBS[可觀測性、事件回應與容量規劃]
end
subgraph APP[應用團隊]
IMAGE[映像檔與供應鏈]
WORKLOAD[Deployment、PDB、requests 與 autoscaling]
DATA[資料保護、備份、SLO 與復原]
end
CP --> CFG
NODE --> OBS
CORE --> POLICY
CFG --> WORKLOAD
POLICY --> IMAGE
OBS --> DATA
classDef provider fill:#dbeafe,stroke:#2563eb,color:#1e3a8a
classDef platform fill:#fef3c7,stroke:#d97706,color:#78350f
classDef app fill:#dcfce7,stroke:#16a34a,color:#14532d
class CP,NODE,CORE provider
class CFG,POLICY,OBS platform
class IMAGE,WORKLOAD,DATA app 「不用管節點」不等於「不用營運 Kubernetes」。Pod Disruption Budget、資源請求、網路政策、祕密、備份與應用 SLO,仍然是使用者責任。
三、三個平台的現在式
GKE:Autopilot 與 Standard
GKE Autopilot 由 Google 管理節點佈建、擴縮、作業系統與多項安全預設;Standard 則讓團隊直接選擇節點池、映像檔與更多底層設定。一般用途 Autopilot 工作負載多以 Pod 資源請求計費,指定特定硬體或部分運算類別時可能改採節點型計費。
gcloud container clusters create-auto my-cluster \
--region=asia-east1 \
--release-channel=regular
Autopilot 有平台 guardrail、資源請求預設與工作負載限制;這些規則會演進,評估特權、host access、第三方 agent 或特殊硬體前,應查閱最新的 Autopilot limitations,而不是沿用固定清單。
EKS:Auto Mode 與標準 EKS
EKS Auto Mode 把管理範圍擴展到運算自動擴縮、Pod 網路、NetworkPolicy、負載平衡與 EBS 儲存元件。Auto Mode 節點採受管且限制直接存取的生命週期;團隊仍掌握 VPC、叢集設定、NodePool/NodeClass 與應用。
標準 EKS 可以搭配 Managed Node Groups、自管節點或 Fargate。Fargate 適合特定 Pod 執行場景,但 DaemonSet、部分儲存與硬體需求須逐項檢查,不應視為 Auto Mode 的同義詞。
eksctl create cluster \
--name my-cluster \
--region ap-northeast-1 \
--nodegroup-name standard-workers \
--node-type m7i.large \
--nodes 3
AKS:Automatic 與 Standard
AKS Automatic 提供預設啟用的節點自動佈建、安全、監控與升級設定;AKS Standard 則保留完整節點池、網路與升級控制。需要 Windows node pool、特定 VM SKU 或既有客製自動化時,要先檢查 Automatic 的功能對照,必要時改用 Standard。
az aks create \
--resource-group myResourceGroup \
--name myAKSCluster \
--node-count 3 \
--enable-managed-identity \
--generate-ssh-keys
AKS 支援 Windows Server 容器,但「支援 Windows」不代表任何 .NET 工作負載都應直接選 AKS。還要比較映像檔相容性、節點池限制、授權、團隊技能與資料所在位置。
四、六個技術面向怎麼比?
1. 代管程度:先比模式,不要只比品牌
| 面向 | GKE Autopilot | EKS Auto Mode | AKS Automatic |
|---|---|---|---|
| 節點佈建與縮放 | 平台管理 | 平台管理,使用 Karpenter 能力 | 平台管理,使用 node auto-provisioning |
| 節點 OS 與修補 | 平台管理 | 平台管理,受管節點有固定生命週期上限 | 平台管理 |
| 核心元件 | 依 Autopilot 能力與設定 | 網路、負載平衡、DNS、EBS 等由 Auto Mode 納管 | 安全、監控、Ingress、升級等有預設組合 |
| 底層自訂 | 受 guardrail 限制 | 以 NodePool/NodeClass 調整,節點不可直接登入 | 受 Automatic 支援矩陣限制 |
| 使用者仍負責 | 工作負載、政策、資料、SLO | 工作負載、VPC 與叢集設定、資料、SLO | 工作負載、政策、資料、SLO |
表格超出欄寬時,可左右捲動;鍵盤可聚焦表格後用左右方向鍵查看。
若平台 guardrail 阻擋必要的 kernel、agent、網路或硬體設定,就改評估標準模式,不要先選品牌再硬套工作負載。
2. 升級:比較可預測性與應用韌性
GKE 有 Rapid、Regular、Stable 與 Extended release channels;Regular 是預設且適合多數使用者。所有 channel 都會自動升級,差別在版本進入的節奏。Extended 提供較長支援週期,但有適用限制與延長支援費用,且不適用 Autopilot。
流程圖暫時無法顯示。可先查看下方的流程與節點文字,或重新整理頁面後再試。
查看流程與節點文字
箭頭表示流程方向;方括號與引號內是節點名稱,可搭配下方圖解閱讀。
flowchart LR UP[上游 Kubernetes 版本] --> RAPID[Rapid<br/>約 1–2 週後可用] RAPID --> REGULAR[Regular<br/>約再 2 個月] REGULAR --> STABLE[Stable<br/>約再 3–4 個月] REGULAR -. 同步進版、延長支援 .-> EXT[Extended<br/>最長約 24 個月] RAPID --> PRE[開發與前置驗證] REGULAR --> PROD[多數生產工作負載] STABLE --> CONS[較保守的採用節奏] EXT --> LONG[有較長升級週期的 Standard 叢集] classDef channel fill:#dbeafe,stroke:#2563eb,color:#1e3a8a classDef use fill:#dcfce7,stroke:#16a34a,color:#14532d class RAPID,REGULAR,STABLE,EXT channel class PRE,PROD,CONS,LONG use
EKS Auto Mode 與 AKS Automatic 也自動化更多升級工作;標準模式則提供更多手動或 channel 設定。無論哪個平台,升級前仍要驗證 deprecated API、PDB、replica、quota、子網容量與 surge 行為。
3. 網路:IP 模型比 CNI 名稱更重要
| 面向 | GKE | EKS | AKS |
|---|---|---|---|
| 主要網路路徑 | VPC-native;Dataplane V2 可提供 Cilium/eBPF data plane | Amazon VPC CNI;Pod 通常取得 VPC 位址 | Azure CNI Overlay 為未指定 plugin 時的預設;也可選 flat networking |
| NetworkPolicy | Dataplane V2 可執行政策 | VPC CNI 支援原生 NetworkPolicy,但須用支援版本並啟用 | 可依模式使用 Cilium、Azure 或 Calico 能力 |
| 身分整合 | Workload Identity Federation for GKE | EKS Pod Identity 或 IRSA | Microsoft Entra Workload ID |
| 負載平衡 | Google Cloud Load Balancing 整合 | AWS Load Balancer Controller 或 Auto Mode 整合 | Application Routing、Application Gateway 等路徑 |
表格超出欄寬時,可左右捲動;鍵盤可聚焦表格後用左右方向鍵查看。
EKS 不再需要一律安裝 Calico 才能執行 NetworkPolicy;VPC CNI 已支援這項能力,但 Fargate、Windows、獨立 Pod 與額外網卡等情況仍有官方限制。
流程圖暫時無法顯示。可先查看下方的流程與節點文字,或重新整理頁面後再試。
查看流程與節點文字
箭頭表示流程方向;方括號與引號內是節點名稱,可搭配下方圖解閱讀。
flowchart TB
subgraph ADDRESS[位址空間]
direction TB
CIDR[VPC/VNet CIDR] --> SUBNET[節點與 Pod 子網]
end
subgraph ALLOCATION[分配模型]
direction TB
CNI{CNI/IPAM} --> FLAT[Flat:雲端網路 IP]
CNI --> OVERLAY[Overlay:獨立 Pod CIDR]
FLAT --> USE[節點、Pod、<br/>warm pool 與 surge]
OVERLAY --> USE
end
subgraph VALIDATION[容量驗證]
direction TB
CHECK{峰值有安全餘裕?}
CHECK -- 否 --> FIX[擴子網/調 IPAM/<br/>評估 overlay]
FIX --> CHECK
CHECK -- 是 --> TEST[擴縮與升級演練]
end
SUBNET --> CNI
USE --> CHECK
classDef source fill:#dbeafe,stroke:#2563eb,color:#1e3a8a
classDef decision fill:#fef3c7,stroke:#d97706,color:#78350f
classDef action fill:#dcfce7,stroke:#16a34a,color:#14532d
class CIDR,SUBNET,FLAT,OVERLAY,USE source
class CNI,CHECK decision
class FIX,TEST action 不要用單一 VM 規格與 CIDR 做跨平台結論。PoC 應以實際 instance/VM、maxPods、升級 surge、prefix delegation 或 overlay 設定重新計算。
4. 安全:看完整控制鏈,不只看單一產品
| 控制層 | GKE | EKS | AKS |
|---|---|---|---|
| 工作負載身分 | Workload Identity Federation | Pod Identity/IRSA | Entra Workload ID |
| 映像檔與弱點 | Artifact Analysis、Binary Authorization | ECR scanning、准入政策工具 | Defender for Containers、deployment safeguards/政策 |
| 網路隔離 | VPC firewall、NetworkPolicy、Service Controls 等 | security groups、NetworkPolicy、VPC controls | NSG、NetworkPolicy、Private Link 等 |
| 政策治理 | Policy Controller/Gatekeeper | Kubernetes 准入工具與 AWS 控制 | Azure Policy/deployment safeguards |
| 稽核與偵測 | Cloud Audit Logs、Security Command Center | CloudTrail、GuardDuty 等 | Azure Monitor、Defender for Cloud 等 |
表格超出欄寬時,可左右捲動;鍵盤可聚焦表格後用左右方向鍵查看。
Binary Authorization 可以在部署時要求映像檔或 attestation 符合政策,但有權限的管理者仍能修改政策,組織也可設計 breakglass。它是控制鏈的一環,不是「永遠無法繞過」的保證。
流程圖暫時無法顯示。可先查看下方的流程與節點文字,或重新整理頁面後再試。
查看流程與節點文字
箭頭表示流程方向;方括號與引號內是節點名稱,可搭配下方圖解閱讀。
flowchart TB
subgraph BUILD_LANE[建置與簽署]
direction TB
CODE[程式碼] --> BUILD[CI 建置]
BUILD --> TEST[測試與弱點掃描]
TEST --> SIGN[簽章或 Attestation]
end
subgraph ADMISSION[Registry 與准入]
direction TB
REG[Artifact Registry/<br/>ECR/ACR] --> DEPLOY[部署請求]
DEPLOY --> POLICY{政策通過?}
BREAK[受控 Breakglass] -. 限時且可追蹤 .-> POLICY
end
subgraph OUTCOME[部署結果]
direction TB
RUN[建立工作負載] --> MON[執行期監控]
DENY[拒絕並記錄]
end
SIGN --> REG
POLICY -- 是 --> RUN
POLICY -- 否 --> DENY
classDef build fill:#dbeafe,stroke:#2563eb,color:#1e3a8a
classDef decision fill:#fef3c7,stroke:#d97706,color:#78350f
classDef good fill:#dcfce7,stroke:#16a34a,color:#14532d
classDef bad fill:#fee2e2,stroke:#dc2626,color:#7f1d1d
class CODE,BUILD,TEST,SIGN,REG,DEPLOY build
class POLICY decision
class RUN,MON good
class DENY,BREAK bad 5. 可觀測性:三家都有受管工具,差別在預設與治理
三家都能收集 Kubernetes metrics、logs 與 traces,也都能接 Prometheus/OpenTelemetry。不要用「建立叢集就全部完成」或「一定要手裝六個 agent」做靜態比較;實際步驟取決於建立模式、預設設定、留存需求與成本政策。
流程圖暫時無法顯示。可先查看下方的流程與節點文字,或重新整理頁面後再試。
查看流程與節點文字
箭頭表示流程方向;方括號與引號內是節點名稱,可搭配下方圖解閱讀。
flowchart TB APP[應用與 Kubernetes] --> METRIC[Metrics] APP --> LOG[Logs] APP --> TRACE[Traces] APP --> EVENT[Events] METRIC --> COLLECT[平台整合或 OpenTelemetry Collector] LOG --> COLLECT TRACE --> COLLECT EVENT --> COLLECT COLLECT --> BACKEND[Cloud Monitoring/<br/>CloudWatch/<br/>Azure Monitor] BACKEND --> DASH[Dashboard] BACKEND --> ALERT[告警與 SLO] BACKEND --> IR[事件回應] BACKEND --> COST[留存、採樣<br/>與成本治理] classDef signal fill:#dbeafe,stroke:#2563eb,color:#1e3a8a classDef platform fill:#f3e8ff,stroke:#9333ea,color:#581c87 classDef outcome fill:#dcfce7,stroke:#16a34a,color:#14532d class METRIC,LOG,TRACE,EVENT signal class COLLECT,BACKEND platform class DASH,ALERT,IR,COST outcome
PoC 至少要驗證:控制平面稽核日誌、容器 stdout/stderr、節點與 Pod 指標、應用 trace、告警路由、資料遮罩、留存天數與每 GB 成本。
6. 成本:固定單價只能當查核點
截至 2026-08-04,官方頁面的關鍵差異是:
- GKE:所有叢集都有每小時叢集管理費;每個帳單帳戶的月度 credit 只適用於 zonal Standard 與 Autopilot,不適用 regional Standard。
- EKS:標準 Kubernetes 版本支援期以每叢集每小時計費;進入 extended support 後費率顯著提高,因此升級延遲本身就是成本。
- AKS:Free tier 沒有財務保證的 SLA;Standard 提供 SLA;Premium 加上 LTS。Automatic 有自己的 hosted component 與運算計費模型。
官方入口:GKE Pricing、EKS Pricing、AKS Pricing。實際金額會受區域、合約、折扣、版本與工作負載模式影響,應以 calculator 或帳單匯出重算。
流程圖暫時無法顯示。可先查看下方的流程與節點文字,或重新整理頁面後再試。
查看流程與節點文字
箭頭表示流程方向;方括號與引號內是節點名稱,可搭配下方圖解閱讀。
flowchart LR
TCO[每月總成本]
subgraph BILLED[帳單與資源成本]
BILL[雲端帳單] --> FIXED[叢集/控制平面]
BILL --> COMPUTE[Pod requests<br/>或節點運算]
BILL --> DATA[儲存、快照與備份]
BILL --> NETWORK[負載平衡、<br/>NAT、IP 與出站]
COMPUTE --> WASTE[閒置、<br/>DaemonSet、<br/>surge 與碎片]
end
subgraph OPERATIONS[營運與生命週期成本]
HUMAN[營運成本] --> OBS[觀測資料與留存]
HUMAN --> OPS[升級、安全<br/>與事件處理]
HUMAN --> SUPPORT[支援與延長版本支援]
OPS --> PEOPLE[人力與交付延遲]
end
TCO --> BILL
TCO --> HUMAN
classDef total fill:#f3e8ff,stroke:#9333ea,color:#581c87
classDef cost fill:#dbeafe,stroke:#2563eb,color:#1e3a8a
classDef hiddenCost fill:#fef3c7,stroke:#d97706,color:#78350f
class TCO total
class BILL,HUMAN,FIXED,COMPUTE,DATA,NETWORK,OBS,OPS,SUPPORT cost
class WASTE,PEOPLE hiddenCost 不要直接拿三個不同 VM 系列的牌價相加比較。先固定 vCPU、記憶體、架構、磁碟、可用區、折扣與 SLO,再加上相同的流量與留存假設。
五、多叢集、混合雲與生態系
GKE fleet 管理、Amazon EKS 的混合/地端選項與 Azure Arc/Fleet Manager 解決的範圍並不完全相同。比較時要拆成註冊與盤點、設定同步、政策、服務連線、升級、身分、可觀測性與支援責任。
流程圖暫時無法顯示。可先查看下方的流程與節點文字,或重新整理頁面後再試。
查看流程與節點文字
箭頭表示流程方向;方括號與引號內是節點名稱,可搭配下方圖解閱讀。
flowchart TB GIT[Git/IaC/應用設定] --> MGMT[多叢集管理層] ID[企業身分與金鑰] --> MGMT POLICY[組織政策與合規基線] --> MGMT MGMT --> INV[註冊與盤點] MGMT --> SYNC[設定同步] MGMT --> GOV[政策與稽核] MGMT --> OBS[集中可觀測性] MGMT --> UPGRADE[版本與生命週期] INV --> C1[雲端叢集 A] SYNC --> C2[雲端叢集 B] GOV --> C3[地端/邊緣叢集] OBS --> C1 OBS --> C2 OBS --> C3 UPGRADE --> C1 UPGRADE --> C2 UPGRADE --> C3 classDef input fill:#dbeafe,stroke:#2563eb,color:#1e3a8a classDef mgmt fill:#f3e8ff,stroke:#9333ea,color:#581c87 classDef capability fill:#fef3c7,stroke:#d97706,color:#78350f classDef cluster fill:#dcfce7,stroke:#16a34a,color:#14532d class GIT,ID,POLICY input class MGMT mgmt class INV,SYNC,GOV,OBS,UPGRADE capability class C1,C2,C3 cluster
生態系的差異在 Kubernetes 外圍
| 面向 | GKE | EKS | AKS |
|---|---|---|---|
| 資料與 AI 鄰接 | BigQuery、Spanner、Gemini Enterprise Agent Platform(原 Vertex AI) | RDS、DynamoDB、SageMaker 等 | Azure SQL、Cosmos DB、Azure AI 等 |
| CI/CD | Cloud Build、Cloud Deploy 與第三方工具 | CodePipeline、CodeBuild、GitHub Actions 與第三方工具 | Azure DevOps、GitHub Actions 與第三方工具 |
| Registry | Artifact Registry | ECR | ACR |
| 企業身分 | Cloud Identity/Google Cloud IAM | AWS IAM/IAM Identity Center | Microsoft Entra ID |
| GitOps/政策 | Config Sync、Policy Controller 或第三方工具 | Argo CD、Flux、Gatekeeper、Kyverno 等 | Flux、Azure Policy 或第三方工具 |
表格超出欄寬時,可左右捲動;鍵盤可聚焦表格後用左右方向鍵查看。
若資料庫、訊息、身分與可觀測性都已在同一朵雲,優先評估同雲平台通常能減少跨雲網路與權限整合。但「資料在哪裡」只是起點,仍要檢查硬性需求與退出成本。
Config Sync 範例
若選擇 GKE,可用 Config Sync 將 Git 設定同步到 fleet 裡的叢集;官方在 2025-09-02 宣布 Config Sync 併入標準 GKE、不另外收費,不必再啟用 GKE Enterprise。其他平台也可使用 Flux、Argo CD 等工具建立類似流程。
apiVersion: configsync.gke.io/v1beta1
kind: RootSync
metadata:
name: root-sync
namespace: config-management-system
spec:
sourceFormat: unstructured
git:
repo: https://github.com/my-org/k8s-config
branch: main
dir: clusters/production
auth: gcpserviceaccount
gcpServiceAccountEmail: config-sync@my-project.iam.gserviceaccount.com
六、選型決策框架

沒有脫離情境的單一贏家。先用既有雲端投資、團隊技能、身分網路整合、營運自動化與混合雲需求縮小範圍,再用同一套工作負載、SLO、安全基線與成本假設做 PoC。
流程圖暫時無法顯示。可先查看下方的流程與節點文字,或重新整理頁面後再試。
查看流程與節點文字
箭頭表示流程方向;方括號與引號內是節點名稱,可搭配下方圖解閱讀。
flowchart TB
subgraph REQUIREMENTS[硬性需求與既有環境]
direction TB
A[開始選型] --> B{有硬性需求?}
B -- Windows node pool --> AKSC[納入 AKS Standard]
B -- 硬體/網路/區域 --> MATRIX[核對支援矩陣]
B -- 沒有 --> C{集中在單一雲?}
AKSC --> C
MATRIX --> C
end
subgraph MODE[營運模式]
direction TB
C -- 是 --> SAME[先評估同雲平台]
C -- 否或多雲 --> D{希望平台管理節點?}
D -- 是 --> AUTO[比較自動化模式]
D -- 否 --> STANDARD[比較標準模式]
end
subgraph VALIDATE[PoC 與決策]
direction TB
SHORT[保留 1–2 個候選] --> POC[相同工作負載與 SLO]
POC --> E{量測達標?}
E -- 否 --> SHORT
E -- 是 --> DECIDE[記錄 ADR 與退出計畫]
end
SAME --> SHORT
AUTO --> SHORT
STANDARD --> SHORT
classDef decision fill:#fef3c7,stroke:#d97706,color:#78350f
classDef candidate fill:#dbeafe,stroke:#2563eb,color:#1e3a8a
classDef validate fill:#f3e8ff,stroke:#9333ea,color:#581c87
classDef outcome fill:#dcfce7,stroke:#16a34a,color:#14532d
class B,C,D,E decision
class AKSC,MATRIX,SAME,AUTO,STANDARD,SHORT candidate
class POC validate
class DECIDE outcome 用加權評分取代固定推薦
先替每個評估面向設定權重,再讓架構、平台、資安、財務與應用團隊各自評分。不要直接套用「Windows +5、AI +4」這種通用分數。
| 評估面向 | 建議驗證證據 |
|---|---|
| 硬性相容性 | 區域、Kubernetes 版本、CPU 架構、GPU、Windows、CSI/CNI、第三方 agent |
| 可靠性 | 控制平面 SLA、跨區設計、升級中斷、PDB、備份與復原時間 |
| 安全與合規 | 身分、私有端點、准入政策、稽核、資料落地與 breakglass |
| Day 2 營運 | 建立、擴縮、升級、除錯、事件回應與版本淘汰所需工時 |
| 總成本 | 穩態與尖峰運算、網路、觀測、備份、支援、折扣與人力 |
| 退出成本 | 雲端專屬 annotation、資料搬遷、IAM、CI/CD、重建與雙跑時間 |
表格超出欄寬時,可左右捲動;鍵盤可聚焦表格後用左右方向鍵查看。
最小可行 PoC
流程圖暫時無法顯示。可先查看下方的流程與節點文字,或重新整理頁面後再試。
查看流程與節點文字
箭頭表示流程方向;方括號與引號內是節點名稱,可搭配下方圖解閱讀。
flowchart LR
subgraph FOUNDATION[基線與整合]
direction TB
BASE[固定應用、SLO 與流量] --> DEPLOY[部署與 CI/CD]
DEPLOY --> ID[工作負載身分]
end
subgraph RESILIENCE[網路與韌性]
direction TB
NET[私有網路與 NetworkPolicy] --> SCALE[節點/Pod 擴縮]
SCALE --> UPGRADE[版本與節點升級]
UPGRADE --> FAIL[區域、節點與依賴故障]
end
subgraph EVIDENCE[觀測與決策]
direction TB
OBS[告警、追蹤與事件回應] --> BILL[匯出帳單與工時]
BILL --> ADR[ADR:證據、風險與退出計畫]
end
ID --> NET
FAIL --> OBS
classDef base fill:#dbeafe,stroke:#2563eb,color:#1e3a8a
classDef test fill:#fef3c7,stroke:#d97706,color:#78350f
classDef outcome fill:#dcfce7,stroke:#16a34a,color:#14532d
class BASE base
class DEPLOY,ID,NET,SCALE,UPGRADE,FAIL,OBS,BILL test
class ADR outcome 七、截至 2026 年的共同方向
三家都在把更多節點與核心元件責任移向供應商:GKE 以 Autopilot、AWS 以 EKS Auto Mode、Microsoft 以 AKS Automatic 提供較完整的自動化路徑。這不代表三者功能完全等價,也不代表標準模式過時;選擇關鍵仍是 guardrail 是否符合工作負載,以及團隊需要多少底層控制。
另一個共同方向是把身分、政策、供應鏈、網路與可觀測性整合到平台預設。但「預設啟用」與「已符合你的合規要求」是兩回事,仍要用組織政策、威脅模型與稽核證據驗證。
產品能力變化很快。本文只保留官方頁能穩定支持的方向,不列出未核對的市場排名、固定延遲與「某年新增」清單。
八、常見問題 FAQ
Q1:GKE 的叢集管理費 credit 適用所有叢集嗎?
不適用。GKE 定價頁列出的每月 credit 只適用於 zonal Standard 與 Autopilot 叢集,不適用 regional Standard。每個叢集仍會產生叢集管理費,credit 再由帳單帳戶層級抵扣符合條件的用量。
Q2:EKS 為什麼要把版本升級納入成本?
EKS 的 Kubernetes 版本先進入標準支援,之後可進入 extended support;官方定價頁顯示 extended support 的每小時叢集費高於標準支援。延後升級除了增加技術風險,也可能直接增加固定費用。
Q3:從 EKS 或 AKS 遷移到 GKE,或反向遷移,困難嗎?
Kubernetes 標準物件通常可以重用,但真正的工作量在 PersistentVolume、Ingress/Gateway、LoadBalancer annotation、工作負載身分、registry、祕密、DNS、觀測與 CI/CD。先列出雲端專屬資源,再設計資料同步、雙跑、流量切換與回復路徑;不要只搬 YAML 就宣告完成。
Q4:GKE Autopilot、EKS Auto Mode、AKS Automatic 有哪些限制?
三者都用 guardrail 換取較低維運負擔,限制會涉及節點存取、自訂映像檔、kernel/host 功能、第三方 agent、硬體、網路與升級控制,而且支援矩陣會持續變動。最可靠的方法是把必要能力列成清單,逐項對照最新官方限制並在 PoC 實際部署。
Q5:小團隊應該直接選哪個?
先把 GKE Autopilot、EKS Auto Mode、AKS Automatic 都列為候選,再優先保留與既有資料、IAM 和網路同雲的方案。小團隊通常更需要降低維運負擔,但也更難承擔跨雲整合與資料傳輸;用一週左右的最小 PoC 比品牌式推薦更可靠。
Q6:台灣使用者應該只看哪裡有 Region 嗎?
不應只看 Region 名稱。還要確認目標 Kubernetes 模式、GPU、資料庫、Load Balancer、私有連線與合規服務在該區域是否可用,並從實際使用者網路量測 latency、jitter 與失敗切換。固定的「從台灣幾毫秒」會隨 ISP、路徑與時間改變,不能當架構保證。
九、總結
- GKE:優先評估 Google Cloud 整合、Autopilot、release channels 與 fleet 管理/政策能力是否符合需求。
- EKS:優先評估 AWS IAM、VPC、EC2/ELB 整合,以及 Auto Mode 或標準 EKS 的責任差異。
- AKS:優先評估 Microsoft Entra、Azure 網路與監控、Automatic/Standard,以及 Windows 工作負載需求。
流程圖暫時無法顯示。可先查看下方的流程與節點文字,或重新整理頁面後再試。
查看流程與節點文字
箭頭表示流程方向;方括號與引號內是節點名稱,可搭配下方圖解閱讀。
flowchart LR
subgraph FILTER[縮小候選]
direction TB
A[硬性需求與資料重力] --> B[保留 1–2 個候選]
B --> C[團隊技能與責任邊界]
end
subgraph PROOF[選模式並驗證]
direction TB
D[自動化或 Standard] --> E[相同工作負載 PoC]
E --> F{SLO、安全與成本達標?}
end
C --> D
F -- 否 --> B
F -- 是 --> G[記錄 ADR 與退出計畫]
classDef input fill:#dbeafe,stroke:#2563eb,color:#1e3a8a
classDef decision fill:#fef3c7,stroke:#d97706,color:#78350f
classDef outcome fill:#dcfce7,stroke:#16a34a,color:#14532d
class A,B,C,D,E input
class F decision
class G outcome 沒有脫離情境的單一贏家。最穩健的決策是:用硬性需求排除不合格方案,用既有雲與責任邊界縮小範圍,再用可重現的 PoC 和帳單證據做最後選擇。
延伸閱讀
- GKE 入門:在 Google Kubernetes Engine 上部署容器應用
- App Engine、Cloud Run、GKE 怎麼選?先看誰負責維運
- GCP 資安怎麼分層?從 IAM 到資料邊界與稽核
- Terraform 與 GCP 基礎架構即程式碼
- Cloud Build CI/CD 實戰
最後核對:2026 年 8 月 4 日 | 資料來源:Google Cloud GKE、Amazon EKS 與 Microsoft AKS 官方文件及定價頁
讀完後,留一個學習紀錄
試著用自己的話說出一個重點,以及你會如何運用。實作文章請先核對結果與清理資源,再標記為讀完。
文章進度以你確認讀完的標記為準,可隨時取消。舊版造訪紀錄保留,但不計入讀完;這份自評不代表已掌握內容。