4.2 KiB
title, type, source-type, category, tags, date-added, video-source, audio-source, status
| title | type | source-type | category | tags | date-added | video-source | audio-source | status | |||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| CTP Topic 64 Scaling out with Amazon EKS | cloud-learning | video | DevOps & SRE/04_EKS |
|
2026-04-14 | nas:///volume2/work/Public Cloud Learning Sessions/CTP _ Topic 64_ Scaling out with Amazon EKS.mp4 | summarized (Gemini 摘要) |
CTP Topic 64 Scaling out with Amazon EKS
Source: NAS /volume2/work/Public Cloud Learning Sessions/CTP _ Topic 64_ Scaling out with Amazon EKS.mp4
Type: VIDEO | Category: 04_EKS
Status: 🟡 Awaiting Whisper transcription → Summary
摘要
Scaling Out with Amazon EKS
The 64th Cloud Transformation Program session covers scaling out with Amazon EKS, with a special guest presenter from AWS. The session is interactive and encourages questions, with a survey link to be shared for feedback.
Suravpul, a senior solutions architect from AWS, discusses scaling workloads using the horizontal pod autoscaler (HPA), event-driven autoscaling with KEDA, capacity autoscaling (cluster autoscaler and Carpenter), addressing IP exhaustion, and scaling cluster components like DNS.
The horizontal pod autoscaler (HPA) is the standard Kubernetes mechanism for scaling application workloads, using metrics to determine replica requirements. It supports CPU and memory utilization out of the box via a metrics server. Custom and external metrics, such as those from load balancers or messaging middleware, can also be used. 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. The speaker notes that the gap between the target threshold and 100% utilization is important, and addresses flapping via period seconds and stabilization window seconds settings. HPA currently considers resource consumption only at the pod level, not at the container level.
KEDA allows scaling application workloads based on external events, using a custom resource definition called a scaled object. It can scale applications from zero replicas, or publish metrics for the horizontal pod autoscaler to use.
Capacity autoscaling can be achieved using Fargate or EC2 instances. For EC2 instances, cluster autoscaler or Carpenter can be used. Cluster autoscaler is tied to auto scaling groups and node groups, updating the desired capacity of the auto scaling group based on the number of pending pods. It considers CPU and memory requests, and supports mixed instances policies. The scaling decision that is made by the cluster auto scaler, it is done on the number of pending pods in the cluster. Auto-discovery is recommended, and changes to min/max configuration should be made at the managed node group or auto scaling group level.
Carpenter is an open-source Kubernetes native capacity auto scaler that directly interacts with the EC2 API, offering dynamic on-demand provisioning and improved speed. It does not depend on pre-configured node groups or auto scaling groups. Carpenter uses the concept of a provisioner to define requirements for EC2 instances, matched with workload requirements using node selectors and affinity terms. Reclamation is disabled by default, so TTL or cluster consolidation must be enabled. Carpenter is recommended for clusters with varying capacity and workload requirements.
To address IP exhaustion, switching to IPv6 addressing is recommended. If not possible, custom networking can be used with carrier-grade NAT. For IPv6, a dual-stack VPC is recommended, with nodes supporting dual-stack IP addresses but pods having only IPv6 addresses. Interaction between IPv6 pods and IPv4 destinations is configured by utilizing matting at two different layers.
Additional considerations for scaling include enabling API server priority and fairness metrics, enabling caching and disabling compression, removing underutilized nodes, and limiting scaling spikes. Scaling the DNS component (CoreDNS) and installing node local DNS cache are also important.
The presentation concludes by recommending the EKS best practices guides, specifically the scalability section.
关键概念
行动项
相关视频
配对视频笔记链接（生成后填入）
最后更新: 2026-04-14