Support new topology/zones labels

[prashanth26]

The old failure-domain label was deprecated in favour of topology/zone labels. This PR addresses this issue.
See: https://v1-18.docs.kubernetes.io/docs/reference/kubernetes-api/labels-annotations-taints/#failure-domainbetakubernetesiozone

What this PR does / why we need it:

Which issue(s) this PR fixes:
Fixes #68

Special notes for your reviewer:

Release note:

Support the latest zone label `topology.kubernetes.io/zone` in addition to the existing `failure-domain.beta.kubernetes.io/zone` while determining the zone for AWS machines.

Allow scaling up from zero using the latest stable zone, region, arch, OS, instanceType labels on node objects. 

[hardikdr]

Thanks for the PR @prashanth26 .

I think, buildGenericLabels needs to be adapted as well here: https://github.com/gardener/autoscaler/blob/machine-controller-manager-provider/cluster-autoscaler/cloudprovider/mcm/mcm_manager.go#L593.

Essentially, mcm-provider fetches the zone "value" from the MachineClass, and builds the node-object, where "key" of the zone-label on the node, should also be adapted for both topology/failure-domain. Both variations could be kept, for backward compatibility, you can take a call on that.

Also, can you please the test exact end-user case with this change, to ensure it solves the issue as expected?

[hardikdr]

If I am not wrong, with this change, where both variations of the label are kept on the node, the original issue should be resolved, but I'd really suggest testing it once.

• Although the worker-extension should anyways be updated for consistency.

[prashanth26]

I think, buildGenericLabels needs to be adapted as well here: https://github.com/gardener/autoscaler/blob/machine-controller-manager-provider/cluster-autoscaler/cloudprovider/mcm/mcm_manager.go#L593.

Nice catch @hardikdr . Thanks for this. I shall update it to have both labels. Probably will also look into the region label.

Also, can you please the test exact end-user case with this change, to ensure it solves the issue as expected?

Yes, hardik. I will need the changes on extensions also to create the machineClass with the new labels. Will make the changes on extension and test it out together. Will keep this PR open until then change has been tested with the usecase.

If I am not wrong, with this change, where both variations of the label are kept on the node, the original issue should be resolved, but I'd really suggest testing it once.

Yes shall do that.

Thanks for this review. Appreciate it. :)

[hardikdr]

One minor comment, with rebase these labels now can be fetched from apiv1 "k8s.io/api/core/v1" as well.

[hardikdr]

Yes, hardik. I will need the changes on extensions also to create the machineClass with the new labels.

If the changes of the "buildGenericLabels" are also included, the changes at extension might not be needed to test it out, the extension should always be updated though.

[prashanth26]

Hi @hardikdr ,

I have taken in your suggestions and made the necessary changes here - e3943ff. Hope this looks good now.

Will be testing these changes locally today/tomorrow.

[hardikdr]

Sure, thank you.

[prashanth26]

Just tested these changes locally. It works backward compatible with both the deprecated and current zone and region labels.

I think for the first cut let's just release the cluster-autoscaler with this change and it should take care of the rest. We can update the provider-aws labels in a couple of releases.

@hardikdr - Let me know if it looks good to merge.