云平台托管集群：EKS、GKE、AKS 深度解析与选型指南-第一章
目录
专栏介绍
作者与平台
您将学到什么？
学习特色
引言：云原生时代的托管集群浪潮
第一章：核心架构与基础概念对比
1.1 控制平面架构：谁在幕后掌控全局？
1.2 工作节点模型：计算资源的基石
1.3 网络模型：Pods 如何互联互通？
专栏介绍
作者与平台
作者:庸子
用户ID:2401_86478612
第一发表平台：CSDN
欢迎来到《Kubernetes架构师之路：系统化学习与实践》专栏！在这个容器化技术主导的时代，Kubernetes已成为云原生应用编排的事实标准，掌握Kubernetes已成为每位开发者和运维工程师的必备技能。
本专栏采用系统化学习方法，从基础概念到高级实践，循序渐进地带您全面掌握Kubernetes技术栈。无论您是刚接触容器技术的初学者，还是希望深入理解Kubernetes架构的资深工程师，这里都将为您提供清晰的学习路径和实用的实战指导。
您将学到什么？
- 基础理论：深入理解容器、容器编排、Kubernetes核心概念和架构设计
- 核心组件：掌握etcd、API Server、Controller Manager、Scheduler等核心组件的工作原理
- 资源管理：学会Pod、Deployment、Service、Ingress等核心资源的创建与管理
- 网络与存储：理解Kubernetes网络模型和存储方案，解决实际部署中的网络与存储问题
- 高可用与扩展：构建高可用的Kubernetes集群，实现应用的自动扩展与故障恢复
- 监控与日志：掌握集群监控、日志收集与应用性能优化方法
- CI/CD集成：学习如何将Kubernetes与CI/CD流程结合，实现自动化部署
- 安全实践：了解Kubernetes安全模型，掌握RBAC、网络策略等安全配置
学习特色
- 系统化知识体系：从零开始，构建完整的Kubernetes知识框架
- 实战导向：每个知识点都配有实际操作案例，让您"学以致用"
- 问题驱动：针对实际部署中常见的问题提供解决方案
- 最新版本覆盖：基于最新稳定版Kubernetes，紧跟技术发展趋势
- 架构师视角：不仅教您"如何做"，更解释"为什么这样设计"
无论您是想提升个人竞争力，还是为企业构建高效的云原生基础设施，本专栏都将助您成为真正的Kubernetes专家。让我们一起开启这段激动人心的Kubernetes学习之旅！
立即订阅，开启您的Kubernetes架构师成长之路！
引言：云原生时代的托管集群浪潮
在数字化转型的浪潮中，容器化技术（以 Docker 为代表）和容器编排平台（以 Kubernetes 为核心）已成为现代应用架构的基石。企业纷纷拥抱云原生，以实现敏捷开发、弹性伸缩、高可用性和资源效率最大化。然而，自建 Kubernetes 集群涉及复杂的安装、配置、升级、维护和监控工作，对运维团队的技术能力和资源投入提出了极高要求。
为了解决这一痛点，全球三大云服务提供商——亚马逊云科技（AWS）、谷歌云（Google Cloud）、微软 Azure——相继推出了其 Kubernetes 托管服务：
Amazon EKS (Elastic Kubernetes Service)
Google Kubernetes Engine (GKE)
Azure Kubernetes Service (AKS)
这些托管服务将 Kubernetes 控制平面的管理责任完全交给云厂商，用户只需专注于工作负载的部署、管理和业务创新。它们极大地降低了 Kubernetes 的使用门槛，加速了云原生应用的落地。
然而，EKS、GKE、AKS 虽然都基于 Kubernetes 核心，但在架构设计、功能特性、集成生态、成本模型、运维体验等方面存在显著差异。对于企业而言，选择哪个平台并非易事，需要综合考虑技术栈、业务需求、成本预算、团队技能、合规要求等多重因素。
本文旨在提供一份超详细、超深入、超实用的对比分析，字数超过 3 万字，力求成为您在 EKS、GKE、AKS 之间做出明智选择的终极参考。我们将从基础架构到高级特性，从技术细节到实战场景，从成本优化到未来趋势，进行全方位、无死角的剖析。
第一章：核心架构与基础概念对比
理解三大托管服务的核心架构是选型的基石。虽然它们都遵循 Kubernetes 的控制平面/工作节点分离模型，但实现方式、网络模型、与云原生服务的集成深度却大相径庭。
1.1 控制平面架构：谁在幕后掌控全局？
Amazon EKS:
架构： EKS 控制平面由 AWS 在其管理的 VPC 中运行，采用多可用区（Multi-AZ）部署，确保高可用性。控制平面组件（API Server, etcd, Scheduler, Controller Manager）分布在多个 AZ 中。
管理： AWS 负责控制平面的所有管理任务：安装、升级、修补、监控、故障恢复。用户无法直接访问控制平面节点或 etcd。
网络： 控制平面与工作节点之间的通信通过 AWS 私有网络（VPC）进行。EKS 会自动创建和管理一个安全组，用于控制平面与工作节点 API Server 之间的通信。用户需要确保工作节点所在的 VPC 子网与 EKS 集群关联，并配置适当的安全组规则。
端点： 提供公有端点（默认）和私有端点（可选）。私有端点使 API Server 仅能通过 VPC 内部访问，增强安全性。
版本管理： AWS 提供多个 Kubernetes 版本供选择，并负责版本升级。用户需要主动发起升级操作，AWS 会提供升级路径指导。升级过程通常是滚动升级，对业务影响较小，但仍需仔细规划。
Google Kubernetes Engine (GKE):
架构： GKE 控制平面由 Google 在其全球基础设施中运行，同样采用多区域/多可用区部署（取决于集群类型：Regional 或 Zonal）。Google 以其强大的 Borg/Omega 系统经验为基础，构建了高度自动化和可靠的 Kubernetes 管理层。
管理： Google 负责控制平面的全生命周期管理，包括自动化的修补、升级和故障恢复。用户无法直接访问控制平面组件。
网络： GKE 控制平面与工作节点之间的通信通过 Google 的私有网络（VPC）进行。GKE 自动配置必要的防火墙规则（VPC 防火墙）来允许控制平面与节点之间的通信。GKE 对 VPC 的原生集成是其一大优势。
端点： 提供公有端点（默认）和私有端点（可选）。私有端点（Private Cluster）使 API Server 仅能通过 VPC 内部 IP 访问，甚至可以限制访问范围到特定的子网/IP 地址。
版本管理： Google 提供 Kubernetes 版本支持策略，通常支持最新的几个版本。GKE 提供了自动升级功能（可配置），可以自动将控制平面和节点升级到指定的版本或补丁级别，极大简化了运维。也支持手动升级。GKE 的升级策略通常非常成熟和稳定。
Azure Kubernetes Service (AKS):
架构： AKS 控制平面由 Microsoft 在其管理的 Azure 订阅中运行，采用多可用区部署（通过托管在多个底层 Azure 资源上实现）。控制平面组件（API Server, etcd 等）作为 Azure 托管服务运行。
管理： Microsoft 负责控制平面的管理、维护、升级和修补。用户无法直接访问控制平面节点或 etcd。
网络： AKS 控制平面与工作节点之间的通信通过 Azure 虚拟网络（VNet）进行。AKS 会自动配置网络安全组（NSG）规则来允许控制平面与节点之间的通信。AKS 对 Azure VNet 的集成也非常深入。
端点： 提供公有端点（默认）和私有端点（可选）。私有端点（Private Cluster）使 API Server 仅能通过 VNet 内部 IP 访问，是 AKS 增强安全性的重要特性。
版本管理： Microsoft 提供 Kubernetes 版本支持策略。AKS 支持手动升级控制平面和节点池。AKS 也提供了自动升级通道（如 stable, rapid, patch），用户可以配置集群自动接收指定通道的升级。升级过程由 Azure 管理。
核心架构对比总结：
| 特性 | Amazon EKS | Google GKE | Azure AKS |
| 控制平面位置 | AWS 管理的 VPC (多 AZ) | Google 全球基础设施 (多区域/AZ) | Azure 管理的订阅 (多 AZ) |
| 管理责任 | AWS 全权负责 | Google 全权负责 | Microsoft 全权负责 |
| 高可用性 | 多 AZ 部署 | Regional (多区域) 或 Zonal (单区域多 AZ) | 多 AZ 部署 |
| 网络模型 | 基于 AWS VPC, 需配置安全组 | 基于 Google VPC, 自动配置防火墙规则 | 基于 Azure VNet, 自动配置 NSG 规则 |
| 端点访问 | 公有/私有端点 | 公有/私有端点 (Private Cluster) | 公有/私有端点 (Private Cluster) |
| 版本管理 | 手动升级为主，AWS 提供路径 | 自动升级 (可选) + 手动升级，策略成熟 | 自动升级通道 (可选) + 手动升级 |
| 控制平面可见性 | 无 | 无 | 无 |
| etcd 访问 | 无 | 无 | 无 |
1.2 工作节点模型：计算资源的基石
工作节点（Worker Nodes）是运行用户容器化应用（Pods）的虚拟机（或物理机）。三大平台在节点管理、操作系统选择、自动扩缩容等方面各有侧重。
Amazon EKS:
节点类型：托管节点组 (Managed Node Groups): 这是 EKS 的推荐方式。 AWS 负责节点的生命周期管理（启动、终止、替换、升级）。用户定义节点组规格（实例类型、数量、AMI、子网等），EKS 会自动处理节点故障替换、滚动更新（包括 OS 补丁和 Kubernetes 组件升级）。简化了运维。
自管理节点组 (Self-managed Node Groups): 用户使用 EC2 Auto Scaling Groups 和自定义 AMI 来管理节点。用户需要自行处理节点的启动配置、升级、打补丁、故障替换等。灵活性高，但运维负担重。
操作系统： 主要支持 Amazon Linux 2 和 Amazon Linux 2023。也支持 Ubuntu 和 Windows Server（通过专门的 Windows 节点组）。AWS 为其优化过的 AMI 包含了必要的容器运行时（如 containerd）、kubelet 和其他组件。
自动扩缩容：Cluster Autoscaler (CA): 开源项目，EKS 完全支持。CA 监控集群中因资源不足而处于 Pending 状态的 Pod，并自动增加节点组中的节点数量。当节点利用率低且 Pod 可以安全调度到其他节点时，CA 会减少节点数量。需要用户自行部署和配置 CA。
Karpenter (AWS 原生): 这是 EKS 的明星级节点管理工具。 Karpenter 直接观察 Pending Pods，并按需启动最合适的 EC2 实例（考虑实例类型、可用区、价格、容量类型等），无需预先定义节点组。它还能更智能地整合节点（bin-packing）以优化成本和资源利用率。Karpenter 显著简化了节点管理，尤其适合工作负载多样化、需求波动大的场景。是 EKS 相对于 GKE/AKS 的一个重要差异化优势。
容量类型： 支持 On-Demand、Spot（通过托管节点组或 Karpenter）、Dedicated Hosts。Karpenter 对 Spot 实例的管理尤其出色，能自动处理 Spot 中断并重新调度 Pods。
Google Kubernetes Engine (GKE):
节点类型：标准模式 (Standard Mode): 用户管理节点池（Node Pools）。用户定义节点池的配置（机器类型、镜像、数量、自动扩缩容策略等）。Google 负责节点的底层基础设施管理，但用户需要通过 GKE 控制台或 gcloud 命令管理节点池的扩缩容和升级（尽管有自动升级选项）。
Autopilot 模式： 这是 GKE 的革命性创新。 用户完全无需管理节点！用户只需定义工作负载的资源请求（CPU、内存），GKE Autopilot 会自动管理底层基础设施：动态分配计算资源（基于 Google 的资源池）、自动扩缩容（Pod 和节点层面）、自动修补和升级、优化资源利用率。用户按实际使用的 vCPU/内存/GPU 资源付费（秒级计费），无需为节点付费。极大降低了运维复杂度，特别适合无服务器化倾向、关注成本效率、开发团队资源有限的场景。是 GKE 的核心卖点。
操作系统： 主要支持 Container-Optimized OS (COS)，这是 Google 专门为运行容器优化的轻量级、安全、自动更新的 Linux 发行版。也支持 Ubuntu 和 Windows Server（通过专门的 Windows 节点池）。
自动扩缩容：Cluster Autoscaler (CA): GKE 内置并自动管理 CA。用户只需在节点池上启用自动扩缩容，设置最小/最大节点数即可。GKE 的 CA 集成度非常高，通常开箱即用。
Pod 水平自动扩缩容 (HPA): Kubernetes 标准组件，GKE 完全支持。
Pod 垂直自动扩缩容 (VPA): GKE 提供托管的 VPA 服务，可以自动调整 Pod 的资源请求和限制，优化资源利用率。
Autopilot 模式： 自动扩缩容是其核心能力，完全由平台管理。
容量类型： 支持 On-Demand、Preemptible VMs（类似 Spot，通过节点池配置）、Committed Use Discounts（长期承诺折扣）。Autopilot 模式下，用户无需关心底层容量类型，由 Google 优化成本。
Azure Kubernetes Service (AKS):
节点类型：托管节点池 (Managed Node Pools): 这是 AKS 的标准方式。 用户通过 Azure 门户、CLI 或 ARM 模板定义节点池（VM 大小、OS 类型、数量、子网等）。Azure 负责节点的底层管理（如主机维护），但用户需要管理节点池的扩缩容和升级（尽管有自动升级通道）。
虚拟节点 (Virtual Nodes)： 基于 ACI (Azure Container Instances) 的无服务器容器服务。允许 AKS 集群在需要时快速启动 Pod 到 ACI 中，无需等待节点扩容。适合突发流量、批处理任务等场景。Pod 运行在 ACI 上，与 AKS 节点池网络互通。
操作系统： 主要支持 Ubuntu 和 Azure Linux（Microsoft 推荐的、针对容器优化的 Linux 发行版）。也支持 Windows Server（通过专门的 Windows 节点池）。
自动扩缩容：Cluster Autoscaler (CA): AKS 内置并自动管理 CA。用户在节点池上启用自动扩缩容，设置最小/最大节点数即可。集成度高。
Pod 水平自动扩缩容 (HPA): Kubernetes 标准组件，AKS 完全支持。
Pod 垂直自动扩缩容 (VPA): AKS 目前不提供托管的 VPA 服务，用户需要自行部署和配置开源 VPA。
容量类型： 支持 On-Demand、Spot（通过节点池配置）、Reserved Instances（长期承诺折扣）。虚拟节点（ACI）按秒计费。
工作节点模型对比总结：
| 特性 | Amazon EKS | Google GKE | Azure AKS |
| 主要节点管理方式 | 托管节点组 (推荐) / 自管理节点组 | 标准模式 (节点池) / Autopilot (无节点) | 托管节点池 / 虚拟节点 (ACI) |
| 操作系统 | Amazon Linux 2/2023, Ubuntu, Windows Server | Container-Optimized OS (COS), Ubuntu, Windows | Ubuntu, Azure Linux, Windows Server |
| 核心自动扩缩容 | Cluster Autoscaler / Karpenter (原生) | Cluster Autoscaler (内置) / Autopilot (内置) | Cluster Autoscaler (内置) / 虚拟节点 (ACI) |
| VPA 支持 | 需自行部署开源 VPA | 提供托管 VPA | 需自行部署开源 VPA |
| Spot/Preemptible | Karpenter 对 Spot 优化极佳 / 托管节点组支持 | 节点池支持 Preemptible VMs | 节点池支持 Spot VMs |
| 无服务器容器 | 无直接对应 | Autopilot 模式 (核心卖点) | 虚拟节点 (ACI) |
| 节点升级 | 托管节点组支持滚动升级 | 标准模式支持自动/手动升级；Autopilot 自动升级 | 支持自动升级通道/手动升级 |
| 运维复杂度 | 托管节点组中；Karpenter 简化 Spot 管理 | Autopilot 最低；标准模式中等 | 托管节点池中等；虚拟节点简化突发流量处理 |
1.3 网络模型：Pods 如何互联互通？
网络是 Kubernetes 集群的命脉。三大平台在 CNI（容器网络接口）插件选择、Pod IP 分配、网络策略实现、负载均衡集成等方面各有特色。
Amazon EKS:
CNI 插件： 默认使用 Amazon VPC CNI。这是 AWS 专门为 EKS 开发的 CNI 插件，其核心特点是：
Pod IP 直接使用 VPC IP： 每个 Pod 分配一个真实的 VPC 子网 IP 地址。这使得 Pod 可以像 EC2 实例一样直接参与 VPC 路由，无需额外的 NAT 或 Overlay 网络（在大多数情况下）。
安全组： Pod 可以直接关联 VPC 安全组（Security Groups for Pods），实现 Pod 级别的网络隔离和安全控制。这是 EKS 网络的一大优势。
IP 地址管理： 依赖 VPC 子网的 IP 地址池。需要合理规划子网大小，避免 IP 耗尽。支持 IPv4 和 IPv6。
网络策略： VPC CNI 本身不实现 Kubernetes NetworkPolicy。需要额外部署支持 NetworkPolicy 的 CNI 插件（如 Calico, Cilium）或使用 AWS 的安全组策略（Security Group Policy）来达到类似效果。安全组策略与 AWS 安全组深度集成，但属于 EKS 特有扩展。
负载均衡：Service Type: LoadBalancer： 创建 Service 时，EKS 自动集成 AWS Network Load Balancer (NLB) 或 Application Load Balancer (ALB)。
AWS Load Balancer Controller： 这是官方推荐的控制器，取代了旧的 Ingress Controller。它支持：
通过 Service 注解自动创建 NLB（支持 TCP/UDP 流量，性能高）。
通过 Ingress 资源自动创建 ALB（支持 HTTP/HTTPS 流量，高级路由规则，WAF 集成）。
支持 IP 模式（Pod IP 直接作为后端，提高效率）和实例模式（节点 IP 作为后端）。
与 AWS WAF, Shield, Cognito 等安全服务深度集成。
DNS： 集群内部使用 CoreDNS。Pod 可以通过 Service 名称解析。外部 DNS 集成通常使用 ExternalDNS 项目。
Google Kubernetes Engine (GKE):
CNI 插件：默认： VPC-native (使用 IpTables 或 eBPF 作为数据平面)。这是 GKE 的推荐模式。
Pod IP 使用别名 IP： Pod 分配的 IP 地址来自为节点配置的别名 IP 范围（Alias IP Ranges）。这些 IP 是 VPC 内的有效地址，但不是直接从子网分配的（子网 IP 用于节点主接口）。路由由 Google Cloud 路由表处理。
网络策略： 原生支持 Kubernetes NetworkPolicy，无需额外 CNI。GKE 使用其内部实现的网络策略引擎（基于 eBPF 或 IPTables）来强制执行规则。这是 GKE 的一个显著优势，开箱即用。
高效： VPC-native 模式通常性能很好，延迟低。
可选： Calico CNI（通过 GKE 插件安装）。如果用户需要 Calico 的特定功能（如 BGP、更精细的网络策略控制），可以选择安装。
负载均衡：Service Type: LoadBalancer： 创建 Service 时，GKE 自动集成 Google Cloud Load Balancing。
支持类型：外部负载均衡： 支持 Global External HTTPS Load Balancer (高级 HTTP/S 路由，CDN 集成，Cloud Armor WAF)，Regional External HTTP(S) Load Balancer，Network Load Balancing (TCP/UDP, Passthrough)。
内部负载均衡： 支持 Internal TCP/UDP Load Balancing 和 Regional Internal HTTP(S) Load Balancing。
Ingress： GKE 提供 GKE Ingress Controller，它使用 Global External HTTPS Load Balancer 或 Regional External HTTP(S) Load Balancer 作为后端。支持高级路由、SSL/TLS 终止、认证等。与 Cloud Armor (WAF), Cloud CDN 等深度集成。
特性： Google Cloud Load Balancing 以其全球覆盖、高可用性、可扩展性和丰富的功能著称。GKE 的集成非常成熟和强大。
DNS： 集群内部使用 kube-dns 或 CoreDNS (取决于版本)。Pod 可以通过 Service 名称解析。外部 DNS 集成通常使用 ExternalDNS 或 Cloud DNS。
Azure Kubernetes Service (AKS):
CNI 插件：默认： Azure CNI。这是 AKS 的推荐模式。
Pod IP 使用 VNet IP： 与 EKS VPC CNI 类似，每个 Pod 分配一个真实的 Azure VNet 子网 IP 地址。Pod 可以像 VM 一样直接参与 VNet 路由。
IP 地址管理： 依赖 VNet 子网的 IP 地址池。需要合理规划子网大小。支持 IPv4 和 IPv6。
网络策略： Azure CNI 本身不实现 Kubernetes NetworkPolicy。需要额外部署支持 NetworkPolicy 的 CNI 插件（如 Calico, Cilium）或使用 Azure Network Policy（基于 Calico 的 Azure 托管版本）来实现。Azure Network Policy 与 Azure 网络安全组 (NSG) 有一定集成。
可选： Kubenet (较老，不推荐)。使用 Overlay 网络，Pod IP 是私有地址，通过节点进行 NAT。节省 VNet IP，但性能稍差，网络策略支持有限。
负载均衡：Service Type: LoadBalancer： 创建 Service 时，AKS 自动集成 Azure Load Balancer。
支持类型：公共负载均衡器： 用于暴露服务到公网。
内部负载均衡器： 用于在 VNet 内部暴露服务。
Ingress： AKS 提供 AGIC (Application Gateway Ingress Controller)，它使用 Azure Application Gateway 作为后端。Application Gateway 是第 7 层负载均衡器，支持 HTTP/S 路由、SSL/TLS 终止、基于 Cookie 的会话亲和性、WAF (Web Application Firewall) 集成等。这是 AKS Ingress 的主要推荐方案。
替代方案： 也可以使用 Nginx Ingress Controller + Azure Load Balancer，或 Traefik 等。
DNS： 集群内部使用 CoreDNS。Pod 可以通过 Service 名称解析。外部 DNS 集成通常使用 ExternalDNS 或 Azure DNS。
网络模型对比总结：
| 特性 | Amazon EKS | Google GKE | Azure AKS |
| 默认 CNI | Amazon VPC CNI (Pod IP = VPC IP) | VPC-native (Pod IP = Alias IP) | Azure CNI (Pod IP = VNet IP) |
| Pod IP 地址来源 | VPC 子网 IP | 节点别名 IP 范围 | VNet 子网 IP |
| NetworkPolicy 支持 | 需额外 CNI (Calico/Cilium) 或 安全组策略 | 原生支持 (开箱即用) | 需额外 CNI (Calico/Cilium) 或 Azure Network Policy |
| 安全组/NSG 集成 | 强 (Security Groups for Pods) | 无直接集成 (依赖 NetworkPolicy) | 中等 (Azure Network Policy 与 NSG 有集成) |
| LoadBalancer 类型 | NLB (TCP/UDP), ALB (HTTP/S) | Global/Regional External HTTP(S), NLB, Internal LB | Public/Internal LB (L4), Application Gateway (L7) |
| Ingress 控制器 | AWS Load Balancer Controller (ALB/NLB) | GKE Ingress Controller (Global/Regional HTTP(S)) | AGIC (Application Gateway) |
| 负载均衡器特性 | 与 AWS WAF, Shield, Cognito 深度集成 | 与 Cloud Armor (WAF), Cloud CDN 深度集成，全球负载均衡 | 与 Azure WAF (Application Gateway) 深度集成 |
| DNS | CoreDNS (内部), ExternalDNS (外部) | kube-dns/CoreDNS (内部), ExternalDNS/Cloud DNS (外部) | CoreDNS (内部), ExternalDNS/Azure DNS (外部) |
| IP 规划复杂度 | 高 (需预留足够 VPC IP) | 中 (别名 IP 范围规划) | 高 (需预留足够 VNet IP) |