2. 公有云Kubernetes集群选型与架构设计
在公有云上落地Kubernetes，第一步不是写YAML，而是做选型与架构决策。托管Kubernetes服务把控制平面（API Server、etcd、调度器、控制器管理器）交给云厂商运维，用户只需为工作节点和网络、存储等资源负责。但“托管”并不意味着可以跳过架构设计——恰恰相反，控制平面被托管后，可用区分布、节点池划分、网络模型和存储类型的选择，才是决定集群可靠性与成本的核心变量。
主流托管Kubernetes服务对比
国内生产环境常见的选择包括阿里云ACK、腾讯云TKE、华为云CCE，海外则以AWS EKS、Azure AKS、Google GKE为主。它们的共同点是控制平面高可用、与云上IAM和VPC深度集成；差异主要体现在网络插件、节点池能力、计费方式和生态工具上。
| 服务 | 控制平面 | 默认网络模型 | 节点池/弹性 | 典型适用场景 |
|---|---|---|---|---|
| 阿里云 ACK | 多可用区托管，SLA 99.95% | Terway（基于ENI）或Flannel | 节点池+弹性伸缩，支持ECI虚拟节点 | 中大型业务、需与VPC网络直通 |
| 腾讯云 TKE | 多可用区托管 | Global Router 或 VPC-CNI | 节点池+弹性伸缩，支持超级节点 | 游戏、互联网业务弹性场景 |
| 华为云 CCE | 多可用区托管 | VPC-CNI / 容器隧道 | 节点池+弹性伸缩 | 政企、混合云场景 |
| AWS EKS | 跨3可用区托管 | VPC-CNI（默认） | 托管节点组+Auto Mode | 海外业务、深度AWS生态 |
选型时优先看三点：网络模型是否与现有VPC规划兼容、节点池能否按业务隔离、以及是否支持你需要的GPU或裸金属机型。例如需要Pod直接使用VPC IP、与数据库同网段互通时，Terway或VPC-CNI比Overlay网络更合适；而如果只是内部微服务通信，Overlay可以节省IP并简化规划。
集群拓扑与多可用区部署
生产集群必须跨可用区部署。假设选择3个可用区（AZ-A、AZ-B、AZ-C），控制平面由云厂商自动分布，工作节点则通过节点池的可用区配置来分散。推荐做法是：每个可用区至少放一个通用节点池，副本数≥2的业务通过Pod反亲和性（podAntiAffinity）或拓扑分布约束（topologySpreadConstraints）打散到不同可用区。
下面这张图展示了一个典型的跨3可用区托管集群拓扑：控制平面由云厂商托管并跨AZ高可用，工作节点按可用区分池，业务Pod通过拓扑约束均匀分布，同时通过内网SLB和云盘/对象存储接入外部依赖。
图中每个可用区都部署了通用节点池和业务节点池，业务Pod的三个副本分别落在AZ-A、AZ-B、AZ-C。这样即使单个可用区故障，仍有2/3副本存活，配合PodDisruptionBudget和就绪探针，服务可以继续对外提供。需要注意的是，跨可用区通信会产生流量费用和少量延迟，对延迟敏感的有状态服务（如Redis主从）应尽量让主从同区或使用云厂商的跨区高可用方案。
网络与存储选型
网络选型要回答两个问题：Pod用什么IP、Service怎么暴露。以阿里云ACK为例，Terway模式下Pod直接使用VPC ENI IP，与ECS、RDS同网段互通，适合需要Pod直连数据库或做网络策略精细控制的场景；Flannel Overlay模式则用独立网段，节省VPC IP但需要NAT转发。Service层面，ClusterIP用于集群内访问，NodePort用于临时调试，生产对外统一走LoadBalancer类型Service或Ingress+SLB。
存储选型按数据特征分三类：临时数据用emptyDir；需要跨Pod共享的用NAS；对IOPS和延迟敏感的有状态服务（如MySQL、Kafka）用ESSD云盘，并通过StorageClass动态供给。下面是一个StorageClass的示例配置：
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: alicloud-disk-essd
provisioner: diskplugin.csi.alibabacloud.com
parameters:
type: cloud_essd
fstype: ext4
reclaimPolicy: Retain
allowVolumeExpansion: true
volumeBindingMode: WaitForFirstConsumer其中volumeBindingMode: WaitForFirstConsumer很关键——它让PV等到Pod调度后再创建，从而保证云盘与Pod在同一可用区，避免因跨区挂载失败导致Pod一直Pending。这是生产环境最常见的存储踩坑点之一。
最后，集群创建后应立即配置：节点自动修复、集群审计日志、关键组件监控告警、以及命名空间级别的ResourceQuota。这些不是“以后再说”的优化项，而是生产集群从第一天起就应具备的基线能力。