当 AI/ML 负载把集群推到万节点级别时，EKS 需要同时扛住海量 API 请求、持续的调度压力以及成千上万节点的镜像拉取。本文梳理在超大规模场景下最常见的瓶颈点，并整理社区通用优化与 AWS 的特有改进，给出可落地的实施路径与监控清单。
一、超大规模场景的核心挑战
- API Server 压力：在数百万级请求下，读取与写入会直接放大 etcd 压力。
- etcd 性能与存储后端：写入密集型场景容易触发一致性与延迟瓶颈。
- 镜像分发：数千节点并发拉取镜像时容易造成带宽和仓库压力。
- 调度效率：大规模 Pod 调度对调度器吞吐和队列设计要求极高。
- 可观测性：监控、日志与事件在规模提升后会产生指数级压力。
二、AWS 规模下的性能 SLO 目标
- API Server GET/PUT 请求延迟：p99 < 1 秒
- LIST 请求延迟：< 30 秒
- 调度器吞吐：约 500 pods/秒
三、社区通用优化（云厂商无关）
1. 一致性读取缓存（Kubernetes v1.33）
大规模集群下，如果每次 API 读取都打到 etcd，将很快遇到性能上限。Kubernetes v1.33 引入的一致性读取缓存改进，使更多读取可以直接从缓存返回，同时保持一致性保证。
- 基于 watch 的缓存与 etcd 实时同步
- 资源版本机制保证一致性
- 显著降低 etcd 读压力
2. 节点弹性与调度优化
- Cluster Autoscaler：传统节点组扩容方案，稳定但响应较慢。
- Karpenter：事件驱动的快速扩容，更适合大规模动态负载。
- Koordinator：提供更细粒度的 QoS 与资源隔离策略。
- Volcano：面向 AI/ML 的批处理调度能力更强。
3. 镜像启动加速
大规模拉镜像会导致启动延迟倍增。社区常见方案包括 Nydus、Stargz 和 Dragonfly 等懒加载/分发机制，显著降低冷启动时的镜像拉取成本。
四、AWS EKS 的特有优化
1. etcd 后端：Amazon QLDB Journal
标准 etcd 使用 Raft 共识在超大规模下可能成为写入瓶颈。AWS 的实践是将 etcd 写入落到 QLDB Journal，以获得更高吞吐与更低运维复杂度。
| 维度 | 标准 etcd | Amazon QLDB Journal |
|---|---|---|
| 共识/持久化 | Raft 共识写入 | 托管账本日志 |
| 写入吞吐 | 受 Raft 限制 | 更高吞吐 |
| 运维成本 | 自管集群 | AWS 托管 |
2. 镜像分发：SOCI + ECR
AWS 推荐使用 SOCI（Seekable OCI）结合 ECR 进行镜像懒加载，使节点按需拉取镜像块，缩短冷启动时间并降低峰值带宽。
3. CoreDNS 自动扩容与 NodeLocal DNSCache
DNS 查询量随着规模增长非常明显。建议按节点规模自动扩容 CoreDNS，同时开启 NodeLocal DNSCache 分担查询压力。
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: coredns
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: coredns
minReplicas: 2
maxReplicas: 100
metrics:
- type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 504. LWS + vLLM：面向大模型推理的组合
在大规模 LLM 推理场景下，AWS 推荐使用 LeaderWorkerSet（LWS）来管理 leader-worker 拓扑，同时配合 vLLM 获得更高吞吐与更稳定的推理性能。
五、AWS vs GKE vs 社区方案对比
| 优化项 | AWS EKS | Google GKE | 社区/私有化 |
|---|---|---|---|
| 存储后端 | QLDB Journal | Spanner | Kine + MySQL/PG、TiKV + KubeBrain |
| 读缓存优化 | 一致性读取缓存（v1.33） | 一致性读取缓存（v1.33） | 一致性读取缓存（v1.33） |
| 镜像加速 | SOCI + ECR | gcr.io 优化 | Nydus / Dragonfly |
| 节点供给 | Karpenter | GKE Autopilot | Cluster Autoscaler（含 Karpenter） |
| DNS 扩展 | CoreDNS 自动扩容 + NodeLocal | 自定义策略 | NodeLocal DNSCache |
| 目标规模 | 万节点级 | 13 万+ 节点 | 5 千节点（默认） |
六、落地实施建议
- 先上社区通用优化：启用一致性读取缓存、选择合适的弹性扩容方案、部署镜像懒加载。
- 再叠加平台特性：在 EKS 使用 SOCI 与托管 etcd 后端，GKE 侧使用原生优化能力。
- 私有化场景：评估 TiKV、Kine 等后端替代方案，减少 etcd 压力。
- 监控先行：把 SLI 设为准入门槛，防止在规模上去后“盲飞”。
七、关键 SLI / 监控清单
- API Server p99 延迟（GET/PUT < 1s）
- etcd 写入延迟与磁盘 I/O
- 调度器吞吐（pods/s）
- DNS 查询延迟与失败率
- 镜像拉取耗时与失败率
总结
万节点级别的 EKS 集群已经在 AI/ML 场景中被验证可行，但前提是把“读缓存、存储后端、镜像分发、调度策略和 DNS 扩展”作为同等重要的工程问题来处理。建议从社区通用优化起步，再逐步叠加平台特性，并通过可观测性闭环来稳住规模增长下的性能与稳定性。
