[EKS] Ensure ASG Max Size Reverts to Original Value After EKS Upgrade Workflow with Cluster Autoscaler
- Dominant language
- Shell
- Stars
- 5.4k
- Forks
- 334
- PR merge metrics
- No merged PRs in 30d
Description
Description:
During an EKS managed node group (MNG) upgrade, the Auto Scaling Group (ASG) max size can temporarily increase as part of the upgrade workflow. However, if the Cluster Autoscaler (CA) triggers scale-up activities during the upgrade process (especially during the scale-down phase), the ASG max size is not reverted to its original value after the upgrade completes. This results in unpredictable increases in the ASG max size, creating operational challenges and deviating from the documented behavior.
Expected Behavior:
The EKS upgrade workflow should ensure that the ASG max size is always reverted to its original value after the upgrade completes, even if the Cluster Autoscaler scales up the node group during the upgrade process.
This behavior should align with the documented logic for temporary ASG max size increases during the scale-up phase (e.g., twice the number of availability zones or based on the maxUnavailable value).
Current Behavior:
If the Cluster Autoscaler triggers scaling during the upgrade process, the ASG max size is left in an increased state (e.g., unpredictably higher than the original value).
This causes potential overprovisioning of nodes and additional costs due to an unintended increase in ASG max size.
Proposed Solution:
Introduce a mechanism in the EKS managed node group upgrade workflow to:
- Track the original ASG max size before the upgrade begins.
- Automatically restore the original ASG max size once the upgrade process is complete, regardless of any Cluster Autoscaler-triggered activities.
Benefit to Customers:
- Ensures predictable and stable behavior of ASGs post-upgrade.
- Prevents unexpected resource usage and costs due to unintended increases in ASG max size.
- Improves alignment between EKS upgrade workflows and documented behavior, enhancing operational trust and ease of use.
Additional Context:
This feature is especially critical for users leveraging Cluster Autoscaler to dynamically manage node group sizes in production environments. The current behavior introduces unnecessary manual intervention to reset ASG configurations after upgrades, which this enhancement could automate and eliminate.
CaseID where I was suggested to create this feature request Case ID: 173143486100288
Contributor guide
Research direction
Locate the EKS managed node group upgrade workflow and its ASG max-size handling, then trace the scale-up and scale-down paths when Cluster Autoscaler acts. Add coverage for preserving the original max size and restoring it after the upgrade, including when scaling occurs; done means the ASG max size matches its pre-upgrade value.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- aws, kubernetes
- Domain
- cloud, infrastructure
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 35/100