写在前面
本系列收尾篇。前面四篇（总览 + AKS/EKS/GKE 实战）各做了一遍，本篇把三家差异摆全，给一张"什么场景选哪个"的决策表。
1
2
3
4
| 本篇结构：
① 创建体验 ② 网络模型 ③ 身份机制 ④ 监控
⑤ 成本 ⑥ Serverless ⑦ 生态绑定
⑧ 选型决策表 ⑨ 一句话画像
|
一、创建体验
| 维度 | AKS | EKS | GKE |
|---|
| 一条命令建集群 | az aks create ✓ | eksctl create cluster ✓ | gcloud ... create/create-auto ✓ |
| 耗时 | ~5 min | ~15-20 min | ~5-8 min |
| 自动建 VPC/VNet | 需预建或同命令建 | eksctl 自动建 | 自动建 |
| 镜像拉取身份 | --attach-acr 授权 kubelet identity | 节点角色需具备 ECR 权限；Fargate 用 execution role | 节点服务账号需具备 AR 权限 |
| 工作负载身份 | Workload Identity | IRSA 或 EKS Pod Identity | Workload Identity Federation for GKE |
1
2
3
| 体感排名（开箱即用）：
GKE ≈ AKS > EKS
EKS 慢且步骤多（VPC/NAT/IAM 角色一长串）
|
二、网络模型
| 模型 | Pod IP | 优势 | 劣势 |
|---|
| Azure CNI（AKS） | VNet IP | Pod 原生可达，互通好 | IP 消耗大 |
| Azure CNI Overlay（AKS） | 私有 CIDR | IP 节约 + 节点 VNet | 复杂度略增 |
| Amazon VPC CNI（EKS） | ENI 次级 IP | 原生 VPC 互通 | IP 密度受 ENI 限制 |
| GKE VPC-native（Alias） | 节点 Alias 段 | 简洁、默认、GCE 集成好 | 跨 VPC 要对等 |
1
2
| 需要 Pod 与 VPC/VNet 内资源直连（数据库、对等网络）→ 都能做，配置差异不大
大规模、IP 紧张 → AKS Overlay / EKS Prefix Delegation / GKE alias 段调大
|
三、身份机制
三家本质同构（OIDC 联邦 + SA 注解 + 短 token），只是术语和命令不同：
| 云 | Pod 级身份 | 节点级身份 | 配置复杂度 |
|---|
| AKS | Workload Identity（SA 绑 Azure AD 应用） | kubelet Managed Identity | 低（attach-acr 一键） |
| EKS | IRSA（SA 注解绑 IAM Role） | 节点 EC2 instance profile | 中（OIDC + IRSA 两步） |
| GKE | Workload Identity（K8s SA ↔ GCP SA 映射） | Compute Engine 默认 SA | 中（三步绑定） |
1
2
3
4
| 核心认知：
三家的现代工作负载身份都围绕 ServiceAccount 与短期云凭据，但具体令牌交换、绑定方式和产品能力并不完全相同
会一个，另两个照搬思路（只是命令不同）
旧的节点级密钥 / AAD Pod Identity 都已过时，别再用
|
四、监控
| 维度 | AKS | EKS | GKE |
|---|
| 默认监控 | Container Insights（要 enable-addons） | CloudWatch Observability（要 addon） | Cloud Operations（默认开） |
| 日志查询 | KQL | CloudWatch Logs Insights | Cloud Logging 查询 |
| PromQL | managed Prometheus | managed Prometheus / 自建 | managed Prometheus |
| 开箱即用 | 中（一键 enable） | 中（addon） | 高（默认全开） |
1
2
3
| 体感排名（开箱即用）：
GKE > AKS ≈ EKS
GKE 建完集群控制台就有数据；AKS/EKS 要主动开 addon
|
五、成本（选型的硬约束）
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
| 集群管理（不含节点、网络、日志等）：
AKS Free $0，但无可用性 SLA；Standard/Premium 另行收费
GKE $0.10/集群小时；每个结算账户有有限月度抵扣额度
EKS 标准支持期 $0.10/集群小时；进入延长支持期后费率更高
节点（2 台通用型/月，粗算）：
AKS 2×D2s_v5 ~$150
EKS 2×t3.medium ~$60
GKE 2×e2-medium ~$50
（机型不等价，仅量级参考）
LB + 公网 IP：
三家都收（小时费 + 流量），EKS 的 NLB/ALB 稍贵
出口流量：
三家都按来源、目的地、区域和计费层级收费，不能用一个统一单价代表
|
关键洞察：
- 单集群生产：管理费只是总成本的一部分，SLA、节点、NAT/LB、观测和出口流量往往更关键。
- 多集群 / 测试环境：逐集群固定费用会累积；AKS Free 和 GKE 抵扣额度也有适用边界。
- 小规模突发：Autopilot / Fargate / Virtual Nodes 可减少预留节点，但并不等于所有情况下都“无空载成本”。
- 大规模稳定：Standard + Reserved/Spot 省。
六、降低节点运维的模式
| 云 | 产品 | 模式 |
|---|
| AKS | Automatic | Azure 管理节点预配、扩缩、升级与一组生产默认项 |
| AKS | Virtual Nodes | Pod 调度到 ACI（Azure Container Instances） |
| EKS | Auto Mode | AWS 托管节点生命周期、Karpenter、负载均衡和存储等基础能力 |
| EKS | Fargate | 把符合约束的部分 Pod 调度到 Fargate |
| GKE | Autopilot | 节点基础设施由 GCP 管理，按 Autopilot 资源计费模型收费 |
1
2
3
4
| 它们不是同一层级的等价产品：
AKS Automatic、EKS Auto Mode、GKE Autopilot 都在集群层降低节点和基础插件运维
Fargate / Virtual Nodes 则主要改变部分 Pod 的执行基础设施
支持的工作负载、网络、DaemonSet/特权能力和计费模型不同，不能只排一条"省心榜"
|
Autopilot 限制：不能特权、不能 hostNetwork、DaemonSet 受限。要这些回 Standard。
七、生态绑定（锁定成本）
| 云 | 锁定面 |
|---|
| AKS | ACR / Azure Monitor / App Gateway / Entra ID / Key Vault |
| EKS | ECR / CloudWatch / ALB&NLB / IAM / KMS |
| GKE | AR / Cloud Operations / Cloud LB / IAM / Secret Manager |
1
2
3
4
| 迁移成本：
应用层（Deployment/Service/Helm）→ 跨云通用，迁移低
云集成层（镜像库/监控/身份/LB/密钥）→ 各家不同，迁移高
→ 真要多云/防锁定：镜像库用 Harbor，监控用 Prometheus+Grafana，身份抽象一层
|
八、选型决策表
1
2
3
4
5
6
7
8
9
10
| 你的情况 推荐
──────────────────────────────────────────────────────
已在某家云、团队熟 → 就用那家的（沉没成本 + 生态）
全新、追求开箱即用、减少节点运维 → 比较 AKS Automatic / EKS Auto Mode / GKE Autopilot
全新、要深度定制节点 → 比较 AKS Standard、EKS 与 GKE Standard
重度 AWS 生态 + IAM 合规 → 重点评估 EKS
多集群 / 大量测试环境 → 按集群层级、抵扣规则和自动休眠能力实算
强 AD / 企业合规 / 混合云 → AKS（Azure 混合优势）
小规模突发、按 Pod 计费 → GKE Autopilot / EKS Fargate
国内访问（中国用户） → AKS（有世纪互联）或国内 ACK/TKE
|
没有"最好"，只有"最合适"。三家都是 upstream K8s，应用层通用，选型主要看已有云绑定 + 团队熟悉度 + 成本结构。
九、一句话画像 + 系列收官
1
2
3
| AKS 多种管理定价层级 + Azure 生态 + Entra ID/混合云能力
EKS AWS 生态与 IAM 集成深入 + 按版本支持阶段收集群费
GKE 有集群管理费与有限月度抵扣 + Autopilot 自动化程度高
|
系列总结（5 篇走完）：
- 总览：三家横览，建立全景
- AKS：Free/Standard/Premium 管理层级 + kubelet Managed Identity 拉 ACR
- EKS：按支持阶段计费 + IRSA/Pod Identity；传统集群通常自装 LB Controller，Auto Mode 已托管相关能力
- GKE：Autopilot 全托管 + 监控默认开
- 本篇：横向对比 + 选型决策
1
2
3
4
5
| 核心收获：
✓ 托管 K8s 把"通用难搞"的部分（控制平面/CNI/CSI/升级）交给云
✓ 三家身份机制同构（OIDC + SA），会一个通三个
✓ kubectl 和大部分 Kubernetes API/Helm 工作流可迁移，但存储类、负载均衡注解、身份、网络与托管扩展仍会形成差异
✓ 选型看：已有云绑定 > 成本结构 > 团队熟悉度
|
想补 K8s 原理地基（自建、etcd、CNI/CSI 细节），看本站「K8s 学习笔记」十篇；想深入某家云的特化特性，各云官方文档是终点。云托管到此，下一站看你团队的方向。