Support external scalers for infrastructure managed by a MachinePool

[dthorsen]

User Story

As a cluster operator, I would like to have the option to utilize external scaling applications for autoscaling infrastructure managed under a MachinePool so that we can take advantage of the capabilities of existing infrastructure scaling tools if we chose.

Detailed Description

There are many potential scaler implementations that support things like AWS ASG and Azure VMSS. With a small change, cluster-api can be made to optionally allow external software to manage the scaling of the node pools without needing to have support for cluster-api. Some examples of scalers that would benefit from this solution are:

• Kubernetes cluster-autoscaler using the existing cloud-provider implementations. This provides a stopgap while cluster-autoscaler's support for CAPI MachinePools to mature and reach feature parity with the existing cloud provider implementations. Incidentally, this would also allow the CAPZ provider add AKS' native managed node pool autoscaling support, which provides an fully-managed installation of cluster-autoscaler on the AKS control plane itself completely managed by the cloud provider, Azure.
• Atlassian escalator
• Spotinst (an infrastructure provider for spotinst does not yet exist but interest has been expressed by the community for one to exist)

/kind feature

[dthorsen]

/assign

[dthorsen]

Related issue with more history and discussion: kubernetes-sigs/cluster-api-provider-aws#2022

[fabriziopandini]

/milestone v1.2

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[AverageMarcus]

/remove-lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[killianmuldoon]

/remove-lifecycle stale

[fabriziopandini]

/triage needs-information
/unassign @dthorsen

@CecileRobertMichon is this still something on your radar?

[CecileRobertMichon]

@jackfrancis was in #7107

/assign @jackfrancis

[fabriziopandini]

/remove-triage needs-information
/triage accepted

[AverageMarcus]

This can be closed now with the release of #7107 right?

/cc @dthorsen @jackfrancis

[jackfrancis]

@AverageMarcus yes! (I don't seem to have privileges to do that)

[jackfrancis]

/close

[k8s-ci-robot]

@jackfrancis: Closing this issue.

In response to this:

/close

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/test-infra repository.

[jackfrancis]

nevermind just had to use the right slash-verb