Filter out non-existing node-groups before scale-up balancing

[pmendelski]

What type of PR is this?

/kind flake

What this PR does / why we need it:

Scale-up orchestrator computes similar node groups for scale-up balancing and expander. It uses both injected and existing node groups. Sometimes injected node group is matched in the balancing phase causing errors as it's impossible to scale it up. Filter all non-existing node groups before balancing happens, leave upcoming ones as they should use in-memory accounting for scale-ups.

Which issue(s) this PR fixes:

Fixes #

Special notes for your reviewer:

Does this PR introduce a user-facing change?

NONE

Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.:

[k8s-ci-robot]

Hi @pmendelski. 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.

[aleksandra-malinowska]

/ok-to-test

[aleksandra-malinowska]

/lgtm
/approve

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: aleksandra-malinowska, pmendelski

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

The pull request process is described here

Needs approval from an approver in each of these files:

• cluster-autoscaler/OWNERS [aleksandra-malinowska]

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

[jackfrancis]

This change seems like it would be good to have a UT scenario for. Maybe in cloudprovider/test/test_cloud_provider.go we add a (tcp *TestCloudProvider) AddInjectedNodeGroup method that we can then leverage in a new test scenario in core/scaleup/orchestrator/orchestrator_test.go?

I'm not sure if the existing func (tcp *TestCloudProvider) BuildNodeGroup includes all of the necessary foo to construct an "injected node group" (we do fulfill the exists=false condition in the AddUpcomingNodeGroup helper method which is used in the TestUpcomingNodesFromUpcomingNodeGroups test case, not sure about how to get the IsUpcoming method to return false).

@pmendelski are you up for adding a UT case for this?