云平台托管集群：EKS、GKE、AKS 深度解析与选型指南-第二章
目录
专栏介绍
作者与平台
您将学到什么？
学习特色
引言：云原生时代的托管集群浪潮
第二章：核心功能与高级特性深度剖析
2.1 存储集成：持久化数据的基石
2.2 安全体系：构建零信任的容器环境
2.3 可观测性：洞察集群与应用的脉搏
2.4 DevOps 与 CI/CD 集成：加速应用交付
2.5 无服务器与混合云扩展：超越集群边界
专栏介绍
作者与平台
作者:庸子
用户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 之间做出明智选择的终极参考。我们将从基础架构到高级特性，从技术细节到实战场景，从成本优化到未来趋势，进行全方位、无死角的剖析。
第二章：核心功能与高级特性深度剖析
除了基础架构，三大平台在存储、安全、可观测性、DevOps 集成、无服务器扩展等核心功能和高级特性上的差异，往往是企业选型的关键考量点。
2.1 存储集成：持久化数据的基石
容器本身是无状态的，但绝大多数应用都需要持久化存储。三大平台如何提供和管理持久化卷？
Amazon EKS:
存储驱动： 使用 Container Storage Interface (CSI) 驱动程序。AWS 提供官方 CSI 驱动：
AWS EBS CSI Driver： 用于动态创建和管理 EBS 卷（块存储）。支持不同类型的 EBS 卷（gp2/gp3, io1/io2, st1, sc1）。支持卷快照、克隆、扩容。支持加密（使用 AWS KMS）。
AWS EFS CSI Driver： 用于动态创建和管理 EFS 文件系统（共享文件存储）。支持动态创建 PV/PVC，支持 ReadWriteMany 访问模式。非常适合需要多个 Pod 共享数据的场景（如内容管理、数据处理）。支持加密。
FSx for Lustre CSI Driver： 用于高性能计算场景，集成 FSx for Lustre 文件系统。
FSx for NetApp ONTAP CSI Driver： 集成企业级文件存储 FSx for ONTAP。
存储类 (StorageClass)： EKS 默认提供 gp2 (EBS) 和 gp3 (EBS) StorageClass。用户可以轻松创建自定义 StorageClass 来指定不同的 EBS 类型、IOPS、吞吐量、加密参数，或者使用 EFS/FSx。
快照与备份：EBS 快照： EBS CSI Driver 支持创建卷快照。结合 VolumeSnapshotClass 和 VolumeSnapshot 资源，可以实现应用一致性快照（需要应用配合，如使用 Velero）。
Velero： 强烈推荐使用开源备份迁移工具 Velero。它利用 CSI 快照能力，可以备份和恢复整个集群（包括资源对象和持久化卷），支持跨集群、跨区域迁移。与 AWS S3 集成存储备份数据。
动态配置： 所有 CSI 驱动都支持动态 PV 配置，用户只需创建 PVC 并指定 StorageClass，驱动会自动创建底层存储资源。
Google Kubernetes Engine (GKE):
存储驱动： 同样使用 CSI 驱动。Google Cloud 提供官方 CSI 驱动：
PD CSI Driver： 用于动态创建和管理 Persistent Disk (PD)（块存储）。支持标准 PD、SSD PD、平衡 PD。支持快照、克隆、扩容。支持加密（使用 Google Cloud KMS）。
Filestore CSI Driver： 用于动态创建和管理 Filestore 实例（高性能网络文件存储）。支持 ReadWriteMany。支持不同性能层级（标准、高级、企业）。
Cloud Storage FUSE CSI Driver： 允许 Pod 直接挂载 Google Cloud Storage (GCS) 存储桶作为文件系统。适合对象存储访问、大数据分析等场景。性能取决于 FUSE 实现。
存储类 (StorageClass)： GKE 默认提供 standard (标准 PD), premium-rwo (SSD PD), standard-rwx (Filestore) 等 StorageClass。用户可以轻松创建自定义 StorageClass。
快照与备份：PD 快照： PD CSI Driver 支持创建卷快照。结合 VolumeSnapshot 资源实现。
Velero： 同样推荐使用 Velero。与 Google Cloud Storage 集成存储备份数据。GKE 对 Velero 的支持良好。
动态配置： 所有 CSI 驱动都支持动态 PV 配置。
Azure Kubernetes Service (AKS):
存储驱动： 使用 CSI 驱动。Azure 提供官方 CSI 驱动：
Azure Disk CSI Driver： 用于动态创建和管理 Azure Disk（块存储）。支持 Premium SSD (P), Standard SSD (E), Standard HDD (S)。支持快照、克隆、扩容。支持加密（使用 Azure Disk Encryption）。
Azure File CSI Driver： 用于动态创建和管理 Azure Files（共享文件存储）。支持 Premium 和 Standard 层级。支持 ReadWriteMany。支持 SMB 和 NFS 协议。支持加密（使用 Azure Storage Service Encryption）。
Blob Fuse CSI Driver： 允许 Pod 直接挂载 Azure Blob Storage 容器作为文件系统（通过 Blob FUSE）。适合对象存储访问。
存储类 (StorageClass)： AKS 默认提供 default (Azure Disk - Standard HDD), managed-premium (Azure Disk - Premium SSD), azurefile (Azure Files - Standard), azurefile-premium (Azure Files - Premium) 等 StorageClass。用户可以创建自定义 StorageClass。
快照与备份：Azure Disk 快照： Azure Disk CSI Driver 支持创建卷快照。结合 VolumeSnapshot 资源实现。
Velero： 推荐使用 Velero。与 Azure Blob Storage 集成存储备份数据。AKS 对 Velero 的支持良好。
动态配置： 所有 CSI 驱动都支持动态 PV 配置。
存储集成对比总结：
| 特性 | Amazon EKS | Google GKE | Azure AKS |
| 主要 CSI 驱动 | EBS CSI, EFS CSI, FSx CSI (Lustre/ONTAP) | PD CSI, Filestore CSI, Cloud Storage FUSE CSI | Azure Disk CSI, Azure File CSI, Blob Fuse CSI |
| 块存储 | EBS (gp2/gp3, io1/io2, st1, sc1) | Persistent Disk (PD) (Standard, SSD, Balanced) | Azure Disk (Premium SSD, Standard SSD/HDD) |
| 共享文件存储 | EFS (NFS), FSx for Lustre, FSx for ONTAP | Filestore (NFS), Cloud Storage FUSE (Object) | Azure Files (SMB/NFS), Blob Fuse (Object) |
| 对象存储挂载 | 无官方 CSI (需第三方方案) | Cloud Storage FUSE CSI (GCS) | Blob Fuse CSI (Azure Blob Storage) |
| 快照支持 | EBS/EFS/FSx CSI 支持 | PD/Filestore CSI 支持 | Azure Disk/Azure File CSI 支持 |
| 备份工具 | Velero (S3) | Velero (GCS) | Velero (Azure Blob Storage) |
| 加密 | EBS/EFS/FSx 支持 KMS 加密 | PD/Filestore 支持 KMS 加密 | Azure Disk/Azure Files 支持 SSE 加密 |
| 动态配置 | 全部支持 | 全部支持 | 全部支持 |
| ReadWriteMany | EFS, FSx (Lustre/ONTAP) | Filestore, Cloud Storage FUSE | Azure Files (SMB/NFS) |
分析：
块存储： 三者都提供高性能、可扩展的块存储解决方案（EBS, PD, Azure Disk），功能（快照、加密、动态配置）非常接近。EBS 的 gp3 在性价比上常被称道，PD 的平衡类型提供灵活性，Azure Disk 的 Premium SSD 性能优异。
共享文件存储： EFS、Filestore、Azure Files 都是成熟的 NFS 解决方案。EFS 以其简单的扩展性和按使用量付费模式著称；Filestore 提供明确的服务层级和性能保障；Azure Files 对 SMB 协议的原生支持是其特色（尤其对 Windows 应用）。
对象存储挂载： GKE 和 AKS 提供了官方 CSI 驱动（Cloud Storage FUSE, Blob Fuse）将对象存储桶挂载为文件系统，方便应用直接访问对象数据。EKS 目前缺乏官方方案，需要依赖第三方工具或自定义实现。
高级存储： EKS 通过 FSx CSI 集成了 Lustre（HPC）和 NetApp ONTAP（企业级 NAS），提供了更专业化的存储选项，这是其优势。GKE 和 AKS 在此方面相对依赖其通用的文件存储或对象存储方案。
备份： Velero 是三大平台都支持的、事实上的标准备份迁移工具，功能强大且成熟。集成各自的云存储（S3, GCS, Blob）作为后端。
2.2 安全体系：构建零信任的容器环境
安全是 Kubernetes 部署的重中之重。三大平台在身份认证与授权、网络安全、工作负载安全、合规性等方面构建了多层次的安全体系。
Amazon EKS:
身份认证 (Authentication)：IAM Authenticator for Kubernetes： 核心组件。允许用户使用 AWS IAM 用户或角色来认证到 Kubernetes API Server。通过创建 aws-auth ConfigMap 将 IAM 角色/用户映射到 Kubernetes 用户/组。这是 EKS 身份认证的核心，与 AWS IAM 深度集成。
OIDC 身份提供者集成： EKS 集群可以配置为信任外部的 OIDC 身份提供者（如 Active Directory, Okta, Auth0）。用户可以使用外部 IdP 的身份登录集群。
服务账户令牌卷投影： 支持 Kubernetes 服务账户与 IAM 角色的关联（IRSA - IAM Roles for Service Accounts）。允许 Pod 内的服务账户直接承担 IAM 角色，获取临时 AWS 凭证，无需在 Pod 中硬编码长期密钥。这是 EKS 安全的关键特性。
授权 (Authorization)：Kubernetes RBAC： 标准授权机制，基于角色（Role/ClusterRole）和角色绑定（RoleBinding/ClusterRoleBinding）控制对 Kubernetes API 资源的访问。
AWS IAM Authenticator 与 RBAC 结合： 通过 aws-auth ConfigMap 将 IAM 主体映射到 Kubernetes 用户/组后，即可对这些用户/组应用 RBAC 策略。
网络安全：安全组 (Security Groups)： 如前所述，VPC CNI 支持 Security Groups for Pods。可以为 Pod 或 Deployment 直接关联安全组，实现 Pod 级别的入站/出站流量控制。这是 AWS 独有的强大功能。
网络策略： 通过部署 Calico/Cilium 或使用安全组策略实现。
VPC 流日志： 可开启 VPC 流日志，记录所有进出 VPC 的网络流量，用于审计和故障排查。
AWS WAF/Shield： 集成到 ALB/NLB，提供 Web 应用防火墙和 DDoS 防护。
工作负载安全：容器镜像扫描： 集成 Amazon ECR (Elastic Container Registry) 的镜像扫描功能（基本扫描免费，高级扫描需付费）。可在推送镜像时自动扫描漏洞。
密钥管理： 集成 AWS Secrets Manager 和 Parameter Store。通过 CSI 驱动（如 Secrets Store CSI Driver）将密钥安全地挂载到 Pod 中，或使用 SDK 在应用中访问。IRSA 是 Pod 访问 AWS 服务凭证的最佳实践。
运行时安全： AWS 提供 GuardDuty，可监控 EKS 集群的审计日志（如 CloudTrail）、VPC 流日志等，检测潜在威胁（如异常 API 调用、恶意 IP 访问）。Amazon Inspector 可提供运行时漏洞评估。
Pod 安全策略 (PSP) / Pod 安全准入控制器 (PSA)： EKS 支持 PSP（已弃用，未来将移除）和新的 PSA（Pod Security Admission）。推荐使用 PSA 并结合 OPA/Gatekeeper 等策略引擎实施更精细的 Pod 安全标准（如限制特权容器、主机路径挂载等）。
合规性： AWS 提供广泛的合规性认证（如 SOC, PCI DSS, HIPAA, GDPR）。EKS 本身继承这些认证，并提供 AWS Security Hub、AWS Config 等服务进行持续合规监控和配置审计。AWS Control Tower 可帮助搭建多账户合规环境。
Google Kubernetes Engine (GKE):
身份认证 (Authentication)：Google Cloud IAM： 核心组件。用户使用 Google Cloud IAM 账户（用户账户或服务账户）通过 gcloud 或 Web UI 认证到 GKE 集群。GKE 自动将 Cloud IAM 权限映射到 Kubernetes 权限。
Workload Identity： 这是 GKE 的核心安全特性。 允许 Kubernetes 服务账户直接扮演 Google Cloud IAM 服务账户。Pod 内的应用可以使用 Google Cloud 客户端库自动获取 IAM 服务账户的临时凭证，访问 GCP 服务（如 Cloud Storage, BigQuery），无需管理密钥文件。与 EKS 的 IRSA 类似，但集成更原生。
OIDC 身份提供者集成： GKE 支持配置外部 OIDC 身份提供者。
授权 (Authorization)：Kubernetes RBAC： 标准机制。
Cloud IAM 与 RBAC 结合： GKE 提供了预定义的 Cloud IAM 角色（如 container.clusterViewer, container.developer），这些角色在 GKE 层面有特定权限，并会映射到集群内的 Kubernetes RBAC 权限。用户也可以自定义 Cloud IAM 角色并精细控制其在 GKE 集群中的权限。
网络安全：VPC 防火墙规则： 如前所述，GKE 自动配置必要的防火墙规则。用户可以创建自定义的 VPC 防火墙规则来控制节点之间、节点与外部之间的流量。
网络策略： 原生支持 Kubernetes NetworkPolicy，无需额外组件。这是 GKE 的显著优势。
Cloud Armor： 集成到 External HTTP(S) Load Balancer，提供 WAF 和 DDoS 防护。
Private Google Access： 允许集群中的节点（即使没有公网 IP）通过私有网络访问 Google API 和服务。
工作负载安全：容器镜像扫描： 集成 Container Analysis / Binary Authorization。可在推送镜像到 Artifact Registry (GCR 的继任者) 时自动扫描漏洞。Binary Authorization 强制执行部署策略（如只允许签名的镜像部署）。
密钥管理： 集成 Secret Manager。通过 CSI 驱动（Secrets Store CSI Driver）或 SDK 访问。Workload Identity 是 Pod 访问 GCP 服务凭证的最佳实践。
运行时安全： Google 提供 Security Command Center，可整合 GKE 审计日志、VPC 流日志、威胁情报等，提供统一的安全态势管理和威胁检测。Cloud Security Scanner 可扫描 Web 应用漏洞。
Pod 安全策略 (PSP) / Pod 安全准入控制器 (PSA)： GKE 支持 PSP（已弃用）和 PSA。推荐使用 PSA 并结合 Policy Controller（基于 OPA/Gatekeeper 的 GKE 托管策略引擎）实施策略（如限制镜像仓库、强制标签、禁止特权容器等）。
合规性： Google Cloud 提供广泛的合规性认证（SOC, PCI DSS, HIPAA, GDPR）。GKE 继承这些认证。Cloud Asset Inventory 提供资源清单和策略分析。Assured Workloads 可帮助满足特定合规性要求（如 HIPAA）的隔离环境。
Azure Kubernetes Service (AKS):
身份认证 (Authentication)：Azure Active Directory (AAD)： 核心组件。 AKS 与 Azure AD 深度集成。用户可以使用 Azure AD 用户、组或服务主体认证到 AKS 集群。支持两种集成模式：
AAD 集成 (推荐)： 将 Azure AD 身份直接映射为 Kubernetes 用户。用户使用 az aks get-credentials 命令登录时，会触发 Azure AD 认证流程（如设备码登录），获取的凭证包含用户的 Azure AD 身份信息。Kubernetes API Server 使用 Azure AD 进行身份验证。
Azure RBAC for AKS： 将 Azure AD 身份与 Kubernetes RBAC 直接绑定。用户可以在 Azure 门户或 CLI 中，直接将 Azure AD 用户/组/服务主体分配到 Kubernetes 命名空间级别的角色（如 Azure Kubernetes Service RBAC Reader），这些角色映射到标准的 Kubernetes RBAC 角色（如 view, edit, admin）。这是 AKS 的独特优势，极大简化了权限管理。
OIDC 身份提供者集成： AKS 支持配置外部 OIDC 身份提供者。
工作负载身份 (Workload Identity)： 类似于 IRSA 和 Workload Identity。允许 Kubernetes 服务账户关联 Azure AD 应用程序（服务主体）。Pod 内的应用可以使用 Azure Identity 库自动获取 Azure AD 令牌，访问 Azure 资源（如 Key Vault, Storage）。
授权 (Authorization)：Kubernetes RBAC： 标准机制。
Azure RBAC for AKS： 如上所述，这是 AKS 的核心授权模型，将 Azure AD 身份与 Kubernetes 权限通过 Azure 平台直接绑定，管理体验统一。
网络安全：网络安全组 (NSG)： AKS 自动配置 NSG 规则保护节点和控制平面端点。用户可以创建自定义 NSG 规则进行更精细的控制。
网络策略： 通过部署 Calico/Cilium 或 Azure Network Policy 实现。
Azure Firewall / Application Gateway WAF： 集成 Azure Firewall 作为网络出口，或使用 Application Gateway 的 WAF 功能保护入口流量。
私有链接： 支持 Azure Private Link，允许通过私有端点访问 Azure PaaS 服务（如 Key Vault, SQL Database），避免流量经过公网。
工作负载安全：容器镜像扫描： 集成 Microsoft Defender for Cloud 和 Azure Container Registry (ACR)。Defender for Cloud 可在 ACR 中推送镜像时自动扫描漏洞，并提供运行时威胁防护（需在 AKS 上启用 Defender 仪表板）。
密钥管理： 集成 Azure Key Vault。通过 CSI 驱动（Secrets Store CSI Driver）将密钥/证书安全地挂载到 Pod 中，或使用 SDK 访问。工作负载身份是 Pod 访问 Azure 服务凭证的最佳实践。
运行时安全： Microsoft Defender for Cloud 是 AKS 运行时安全的核心。提供：
威胁防护：检测集群中的恶意活动（如挖矿程序、异常访问）。
漏洞评估：扫描节点和容器的漏洞。
合规性检查：评估集群配置是否符合安全基线（如 CIS Benchmark）。
数据收集：收集节点日志、容器审计日志等。
Pod 安全策略 (PSP) / Pod 安全准入控制器 (PSA)： AKS 支持 PSP（已弃用）和 PSA。推荐使用 PSA 并结合 Azure Policy for AKS。Azure Policy 提供大量内置策略（如限制特权容器、强制镜像来源、禁用主机网络等），可直接在 Azure 门户中应用到 AKS 集群，实现策略的集中管理和审计。这是 AKS 在策略管理上的显著优势。
合规性： Azure 提供广泛的合规性认证（SOC, PCI DSS, HIPAA, GDPR）。AKS 继承这些认证。Azure Policy 和 Microsoft Defender for Cloud 是核心的合规监控和强制工具。Azure Blueprints 可帮助部署符合特定合规性要求的环境。
安全体系对比总结：
| 特性 | Amazon EKS | Google GKE | Azure AKS |
| 核心身份认证 | AWS IAM Authenticator + IAM 用户/角色 | Google Cloud IAM + Workload Identity | Azure AD 集成 + Azure RBAC for AKS |
| 服务账户身份 | IAM Roles for Service Accounts (IRSA) | Workload Identity | Workload Identity |
| 授权模型 | Kubernetes RBAC + IAM 映射 | Kubernetes RBAC + Cloud IAM 预定义/自定义角色 | Kubernetes RBAC + Azure RBAC for AKS (统一管理) |
| Pod 级网络控制 | Security Groups for Pods (强) | 原生 NetworkPolicy (强) | NetworkPolicy (需额外 CNI) |
| 负载均衡器安全 | AWS WAF, Shield (ALB/NLB) | Cloud Armor (External HTTP(S) LB) | Application Gateway WAF |
| 镜像扫描 | Amazon ECR 扫描 | Container Analysis / Binary Authorization | Microsoft Defender for Cloud + ACR 扫描 |
| 密钥管理 | Secrets Manager / Parameter Store + CSI | Secret Manager + CSI | Azure Key Vault + CSI (深度集成) |
| 运行时安全 | GuardDuty, Inspector | Security Command Center | Microsoft Defender for Cloud (集成度高) |
| 策略引擎 | OPA/Gatekeeper (需自管) | Policy Controller (GKE 托管 OPA/Gatekeeper) | Azure Policy for AKS (内置策略，统一管理) |
| 合规性工具 | Security Hub, Config, Control Tower | Security Command Center, Assured Workloads | Azure Policy, Defender for Cloud, Blueprints |
| 独特优势 | Security Groups for Pods, IRSA | 原生 NetworkPolicy, Workload Identity, Policy Controller | Azure RBAC for AKS, Azure Policy, Defender 集成 |
分析：
身份认证与授权：EKS (IAM)： 与 AWS IAM 的集成非常深入，IRSA 是 Pod 访问 AWS 服务的标准。授权需要将 IAM 主体映射到 Kubernetes 用户，然后应用 RBAC，管理相对分散。
GKE (Cloud IAM)： Workload Identity 设计优雅，与 GCP 服务集成无缝。Cloud IAM 提供了预定义角色，简化了部分权限管理，但精细控制仍需 RBAC。
AKS (Azure AD)： Azure RBAC for AKS 是最大亮点。 将 Azure AD 身份与 Kubernetes 权限在 Azure 平台层面直接绑定，管理员可以在熟悉的 Azure 门户或 CLI 中统一管理集群访问权限，体验极佳，极大降低了管理复杂度。工作负载身份也完善了 Pod 访问 Azure 服务的安全模型。
网络安全：EKS： Security Groups for Pods 是独门绝技，提供了类似 VM 级别的精细化网络控制，对安全要求极高的场景非常有价值。
GKE： 原生 NetworkPolicy 开箱即用，无需额外部署和维护 CNI，是显著优势，简化了安全策略的实施。
AKS： 网络策略需要额外 CNI，但 Azure Private Link 提供了强大的私有网络访问能力。
工作负载安全：镜像扫描： 三者都提供集成的镜像扫描能力，功能接近。GKE 的 Binary Authorization 提供了更强的部署策略控制。
密钥管理： 三者都支持通过 CSI 驱动挂载密钥。Azure Key Vault 是企业级密钥管理的标杆，AKS 与其集成非常成熟。
运行时安全：EKS： GuardDuty 和 Inspector 提供威胁检测和漏洞评估，但需要用户分别配置和管理。
GKE： Security Command Center 提供统一的安全态势管理视图。
AKS： Microsoft Defender for Cloud 是 AKS 的王牌。 它将威胁防护、漏洞管理、合规性检查、数据收集整合在一个服务中，与 Azure 生态深度集成，提供仪表板、告警、修复建议，体验非常完整和强大。这是 AKS 在安全运营上的显著优势。
策略与合规：EKS： 需要自行部署和管理 OPA/Gatekeeper，灵活但运维负担重。AWS 的合规工具（Security Hub, Config）功能强大但需要整合。
GKE： Policy Controller 提供托管的 OPA/Gatekeeper，简化了策略引擎的运维。Assured Workloads 满足特定合规需求。
AKS： Azure Policy for AKS 是最大亮点。 提供大量开箱即用的内置安全策略，直接在 Azure 门户中管理、分配、审计，与 Azure 的合规框架无缝集成，极大降低了实施安全基线和满足合规要求的门槛。这是 AKS 在治理和自动化合规方面的核心优势。
2.3 可观测性：洞察集群与应用的脉搏
有效的监控、日志和追踪是保障集群稳定运行、快速排查问题、优化性能的关键。三大平台在可观测性生态上各有侧重。
Amazon EKS:
监控 (Metrics)：CloudWatch Container Insights： 官方推荐。 提供开箱即用的 EKS 集群监控能力。自动收集控制平面、节点、Pod、容器级别的性能指标（CPU、内存、磁盘、网络）。提供预置仪表板展示集群资源利用率、Pod 状态、节点健康状况等。支持设置告警。
Prometheus + Grafana： 开源事实标准。用户可以在 EKS 集群中部署 Prometheus Server（或使用托管 Prometheus 服务）收集指标，使用 Grafana 进行可视化。社区提供大量针对 Kubernetes、EKS、AWS 服务的仪表盘模板。Amazon Managed Service for Prometheus (AMP) 是 AWS 托管的 Prometheus 兼容服务，简化了 Prometheus 的运维，支持长期存储、告警、与 Grafana 集成。
指标来源： kubelet, cAdvisor, node-exporter, Kubernetes API Server Metrics, 以及通过 ServiceMonitor/PodMonitor 发现的应用自定义指标。
日志 (Logs)：CloudWatch Logs： 官方推荐。 通过部署 Fluent Bit 或 Fluentd 作为 DaemonSet，将节点、容器、Kubernetes 组件的日志发送到 CloudWatch Logs。提供强大的日志查询、过滤、分析功能。支持创建指标过滤器从日志中提取指标。支持设置基于日志的告警。
其他选项： 用户也可以选择将日志发送到第三方日志服务（如 Elasticsearch/Kibana, Splunk, Datadog）。
追踪 (Tracing)：AWS X-Ray： AWS 原生的分布式追踪服务。应用需要集成 X-Ray SDK。X-Ray Daemon 可以作为 Sidecar 或 DaemonSet 部署在 EKS 中，收集追踪数据并发送到 X-Ray 服务。提供服务地图、性能分析、错误率统计等。
开源方案： 部署 Jaeger 或 Zipkin。Amazon Managed Service for OpenTelemetry (AMOT) 是 AWS 托管的 OpenTelemetry 兼容服务，支持收集、处理、导出追踪、指标和日志数据，兼容 OpenTelemetry 协议，是未来的方向。
统一可观测性： AWS Distro for OpenTelemetry (ADOT) 是 AWS 维护的 OpenTelemetry 发行版，提供 Collector、SDK、Auto Instrumentation Agent，帮助用户在 EKS 中统一收集指标、日志、追踪数据，并发送到 AWS 服务（CloudWatch, X-Ray, AMP）或兼容的第三方后端。
Google Kubernetes Engine (GKE):
监控 (Metrics)：Cloud Monitoring (formerly Stackdriver)： 官方推荐且深度集成。 GKE 原生集成 Cloud Monitoring，自动收集控制平面、节点、Pod、容器级别的丰富指标。提供强大的预置仪表板（GKE Dashboard）、查询语言（MQL）、告警功能。支持基于 SLO 的告警。
Prometheus + Grafana： 同样是主流选择。用户可以在 GKE 中部署 Prometheus。Google Cloud Managed Service for Prometheus 是 GCP 托管的 Prometheus 兼容服务，提供与 Cloud Monitoring 类似的托管优势（长期存储、告警、Grafana 集成）。
指标来源： 与 EKS 类似，kubelet, cAdvisor, node-exporter, KSM 等。
日志 (Logs)：Cloud Logging (formerly Stackdriver Logging)： 官方推荐且深度集成。 GKE 默认启用 Cloud Logging，通过节点上的日志代理自动收集系统日志、容器日志、Kubernetes 组件日志。提供强大的日志查询、分析、基于日志的指标提取、告警功能。支持日志 sinks 将日志导出到其他地方。
其他选项： 同样支持第三方日志服务。
追踪 (Tracing)：Cloud Trace： Google Cloud 原生的分布式追踪服务。应用需要集成 OpenTelemetry 或旧版 Stackdriver Trace SDK。Cloud Trace 提供服务地图、延迟分析、采样率控制等。
开源方案： 部署 Jaeger 或 Zipkin。Google Cloud Managed Service for OpenTelemetry 是 GCP 托管的 OpenTelemetry 兼容服务，功能与 AWS AMOT 类似。
统一可观测性： Google Cloud’s operations suite (包含 Cloud Monitoring, Logging, Trace, Error Reporting, Profiler 等) 提供了高度统一和集成的可观测性体验。OpenTelemetry 是 Google 积极推动的标准，其托管服务也基于此。
Azure Kubernetes Service (AKS):
监控 (Metrics)：Azure Monitor for containers： 官方推荐且深度集成。 AKS 原生集成 Azure Monitor，通过部署在集群中的 containerized agent 收集控制平面、节点、Pod、容器级别的性能指标。提供预置的 AKS 仪表板（在 Azure 门户中）、强大的查询语言 (Kusto Query Language - KQL)、告警功能。支持基于 Prometheus 指标的收集和查询（通过配置）。
Prometheus + Grafana： 广泛使用。用户可以在 AKS 中部署 Prometheus。Azure Monitor managed service for Prometheus 是 Azure 托管的 Prometheus 兼容服务，提供与 Azure Monitor 集成的托管优势。
指标来源： kubelet, cAdvisor, node-exporter, KSM 等。
日志 (Logs)：Azure Monitor Logs： 官方推荐且深度集成。 通过 containerized agent 自动收集节点、容器、Kubernetes 组件的日志。日志存储在 Log Analytics 工作区 中，使用强大的 KQL 进行查询和分析。支持创建日志查询告警、工作簿 (Workbooks) 进行可视化分析、日志指标等。
其他选项： 支持第三方日志服务。
追踪 (Tracing)：Application Insights： Azure 的应用性能管理 (APM) 服务，包含分布式追踪能力。应用需要集成 Application Insights SDK。它提供端到端事务追踪、依赖项映射、性能分析、异常诊断等。与 Azure Monitor 深度集成。
开源方案： 部署 Jaeger 或 Zipkin。Azure Monitor managed service for OpenTelemetry 是 Azure 托管的 OpenTelemetry 兼容服务。
统一可观测性： Azure Monitor 是 AKS 可观测性的核心平台，集成了指标、日志、追踪（通过 Application Insights）、告警、工作簿、仪表板等功能。Azure Managed Grafana 提供托管的 Grafana 服务，可与 Azure Monitor 数据源无缝集成。
可观测性对比总结：
| 特性 | Amazon EKS | Google GKE | Azure AKS |
| 官方监控方案 | CloudWatch Container Insights | Cloud Monitoring | Azure Monitor for containers |
| 托管 Prometheus | Amazon Managed Service for Prometheus (AMP) | Google Cloud Managed Service for Prometheus | Azure Monitor managed service for Prometheus |
| 官方日志方案 | CloudWatch Logs (Fluent Bit/Fluentd) | Cloud Logging (内置代理) | Azure Monitor Logs (Log Analytics) |
| 官方追踪方案 | AWS X-Ray / AMOT (OpenTelemetry) | Cloud Trace / Managed OpenTelemetry | Application Insights / Managed OpenTelemetry |
| 统一平台 | CloudWatch, X-Ray, AMP, AMOT | Cloud’s operations suite (Monitoring, Logging, Trace) | Azure Monitor (Metrics, Logs, Insights) |
| 查询语言 | CloudWatch Insights Query | Monitoring Query Language (MQL) | Kusto Query Language (KQL) (强大) |
| 告警 | CloudWatch Alarms | Cloud Alerting | Azure Alerts |
| 仪表板 | CloudWatch Dashboards / Grafana | Cloud Monitoring Dashboards / Grafana | Azure Dashboards / Azure Managed Grafana |
| 集成度 | 高 (Container Insights) | 非常高 (原生集成) | 非常高 (原生集成) |
| 开源支持 | 良好 (Prometheus, Grafana, Fluentd, OpenTelemetry) | 良好 (Prometheus, Grafana, OpenTelemetry) | 良好 (Prometheus, Grafana, OpenTelemetry) |
分析：
官方方案集成度： GKE 和 AKS 在官方监控日志方案的集成度上略胜一筹。GKE 的Cloud Monitoring/Logging 和 AKS 的 Azure Monitor 都是与 Kubernetes 平台深度绑定的，配置相对简单，开箱即用性强。EKS 的 Container Insights 也很成熟，但需要部署 Fluent Bit/Fluentd 代理。
托管 Prometheus： 三大云都提供了托管的 Prometheus 兼容服务（AMP, GCP Managed Prometheus, Azure Managed Prometheus），解决了自建 Prometheus 的运维痛点（存储、高可用、扩容），是拥抱开源 Prometheus 标准的用户的理想选择。
日志查询与分析： Azure Monitor Logs 的 KQL 被广泛认为是功能最强大、表达能力最强的日志查询语言之一，尤其适合复杂的日志分析和关联查询。CloudWatch Logs 和 Cloud Logging 的查询能力也很强，但 KQL 在复杂场景下可能更具优势。
追踪：EKS： X-Ray 功能全面，但需要应用集成 SDK。AMOT (OpenTelemetry) 是未来方向。
GKE： Cloud Trace 与 GCP 生态集成好，性能分析能力强。Managed OpenTelemetry 是重点。
AKS： Application Insights 不仅是追踪工具，更是完整的 APM 解决方案，提供应用性能、异常、依赖项的全方位洞察，与 Azure DevOps 集成紧密，对 .NET 应用尤其友好。Managed OpenTelemetry 也是重点。
统一平台： GCP 的 operations suite 和 Azure Monitor 都提供了非常统一和集成的可观测性体验，在一个平台内完成指标、日志、追踪的查看、查询、告警、分析。AWS 的 CloudWatch、X-Ray、AMP 等服务虽然强大，但整合体验上稍显分散（尽管在不断改进）。
开源生态： 三者对 Prometheus、Grafana、Fluentd、OpenTelemetry 等开源工具的支持都非常好，用户有充分的自由度选择开源方案。
2.4 DevOps 与 CI/CD 集成：加速应用交付
托管 Kubernetes 集群需要与 CI/CD 流水线紧密集成，实现自动化构建、测试、部署和发布管理。三大平台及其生态提供了丰富的工具链。
Amazon EKS:
CI/CD 平台：AWS CodePipeline + CodeBuild + CodeDeploy： AWS 原生的 CI/CD 服务套件。CodePipeline 可构建包含源码获取（CodeCommit, GitHub, S3）、构建（CodeBuild）、测试、部署到 EKS（通过 CodeDeploy 或调用 kubectl/Helm）的流水线。CodeDeploy 提供蓝绿部署和金丝雀发布能力。
Jenkins： 广泛使用的开源 CI/CD 服务器。可以在 EC2 或 EKS 上运行 Jenkins Master/Agent，通过插件（如 Kubernetes Plugin, AWS ECR Plugin, AWS IAM Plugin）与 EKS 集成。
GitLab CI/CD： GitLab 内置的 CI/CD 功能，通过 Runner（可部署在 EKS 或 EC2）执行任务，支持 kubectl 和 Helm 部署到 EKS。
GitHub Actions： 通过 Marketplace 中的 Action（如 aws-actions/configure-aws-credentials, aws-actions/amazon-ecs-deploy 可适配 EKS）实现构建和部署。
部署工具：kubectl： 基础命令行工具。
Helm： Kubernetes 包管理器事实标准。用于打包、分发、部署和管理 Kubernetes 应用。EKS 完全支持 Helm 3。
Kustomize： Kubernetes 原生配置管理工具，支持模板化、差异化配置。EKS 完全支持。
Argo CD： 开源的 GitOps 持续交付工具。可在 EKS 上部署 Argo CD，实现声明式、自动化、版本化的应用部署和管理。与 EKS 集成良好。
Flux CD： 另一个流行的 GitOps 工具。同样可在 EKS 上部署使用。
镜像仓库：Amazon ECR (Elastic Container Registry)： AWS 托管的容器镜像仓库。与 EKS 深度集成，支持镜像扫描、生命周期策略、跨区域复制。通过 IAM 控制访问权限。
基础设施即代码 (IaC)：AWS CloudFormation： AWS 原生 IaC 服务，支持定义 EKS 集群、节点组、VPC 等资源。提供 EKS 资源类型。
Terraform： 流行的开源 IaC 工具，拥有成熟的 AWS Provider，广泛用于管理 EKS 集群及相关基础设施。
AWS CDK (Cloud Development Kit)： 允许使用编程语言（TypeScript, Python, Java 等）定义 AWS 基础设施，包括 EKS。提供高级抽象。
其他工具：AWS App Mesh： AWS 托管的服务网格（基于 Envoy），用于管理微服务通信。可在 EKS 上部署使用。
AWS X-Ray： 用于 CI/CD 流水线中的性能分析和问题追踪。
Google Kubernetes Engine (GKE):
CI/CD 平台：Google Cloud Build： GCP 原生的持续集成服务。可构建包含源码获取（Cloud Source Repositories, GitHub, Bitbucket）、构建（Docker 构建、测试）、部署到 GKE（通过 kubectl/Helm 或 Cloud Deploy）的触发器。支持私有 Worker Pool。
Jenkins： 同样广泛使用。可在 GCE 或 GKE 上运行，通过插件与 GKE 集成。
GitLab CI/CD： 通过 Runner（可部署在 GKE 或 GCE）执行任务。
GitHub Actions： 通过 Action（如 google-github-actions/setup-gcloud, google-github-actions/deploy-cloud-run 可适配 GKE）。
部署工具：kubectl, Helm, Kustomize： 标准工具，GKE 完全支持。
Argo CD, Flux CD： 流行的 GitOps 工具，可在 GKE 上部署使用。
Cloud Deploy： GCP 原生的持续交付服务。 专门设计用于将应用部署到 GKE、Cloud Run 等目标。支持定义交付管道、渐进式交付（金丝雀、蓝绿）、自动化推广、可视化部署状态。与 GKE 深度集成，是 GKE CI/CD 的差异化优势。
镜像仓库：Artifact Registry： GCP 统一的托管仓库服务，支持容器镜像（替代 GCR）、Helm Chart、Maven/ npm 包等。与 GKE 深度集成，支持漏洞扫描（Vulnerability Scanning）、签名（Binary Authorization）、IAM 权限控制。
基础设施即代码 (IaC)：Google Cloud Deployment Manager： GCP 原生 IaC 服务，支持定义 GKE 集群等资源。
Terraform： 拥有成熟的 GCP Provider，广泛用于管理 GKE 集群及相关基础设施。
Google Cloud CDK (Terraform)： 允许使用 TypeScript/Python 等语言定义 GCP 基础设施（基于 Terraform）。
其他工具：Anthos Service Mesh (ASM)： Google 托管的服务网格（基于 Istio），提供跨集群（GKE、On-Prem、其他云）的服务治理能力。是 GKE 企业级服务治理的核心。
Cloud Trace, Cloud Profiler： 集成到 CI/CD 流水线中进行性能分析。
Azure Kubernetes Service (AKS):
CI/CD 平台：Azure Pipelines (Azure DevOps)： Azure 原生且深度集成。 是 Azure DevOps Services 的核心组件。提供强大的可视化流水线编辑器（YAML 支持），支持构建（包括 Docker 构建、.NET 构建等）、测试、部署到 AKS（通过内置的 KubernetesManifest 任务或 kubectl/Helm 任务）。与 Azure Repos、GitHub 等源码管理集成。支持多阶段部署、审批、环境管理。
GitHub Actions： 通过 Action（如 azure/login, azure/aks-set-context, azure/k8s-deploy）实现与 AKS 的集成。
Jenkins： 可在 Azure VM 或 AKS 上运行，通过插件与 AKS 集成。
GitLab CI/CD： 通过 Runner（可部署在 AKS 或 Azure VM）执行任务。
部署工具：kubectl, Helm, Kustomize： 标准工具，AKS 完全支持。
Argo CD, Flux CD： 流行的 GitOps 工具，可在 AKS 上部署使用。
Azure DevOps 部署任务： Azure Pipelines 提供了专门用于部署到 Kubernetes 集群的任务，简化了 YAML/Helm/Kustomize 的部署流程。
镜像仓库：Azure Container Registry (ACR)： Azure 托管的容器镜像仓库。与 AKS 深度集成，支持私有链接、镜像扫描（集成 Defender for Cloud）、地理复制、内容信任（签名）、基于 Azure AD 的访问控制。可通过 Azure CLI 或门户轻松授权 AKS 集群拉取 ACR 镜像。
基础设施即代码 (IaC)：Azure Resource Manager (ARM) 模板： Azure 原生 IaC 服务，支持定义 AKS 集群、VNet 等资源。提供 AKS 资源类型。
Terraform： 拥有成熟的 AzureRM Provider，广泛用于管理 AKS 集群及相关基础设施。
Azure Bicep： Azure 的新一代领域特定语言 (DSL)，用于声明式部署 Azure 资源（包括 AKS），是 ARM 模板的简化替代方案。
其他工具：Azure Service Mesh (ASM)： Azure 托管的服务网格（基于 Istio），提供服务治理能力。可在 AKS 上启用。
Azure Monitor Application Insights： 集成到 CI/CD 流水线中进行应用性能监控和问题诊断。
DevOps 与 CI/CD 集成对比总结：
| 特性 | Amazon EKS | Google GKE | Azure AKS |
| 原生 CI/CD 平台 | AWS CodePipeline/Build/Deploy | Google Cloud Build / Cloud Deploy | Azure Pipelines (Azure DevOps) |
| GitOps 工具支持 | Argo CD, Flux CD | Argo CD, Flux CD | Argo CD, Flux CD |
| 原生部署工具 | kubectl, Helm, Kustomize | kubectl, Helm, Kustomize, Cloud Deploy | kubectl, Helm, Kustomize, Azure DevOps Tasks |
| 托管镜像仓库 | Amazon ECR | Artifact Registry | Azure Container Registry (ACR) |
| IaC 工具 | CloudFormation, Terraform, AWS CDK | Deployment Manager, Terraform, CDK (Terraform) | ARM Templates, Terraform, Azure Bicep |
| 服务网格 | AWS App Mesh (Envoy) | Anthos Service Mesh (Istio) | Azure Service Mesh (Istio) |
| 平台集成度 | 高 (CodePipeline, ECR) | 非常高 (Cloud Build/Deploy, Artifact Registry) | 非常高 (Azure Pipelines, ACR, Azure DevOps) |
| 独特优势 | 成熟的 AWS 工具链，CodeDeploy 蓝绿/金丝雀 | Cloud Deploy (渐进式交付), Artifact Registry 统一仓库 | Azure Pipelines (可视化强大), ACR 集成深度 |
分析：
原生 CI/CD 平台：EKS： AWS CodePipeline/Build/Deploy 提供了完整的原生能力，CodeDeploy 的蓝绿/金丝雀是亮点。但整体体验和功能丰富度上，与 GCP 和 Azure 的方案相比可能略显传统。
GKE： Cloud Deploy 是核心亮点。 它是 GCP 专门为 GKE 等目标设计的现代化持续交付服务，在可视化、渐进式交付（金丝雀、蓝绿）、自动化推广、部署状态追踪方面做得非常出色，代表了云原生 CD 的先进实践。Cloud Build 作为 CI 也非常成熟。
AKS： Azure Pipelines (Azure DevOps) 是最大优势。 它提供了极其强大、可视化、易用的 CI/CD 流水线编辑和管理体验（YAML 和 GUI 都支持），与 Azure 生态（Repos, ACR, Monitor）无缝集成，内置丰富的任务模板（包括 AKS 部署），支持复杂的多阶段部署、审批和环境管理。对于已经在使用 Azure DevOps 的团队，这是最自然的选择。
托管镜像仓库： ECR、Artifact Registry、ACR 都是各自平台上的优秀托管镜像仓库，功能（扫描、复制、安全控制）都非常接近。Artifact Registry 支持多种包类型是其特色。ACR 与 AKS 的集成（如通过 Azure CLI 授权拉取）非常便捷。
IaC： Terraform 是三大平台都广泛采用的通用 IaC 工具。各云的原生 IaC（CloudFormation, Deployment Manager, ARM/Bicep）也各有特点。Azure Bicep 作为 ARM 的现代替代，语法简洁，值得关注。
服务网格： AWS App Mesh (Envoy)、Anthos Service Mesh (Istio)、Azure Service Mesh (Istio) 都提供了托管的服务网格能力。Anthos Service Mesh 在跨集群、混合云治理方面经验更丰富，是其优势。
平台集成度： GKE 和 AKS 在其原生 DevOps 工具链（Cloud Build/Deploy, Azure Pipelines）与 Kubernetes 平台的集成度上达到了非常高的水平，提供了更流畅、更一体化的体验。EKS 与 AWS 工具链的集成也很成熟，但可能需要用户做更多的“胶水”工作。
2.5 无服务器与混合云扩展：超越集群边界
现代应用架构往往需要无服务器能力来处理突发流量、事件驱动任务，以及混合云/多云能力来满足合规、避免厂商锁定或利用不同云的优势。
Amazon EKS:
无服务器容器：AWS Fargate： EKS on Fargate 是核心方案。用户无需管理节点！只需定义 Pod 规格（CPU/内存），Fargate 会自动启动和管理运行 Pod 所需的基础设施（底层 EC2 实例）。按 Pod 使用的 vCPU/内存/GPU 资源秒级计费。与 EKS API 完全兼容，使用相同的控制平面。非常适合运行无状态应用、批处理任务、微服务，简化运维，优化成本（尤其对低利用率或波动的负载）。Fargate Pod 运行在 AWS 专有的 VPC 中，安全性高。
AWS Lambda： 虽然不是直接运行在 EKS 上，但 Lambda 是 AWS 无服务器的核心。可以通过 EKS 集群中的 AWS Lambda Controller 将 Kubernetes CRD 映射到 Lambda 函数，实现从 Kubernetes 触发 Lambda 函数。或者通过 API Gateway、EventBridge 等事件源触发 Lambda，Lambda 再与 EKS 中的服务交互。
混合云/多云：Amazon EKS Anywhere： 这是 AWS 的混合云/本地 Kubernetes 解决方案。 允许用户在自有数据中心（VMware vSphere, bare metal）或边缘设备上创建和管理 Kubernetes 集群，这些集群使用与 EKS 相同的发行版、工具链（如 eksctl）和 API。由 AWS 提供软件更新、安全补丁和管理工具。支持将本地集群注册到 EKS 控制平面，实现统一管理视图。目标是提供一致的混合云 Kubernetes 体验。
Amazon EKS Distro (EKS-D)： AWS 开源的 Kubernetes 发行版，与 EKS 使用的上游版本一致。用户可以下载 EKS-D，在任何地方（本地、其他云、边缘）安装和运行 Kubernetes 集群。用户需要自行管理集群的生命周期。EKS-D 是 EKS Anywhere 的基础。
第三方工具： 使用 Rancher, Anthos, Red Hat OpenShift 等第三方平台管理跨 EKS 和其他环境的集群。
Google Kubernetes Engine (GKE):
无服务器容器：GKE Autopilot： 这是 GKE 的核心无服务器模式。 如前所述，用户完全无需管理节点，按 Pod 资源付费。Autopilot 不仅仅是无服务器节点，它是一种全新的托管模式，管理整个集群的生命周期（控制平面+节点），自动优化资源利用率和成本。是 GKE 在无服务器领域的旗舰产品。
Cloud Run： Google Cloud 的无服务器容器平台。虽然不是直接运行在 GKE 集群上，但 Cloud Run 与 GKE 集成紧密：
可以将 Cloud Run 服务部署到 GKE 集群（通过 Cloud Run on GKE），利用 GKE 的网络和安全策略。
GKE 中的应用可以轻松调用 Cloud Run 服务。
Cloud Run 专注于 HTTP 请求驱动的无状态工作负载，提供极致的自动扩缩容（从 0 到 N）和按请求计费。
Cloud Functions： Google Cloud 的无服务器函数计算。可以通过事件（如 Pub/Sub, Cloud Storage）触发，与 GKE 服务交互。
混合云/多云：Anthos： 这是 Google 的混合云/多云平台旗舰。 Anthos 是一个产品组合，核心是：
Anthos clusters： 允许用户在 Google Cloud (GKE)、本地数据中心（VMware, bare metal）、其他公有云（AWS, Azure - 通过 Anthos clusters on AWS/Azure）上创建和管理统一的 Kubernetes 集群。提供统一的控制平面（GKE On-Prem/Anthos clusters on AWS/Azure 的控制平面运行在用户环境或 GCP）、统一的策略管理（Anthos Policy Controller）、统一的服务网格（Anthos Service Mesh）、统一的配置管理（Anthos Config Management）。
Anthos Config Management： 基于 GitOps 的集群配置管理工具，确保跨集群配置一致性。
Anthos Service Mesh： 跨集群的服务治理。
Cloud Run for Anthos： 在 Anthos 管理的本地集群上运行 Cloud Workloads。
Google Kubernetes Engine Enterprise (GKE Enterprise)： Anthos 的核心能力现在打包在 GKE Enterprise 中，提供企业级的混合云/多云 Kubernetes 解决方案。
GKE on-prem： Anthos clusters 的前身，用于在本地部署 GKE。
Azure Kubernetes Service (AKS):
无服务器容器：Azure Container Instances (ACI)： AKS 的核心无服务器扩展。 通过 虚拟节点 (Virtual Nodes) 功能，AKS 集群可以在需要时将 Pod 调度到 ACI 中运行。ACI 提供秒级启动的容器实例，按秒计费。非常适合处理突发流量、批处理作业、CI/CD 运行器等场景。Pod 运行在 ACI 上，但网络与 AKS 节点池互通，通过 ACI Connector 实现与 VNet 的集成。ACI 是 AKS 无服务器能力的主要体现。
Azure Container Apps (ACA)： 这是 Azure 新一代的无服务器容器平台。 虽然不是直接运行在 AKS 集群上，但 ACA 提供了更强大的无服务器容器能力：
支持 HTTP 请求驱动和事件驱动（Dapr 集成）。
内置 KEDA (Kubernetes Event-driven Autoscaling) 能力，支持基于多种指标（队列长度、Kafka lag 等）的自动扩缩容。
支持微服务、Dapr 分布式应用运行时。
提供 revision、流量分割等高级部署模型。
ACA 可以看作是 ACI 和 Azure Functions 的进化版，定位更偏向于构建完整的无服务器微服务应用。AKS 应用可以与 ACA 服务交互。
Azure Functions： Azure 的无服务器函数计算。可通过事件触发，与 AKS 服务交互。
混合云/多云：Azure Arc enabled Kubernetes： 这是 Azure 的混合云/多云管理平台。 Azure Arc 允许用户将任何地方的 Kubernetes 集群（包括本地数据中心、其他公有云如 AWS/GCP、边缘设备上的 AKS、EKS、GKE、自建 K8s 等）连接（attach） 到 Azure Arc。连接后，用户可以在 Azure 门户中：
统一查看和管理这些集群的清单、配置、工作负载。
应用 Azure Policy（包括用于 Kubernetes 的策略）进行治理和合规。
使用 Azure Monitor for containers 进行监控。
部署 Azure 服务（如 Azure SQL Edge, Azure Machine Learning）到这些集群。
使用 GitOps（通过 Azure Arc-enabled Kubernetes 配置）进行集群配置管理。
Azure Stack HCI： Azure 的超融合基础设施解决方案。可以在 Azure Stack HCI 上部署和管理 AKS on Azure Stack HCI，提供本地化的 AKS 体验，并与 Azure Arc 集成进行统一管理。
Azure Stack Hub： Azure 的混合云平台，可在本地运行 Azure 服务。支持在 Azure Stack Hub 上部署 AKS 引擎（用于部署和管理 Kubernetes 集群的工具）。
第三方工具： 同样支持 Rancher, Anthos, OpenShift 等。
无服务器与混合云扩展对比总结：
| 特性 | Amazon EKS | Google GKE | Azure AKS |
| 核心无服务器容器 | EKS on Fargate (Pod 级无服务器) | GKE Autopilot (集群级无服务器) | Azure Container Instances (ACI) (通过虚拟节点) |
| 其他无服务器容器 | AWS Lambda (需集成) | Cloud Run (HTTP 驱动), Cloud Functions | Azure Container Apps (ACA) (事件驱动), Azure Functions |
| 混合云/多云平台 | EKS Anywhere (本地/边缘) / EKS-D (开源) | Anthos / GKE Enterprise (跨云/本地) | Azure Arc enabled Kubernetes (连接任意 K8s) |
| 本地部署方案 | EKS Anywhere (vSphere, bare metal) | Anthos clusters (VMware, bare metal, AWS/Azure) | AKS on Azure Stack HCI, AKS Engine (Azure Stack Hub) |
| 统一管理 | EKS Anywhere 控制面板 (需注册) | Anthos/GKE Enterprise 控制平面 | Azure Arc (在 Azure 门户统一管理) |
| 统一策略/治理 | 需借助 AWS Config/Security Hub 或第三方 | Anthos Policy Controller | Azure Policy (通过 Azure Arc 应用) |
| 统一监控 | CloudWatch (需配置) | Cloud Monitoring (需配置) | Azure Monitor (通过 Azure Arc 启用) |
| 独特优势 | Fargate Pod 级别隔离，EKS Anywhere 体验一致 | Autopilot 集群级自动化，Anthos 跨云治理成熟 | Azure Arc 连接任意 K8s，ACA 事件驱动无服务器 |
分析：
无服务器容器：EKS： Fargate 提供了 Pod 级别的无服务器体验，隔离性好，非常适合运行需要强隔离或独立计费的工作负载。但 Fargate 仅支持 Pod，不提供集群级别的自动化管理（如控制平面升级、节点池管理仍需用户关注 EKS 集群本身）。
GKE： Autopilot 是革命性的。 它将无服务器理念提升到整个集群层面，用户不仅无需管理节点，也无需关心控制平面升级、节点池配置、容量规划等所有底层细节，平台全权负责并自动优化。这是 GKE 在无服务器领域的最大差异化优势，提供了极致的简化和潜在的效率提升。Cloud Run 则是 HTTP 工作负载的绝佳补充。
AKS： ACI 通过虚拟节点提供了 Pod 级别的无服务器扩展能力，是处理突发流量的有效手段。Azure Container Apps (ACA) 是 AKS 生态的重要补充和未来方向。 ACA 提供了比 ACI 更强大的无服务器容器平台能力，特别是内置 Dapr 和 KEDA 支持，使其非常适合构建事件驱动的微服务应用。ACA 代表了 Azure 在无服务器应用平台上的演进。
混合云/多云：EKS： EKS Anywhere 提供了在本地运行与 EKS API/工具链一致的 Kubernetes 集群的能力，体验统一是其核心价值。EKS-D 提供了开源基础。但 EKS Anywhere 主要专注于本地/边缘，对跨其他公有云的支持相对有限（主要依赖第三方工具）。
GKE： Anthos/GKE Enterprise 是混合云/多云领域的领导者。 它提供了最完整、最成熟的跨云（GCP, AWS, Azure）、本地（VMware, bare metal）的 Kubernetes 统一管理平台，包括统一控制平面、统一策略、统一服务网格、统一配置管理。对于需要深度跨云治理和一致性的企业，Anthos 是强有力的选择。
AKS： Azure Arc 的核心优势在于其“连接”而非“接管”的理念。 它允许用户将现有的、运行在任何地方的 Kubernetes 集群（包括竞争对手云上的 EKS/GKE）连接到 Azure 进行统一的管理、治理、监控和应用部署，而无需改变集群的底层运行方式或控制平面。这种轻量级、非侵入式的连接方式，对于已经拥有复杂异构 Kubernetes 环境的企业来说，具有极大的吸引力。Azure Arc 的覆盖范围和灵活性是其最大亮点。AKS on Azure Stack HCI 则提供了本地化的 AKS 体验。