Fix/aws asg unsafe decommission 5829

[ruiscosta]

Merge branch 'fix/aws-asg-placeholder-decommission'

This merge resolves an issue in the Kubernetes Cluster Autoscaler where actual instances within AWS Auto Scaling Groups (ASGs) were incorrectly decommissioned instead of placeholders. The updates ensure that placeholders are exclusively targeted for scaling down under conditions where recent scaling activities have failed. This prevents the accidental termination of active nodes and enhances the reliability of the autoscaler in AWS environments.

Key improvements include:

• Refined logic to strictly identify unsuccessful scaling activities.
• Ensured that scaling operations affect placeholders only, preventing unintended impacts on real instances.
• Expanded unit tests and validations to bolster the resilience and correctness of the scaling process.

Fixes #5829

What type of PR is this?

/kind bug

What this PR does / why we need it:

This PR prevents the Kubernetes Cluster Autoscaler from erroneously decommissioning actual nodes during scale-down operations in AWS environments, which could lead to unintended service disruptions.

Which issue(s) this PR fixes:

Fixes #5829

Special notes for your reviewer:

Does this PR introduce a user-facing change?

Fix an issue in the Kubernetes Cluster Autoscaler where actual AWS instances could be incorrectly scaled down instead of placeholders.

[k8s-ci-robot]

Keywords which can automatically close issues and at(@) or hashtag(#) mentions are not allowed in commit messages.

The list of commits with invalid commit messages:

• fb69323 fix: Handle placeholder instance decommission safely in AWS ASGs
• 9dfbb4d fix: Handle placeholder instance decommission safely in AWS ASGs

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here.

[linux-foundation-easycla]

• ❌ - login: @ruiscosta / name: Rui Costa . The commit (fb69323, 9dfbb4d) is not authorized under a signed CLA. Please click here to be authorized. For further assistance with EasyCLA, please submit a support request ticket.

[k8s-ci-robot]

Hi @ruiscosta. Thanks for your PR.

I'm waiting for a kubernetes member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: ruiscosta
Once this PR has been reviewed and has the lgtm label, please assign drmorr0 for approval. For more information see the Kubernetes Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• cluster-autoscaler/cloudprovider/aws/OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[aaroniscode]

/ok-to-test

[k8s-ci-robot]

@aaroniscode: Cannot trigger testing until a trusted user reviews the PR and leaves an /ok-to-test message.

In response to this:

/ok-to-test

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[drmorr0]

Hi @ruiscosta I don't believe this actually solves the problem. Consider the following scenario:

1. We scale up the ASG by 10 instances. AWS creates 3 of them, and then fails on the remaining 7.
2. DeleteInstances is called with those 10 instances; 7 of them are placeholders
3. In lines 321 we check to see if the most recent scaling activity was successful or not, which returns false since 7 instances could not be created.
4. Now for each instance in the loop, we decrease the ASG size by one, which reduces the ASG size by 7.
5. In between the check in line 321 and (say) the 5th iteration of the loop, AWS launches a new instance, which joins the cluster. Our information about what instances are actually placeholders is now out of date, and we get the same problem that we had before.

We "could" check the recent scaling activity in every iteration of the loop, at the expense of making a lot more API calls, which I think is undesirable, and is still subject to a race between when you make the check and when you change the ASG size.

[dims]

/ok-to-test

[dims]

/easycla