6.8 KiB
6.8 KiB
title, type, tags, sources, last_updated
| title | type | tags | sources | last_updated | |||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| CTP Topic 64 Scaling out with Amazon EKS | source |
|
|
2026-04-25 |
Source File
Summary（用中文描述）
- 核心主题：Amazon EKS 工作负载水平扩展与容量扩展的完整方法论，涵盖 Pod 级别扩展（事件驱动 + 指标驱动）和 Node 级别扩展（ASG 联动 + 直接 API）
- 问题域：传统 HPA 仅支持 CPU/内存指标，无法满足事件驱动型工作负载的零扩展需求；Cluster Autoscaler 依赖预配置 ASG 导致灵活性不足；EKS 集群 IP 地址耗尽问题；CoreDNS 等集群组件扩缩容被忽视
- 方法/机制：HPA（标准指标扩展）→ KEDA（事件驱动扩展）→ Cluster Autoscaler（ASG 联动扩缩容）→ Karpenter/Carpenter（直接 API 扩缩容）→ IPv6 解决 IP 耗尽 → API Server PPF + CoreDNS 缓存优化集群稳定性
- 结论/价值：EKS 扩缩容需 Pod 层（KEDA）和 Node 层（Karpenter/Carpenter）双管齐下，HPA 负责 Pod 副本数调节，容量层通过原生云工具或第三方工具解决 IP 耗尽问题，集群组件扩缩容是生产部署常被忽视但至关重要的环节
Key Claims（用中文描述）
- HPA 通过拉取 Metrics Server 的 CPU/内存指标计算应用工作负载所需的 Pod 副本数，默认支持标准资源指标，自定义/外部指标（如负载均衡器并发连接数、消息中间件队列深度）可通过 Custom Metrics API 扩展
- KEDA 通过 ScaledObject CRD 实现事件驱动扩缩容，可将应用从零副本扩展，支持 Publishes Metrics 模式为 HPA 供数，实现指标驱动与事件驱动的混合扩展
- Cluster Autoscaler 的扩缩容决策基于集群内 Pending Pod 的数量，联动 ASG/托管节点组调整期望容量，同时考虑 Pod 的 CPU/内存 requests，支持 Mixed Instances Policy，推荐使用 Auto-discovery 模式，min/max 配置变更应在 ASG/托管节点组层面操作
- Karpenter 是 AWS 开源的 Kubernetes 原生容量扩缩器，直接与 EC2 API 通信，支持动态按需供给（无需预配置节点组），通过 Provisioner 定义 EC2 实例需求并与工作负载的 node selector/affinity 匹配，默认禁用回收（需启用 TTL 或集群整合）
- 为解决 IP 地址耗尽问题，推荐切换至 IPv6（双栈 VPC，节点双协议栈，Pod 仅 IPv6）；若无法切换，可使用 Carrier-Grade NAT（CGNAT）配合自定义网络；IPv6 Pod 与 IPv4 目标的交互通过双层 NAT 映射配置
- CoreDNS 扩缩容和 Node Local DNS Cache 安装是 EKS 生产部署的重要优化项
Key Quotes
"The horizontal pod autoscaler is going to pull the metrics and it is going to calculate how many replicas are required for your application workload." — HPA 的核心机制：拉取指标 → 计算所需副本数
"The scaling decision that is made by the cluster auto scaler, it is done on the number of pending pods in the cluster." — Cluster Autoscaler 的决策依据：Pending Pod 数量
"Carpenter has native integration with Kubernetes and it complements the native Kubernetes spot pod scheduling constraints that is available for your workloads." — Karpenter/Carpenter 与原生 K8s Spot Pod Disruption Budget 的互补关系
"The EKS best practices guides, specifically the scalability section." — 演讲者推荐的学习资源：EKS Best Practices Guides
Key Concepts
- Horizontal Pod Autoscaler (HPA)：Kubernetes 标准 Pod 水平扩缩容机制，通过 CPU/内存指标或自定义/外部指标计算副本需求，支持 stabilization window 和 period seconds 配置防止震荡
- KEDA（Kubernetes Event-Driven Autoscaling）：基于外部事件驱动的 K8s 扩缩容框架，通过 ScaledObject CRD 定义扩缩规则，支持从零副本扩展，可 Publish Metrics 给 HPA 实现混合扩展模式
- Cluster Autoscaler：Kubernetes 官方节点扩缩容组件，联动 AWS ASG/托管节点组，根据 Pending Pod 数量和资源 requests 调整 Node 数量，推荐 Auto-discovery 模式
- Karpenter：AWS 开源的 Kubernetes 原生容量扩缩器，直接与 EC2 API 通信，通过 Provisioner 匹配工作负载需求，支持动态按需供给，默认禁用回收（需启用 TTL 或 Consolidation）
- IPv6-in-EKS：EKS 集群解决 IP 地址耗尽的方案，推荐双栈 VPC 架构（节点双协议栈，Pod 仅 IPv6），IPv6 Pod 与 IPv4 目标通过 NAT 映射通信
- API-Server-Priority-and-Fairness：EKS API Server 的优先级和公平性配置，用于在高负载下保护关键工作负载的 API 访问
- CoreDNS-Scaling：EKS 集群 CoreDNS 的水平扩缩容策略，配合 Node Local DNS Cache 降低 DNS 查询延迟
- Metrics-Server：Kubernetes 的 CPU/内存指标采集组件，HPA 依赖其提供标准资源指标
Key Entities
- Suravpul：AWS 高级解决方案架构师（Senior Solutions Architect），CTP Topic 64 和 Topic 59、Topic 67 的讲师，专注 EKS 可靠性、可观测性和扩缩容实践
- Amazon EKS：托管 Kubernetes 服务，本 Source Page 的目标平台
- AWS：Amazon Web Services，EKS 及相关扩缩容工具（KEDA、Karpenter）的云服务提供商
- Kubernetes：开源容器编排平台，HPA、Cluster Autoscaler、KEDA 的上游项目
Connections
- ctp-topic-59-achieving-reliability-with-amazon-eks ← 相关 ← Horizontal Pod Autoscaler (HPA)（Topic 59 涵盖 HPA 和 VPA 在 EKS 可靠性中的作用）
- ctp-topic-70-eks-deployment-using-iac ← 相关 ← Cluster Autoscaler（Topic 70 提及 Cluster Autoscaler 实现 Worker Node 自动扩缩容）
- ctp-topic-70-eks-deployment-using-iac ← depends_on ← ctp-topic-64-scaling-out-with-amazon-eks（扩缩容是 IaC 部署后的运维关注点）
- public-cloud-learning-sessions-eks-optimization-part-1-of-3-compute-optimization ← 关联 ← Karpenter（Part 1 深度对比 Karpenter 与 Cluster Autoscaler）
- public-cloud-learning-sessions-eks-optimization-part-3-of-3-introduction-to-eks ← 关联 ← Karpenter（Part 3 介绍 EKS Auto Mode，内置 Karpenter Controller）
- ctp-topic-67-cloud-native-observability-using-opentelemetry ← 相关 ← Suravpul（同一讲师的可观测性专题）
Contradictions
- 与 ctp-topic-70-eks-deployment-using-iac 无实质冲突：
- 冲突点：无
- 当前观点：Topic 64 提供扩缩容的完整方法论（HPA/KEDA/Carpenter + IPv6 解决 IP 耗尽）
- 对方观点：Topic 70 仅简述 Cluster Autoscaler 实现 Worker Node 自动扩缩容，侧重 IaC 部署流程
- 注：两者互补而非冲突，Topic 70 是部署入口，Topic 64 是扩缩容深化