Update nexus: fix conflicts and sync local changes
This commit is contained in:
Shen Wei
@@ -1,64 +1,64 @@
|
||||
---
|
||||
title: "CTP Topic 64 Scaling out with Amazon EKS"
|
||||
type: source
|
||||
tags: [AWS, EKS, Kubernetes, Scaling, HPA, KEDA, Karpenter, Cluster-Autoscaler]
|
||||
sources: [ctp-topic-64-scaling-out-with-amazon-eks]
|
||||
last_updated: 2026-04-25
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/04_EKS/ctp-topic-64-scaling-out-with-amazon-eks.md]]
|
||||
|
||||
## 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 是扩缩容深化
|
||||
---
|
||||
title: "CTP Topic 64 Scaling out with Amazon EKS"
|
||||
type: source
|
||||
tags: [AWS, EKS, Kubernetes, Scaling, HPA, KEDA, Karpenter, Cluster-Autoscaler]
|
||||
sources: [ctp-topic-64-scaling-out-with-amazon-eks]
|
||||
last_updated: 2026-04-25
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/04_EKS/ctp-topic-64-scaling-out-with-amazon-eks.md]]
|
||||
|
||||
## 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 是扩缩容深化
|
||||
|
||||
Reference in New Issue
Block a user