Cluster-api-provider-azure: Add warnings when a user selects a VM instance type that could lead to potential throttling issues based on the storage configuration

[detiber]

/kind feature

Describe the solution you'd like
Azure has a tiered set of i/o and bandwidth limits that can lead to difficult to debug throttling behavior. We should likely attempt to warn the user if the VM type they choose could cause VM-level limits to throttle before individual storage-level limits are hit.

Anything else you would like to add:
This will likely require either mapping (or potentially determining through api introspection) the vm-level limits based on the instance type selected to the aggregated limits for individual disks for the given instance to determine if the vm-level limits are lower than the aggregated individual disk limits.

[devigned]

kind of related: https://github.com/kubernetes-sigs/cluster-api-provider-azure/issues/448

Also related, @CecileRobertMichon and I have talked about this a few times and have increased the default disk storage capacity as disk storage capacity is also related to i/o 😜.

What do you think about this going into a warning event on the AzureMachine resource?

[CecileRobertMichon]

/help

[k8s-ci-robot]

@CecileRobertMichon:
This request has been marked as needing help from a contributor.

Please ensure the request meets the requirements listed here.

If this request no longer meets these requirements, the label can be removed
by commenting with the /remove-help command.

In response to this:

/help

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.

[detiber]

I think a Warning event on the AzureMachine resource is a great idea. Only downside is that events are not long lived. It might also be good to replicate it as a Condition on the AzureMachine once we go down the path of supporting Conditions :)

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[alexeldeib]

/remove-lifecycle stale

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[CecileRobertMichon]

/remove-lifecycle stale

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[CecileRobertMichon]

/remove-lifecycle stale

[CecileRobertMichon]

/good-first-issues

conditions are now supported for AzureMachines, we should use those.

[CecileRobertMichon]

/good-first-issue

[k8s-ci-robot]

@CecileRobertMichon:
This request has been marked as suitable for new contributors.

Please ensure the request meets the requirements listed here.

If this request no longer meets these requirements, the label can be removed
by commenting with the /remove-good-first-issue command.

In response to this:

/good-first-issue

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]

My 2¢: these types of warnings should be integrated into the UX flow of building/configuring clusters and/or machines. Putting them in an event stream of the resource itself is sort of too late.

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale