Khi tải tăng, cần thêm cả bản sao của ứng dụng (Pod hoặc task) lẫn node để chạy các bản sao đó; hai việc này diễn ra ở hai tầng riêng biệt.

Trong đợt khuyến mãi, lưu lượng vào service web của MFTECH tăng gấp nhiều lần. Việc mở rộng diễn ra ở hai tầng tách biệt:

• Tầng ứng dụng (số Pod hoặc số task). Trên EKS, Horizontal Pod Autoscaler (HPA) thay đổi số Pod của Deployment để giữ CPU quanh target (ví dụ 50%). HPA là API resource có sẵn của Kubernetes, chỉ cần một nguồn metric như Kubernetes Metrics Server. Trên ECS, Service Auto Scaling thay đổi desired count của service (target tracking, step scaling, scheduled, predictive, hoặc theo backlog của hàng đợi SQS).
• Tầng hạ tầng (số node). Trên EKS dùng node EC2, Cluster Autoscaler điều chỉnh desired capacity của Auto Scaling group khi có Pod không lập lịch được; Karpenter và EKS Auto Mode (xây dựng trên Karpenter) tạo node mới khi Pod không vừa với các node hiện có. Với Fargate, tầng này không tồn tại: mỗi task hoặc Pod được cấp tài nguyên riêng.

Chạy thử từng cấu hình và quan sát số Pod, số node, Pod Pending:

Hai điểm rút ra từ mô phỏng. Thứ nhất, HPA chỉ tăng số Pod; khi node hết CPU, Pod mới ở trạng thái Pending và số node giữ nguyên cho tới khi có Cluster Autoscaler (hoặc Karpenter). Một CloudWatch alarm theo CPU trung bình của node không nhìn thấy Pod Pending, nên không thay thế được Cluster Autoscaler. Thứ hai, CPU và memory của task Fargate khai báo ở task level trong task definition; muốn thay đổi phải tạo task definition revision mới và cập nhật service. Một task đơn lẻ vẫn là điểm nghẽn và không có dự phòng; ECS mở rộng theo chiều ngang bằng cách thêm task sau ALB.

When load rises, you need more copies of the application (Pods or tasks) and more nodes to run those copies; the two happen at separate layers.

During a sale, traffic to MFTECH’s web service grows several times over. Scaling happens in two separate layers:

• The application layer (number of Pods or tasks). On EKS, the Horizontal Pod Autoscaler (HPA) changes the number of Pods in a Deployment to keep CPU near a target (for example 50%). The HPA is a standard Kubernetes API resource; it only needs a metrics source such as the Kubernetes Metrics Server. On ECS, Service Auto Scaling changes the service’s desired count (target tracking, step scaling, scheduled, predictive, or based on an SQS queue backlog).
• The infrastructure layer (number of nodes). On EKS with EC2 nodes, the Cluster Autoscaler adjusts the Auto Scaling group’s desired capacity when Pods cannot be scheduled; Karpenter and EKS Auto Mode (built on Karpenter) create new nodes when Pods do not fit on the existing ones. With Fargate this layer does not exist: each task or Pod gets its own capacity.

Try each setup and watch the number of Pods, nodes and Pending Pods:

Two lessons from the simulation. First, the HPA only adds Pods; when nodes run out of CPU, new Pods stay Pending and the node count stays the same until a Cluster Autoscaler (or Karpenter) is in place. A CloudWatch alarm on the nodes’ average CPU cannot see Pending Pods, so it does not replace the Cluster Autoscaler. Second, a Fargate task’s CPU and memory are set at the task level in the task definition; changing them takes a new task definition revision and a service update. A single task remains a bottleneck with no redundancy; ECS scales horizontally by adding tasks behind an ALB.