Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Default min/max sizes for Azure VMSSs #6863

Merged
merged 1 commit into from
Jul 1, 2024

Conversation

rrangith
Copy link
Contributor

@rrangith rrangith commented May 22, 2024

What type of PR is this?

/kind feature

What this PR does / why we need it:

Currently the autoscaler will ignore a VMSS if no min/max size is provided. This PR changes the behaviour so it will instead default to a min and max as part of the autodiscovery tags, similar to how GCP does it

"GCE matches by IG name prefix, and requires you to specify min and max nodes per IG, e.g. `mig:namePrefix=pfx,min=0,max=10` "+
. The min and max are optional for Azure and used as default values if a VMSS is missing its min/max tags

Azure has a limit of 50 tags per resource https://learn.microsoft.com/en-us/azure/azure-resource-manager/management/tag-resources#limitations. This change will allow people to save 2 tag spaces

What does this PR do

We will read scaleSet.Tags["min"] (which is the current behaviour), and then else if that is not defined, we will check to see if there is a default minSize (new behaviour), and then if neither are defined we will ignore the vmss (current behaviour).

So if a default is not specified, then the current behaviour will be maintained. And the explicit min/max tags will always be given the higher assignment precedence since even if the default is specified, we will still use the the explicit tag value

Testing

I built an image including these changes and tested in an environment. I confirmed that when you don't specify a default min/max the behaviour stays the same. And then when I defined a default min/max I confirmed that now VMSSs missing an explicit min/max tag were now considered and used the default. I also confirmed that the explicit min/max tag would take precedence over the default value

Which issue(s) this PR fixes:

Fixes #6864

Does this PR introduce a user-facing change?

You can now optionally specify a default `min` and `max` size for Azure VMSSs through the auto discovery tags. Explicit `min` and `max` tags on VMSSs will still be given priority over the default.

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


@k8s-ci-robot k8s-ci-robot added the kind/feature Categorizes issue or PR as related to a new feature. label May 22, 2024
@k8s-ci-robot k8s-ci-robot requested a review from nilo19 May 22, 2024 20:28
@k8s-ci-robot k8s-ci-robot requested a review from x13n May 22, 2024 20:28
@k8s-ci-robot k8s-ci-robot added cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. area/provider/azure Issues or PRs related to azure provider labels May 22, 2024
@k8s-ci-robot
Copy link
Contributor

Hi @rrangith. 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 k8s-ci-robot added needs-ok-to-test Indicates a PR that requires an org member to verify it is safe to test. size/L Denotes a PR that changes 100-499 lines, ignoring generated files. labels May 22, 2024
@rrangith
Copy link
Contributor Author

/assign @jackfrancis @feiskyer

I presented this at the SIG Autoscaling meeting and they suggested I reach out to you. Can I please get a review?

@@ -327,6 +329,8 @@ func (m *AzureManager) getFilteredScaleSets(filter []labelAutoDiscoveryConfig) (
klog.Warningf("ignoring vmss %q because of invalid minimum size specified for vmss: %s", *scaleSet.Name, err)
continue
}
} else if cfgMinSize >= 0 {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we invert the precedence here and have the previous min/max foo (scaleSet.Tags["min"] and scaleSet.Tags["max"] have the higher assignment precedence? I think that might be a better back-compat story.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure I follow. We will read scaleSet.Tags["min"] (which is the current behaviour), and then else if that is not defined, we will check to see if there is a default cfgMinSize (new behaviour), and then if neither are defined we will ignore the vmss (current behaviour).

So if a default is not specified, then the current behaviour will be maintained. And the explicit tags will always be given the higher assignment precedence since even if the default is specified, we will still use the the explicit tag value

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah yes my bad, thanks!

func matchDiscoveryConfig(labels map[string]*string, configs []labelAutoDiscoveryConfig) bool {
// returns true if the VMSS's tags match the autodiscovery configs
// if there are multiple min/max sizes defined, return the highest min value and the lowest max value
func matchDiscoveryConfig(labels map[string]*string, configs []labelAutoDiscoveryConfig) (bool, int, int) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This func (and the caller flow is starting to get a little opaque...)

Would returning a struct make this a bit more readable from the consumer side and make the func more maintainable? Is there a good chance that the configs we grab out of this will never grow beyond min + max?

(Love the new UT cases though!)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sure I can change that to a struct!

@jackfrancis
Copy link
Contributor

/ok-to-test

@k8s-ci-robot k8s-ci-robot added ok-to-test Indicates a non-member PR verified by an org member that is safe to test. and removed needs-ok-to-test Indicates a PR that requires an org member to verify it is safe to test. labels Jun 10, 2024
@rrangith
Copy link
Contributor Author

/retest-required

@rrangith
Copy link
Contributor Author

/retest

@jackfrancis
Copy link
Contributor

@rrangith have you built images from these source changes and tested in an Azure environment? I'm confident the E2E failures are not related to this PR, but would like to get some coverage before landing this.

@rrangith
Copy link
Contributor Author

rrangith commented Jun 11, 2024

@rrangith have you built images from these source changes and tested in an Azure environment? I'm confident the E2E failures are not related to this PR, but would like to get some coverage before landing this.

@jackfrancis yes, I built an image including these changes and tested in an environment. I confirmed that when you don't specify a default min/max the behaviour stays the same. And then when I defined a default min/max I confirmed that now VMSSs missing an explicit min/max tag were now considered and used the default. I also confirmed that the explicit min/max tag would take precedence over the default value

@k8s-ci-robot
Copy link
Contributor

@rrangith: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name Commit Details Required Rerun command
pull-cluster-autoscaler-e2e-azure 333d438 link false /test pull-cluster-autoscaler-e2e-azure

Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR.

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.

Copy link
Contributor

@jackfrancis jackfrancis left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

/lgtm
/approve

Thank you @rrangith!

@k8s-ci-robot k8s-ci-robot added the lgtm "Looks good to me", indicates that a PR is ready to be merged. label Jun 13, 2024
@rrangith
Copy link
Contributor Author

rrangith commented Jul 1, 2024

/retest

@gjtempleton
Copy link
Member

Thanks for this, changes outside of the Azure cloudprovider implementation all look good to me.

/approve

@k8s-ci-robot
Copy link
Contributor

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: gjtempleton, jackfrancis, rrangith

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:

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

@k8s-ci-robot k8s-ci-robot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Jul 1, 2024
@k8s-ci-robot k8s-ci-robot merged commit 3c6dd26 into kubernetes:master Jul 1, 2024
6 of 7 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approved Indicates a PR has been approved by an approver from all required OWNERS files. area/cluster-autoscaler area/provider/azure Issues or PRs related to azure provider cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. kind/feature Categorizes issue or PR as related to a new feature. lgtm "Looks good to me", indicates that a PR is ready to be merged. ok-to-test Indicates a non-member PR verified by an org member that is safe to test. size/L Denotes a PR that changes 100-499 lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Default min/max sizes for Azure VMSSs
5 participants