Update cluster-api provider to use machineTemplate.status.nodeInfo for architecture-aware autoscale from zero

[aleskandro]

What type of PR is this?

/kind feature

What this PR does / why we need it:

kubernetes-sigs/cluster-api#11962 introduced the nodeInfo field for MachineTemplates. Providers can reconcile this field in the status subresource to inform the autoscaler about the architecture and operating system that the MachineTemplate's nodes will run.

Previously, we have been implementing this behavior in the cluster autoscaler by leveraging the labels capacity annotation and, as a fallback, default values set in environment variables at cluster-autoscaler deployment time.

With this commit, the cluster autoscaler computes the future architecture of a node with the following priority order:

• Labels set in existing nodes for not-autoscale-from-zero cases
• Labels set in the labels capacity annotation of machine template, machine set, and machine deployment.
• Values in the status.nodeSystemInfo of MachineTemplates
• Generic/default labels set in the environment of the cluster autoscaler

Which issue(s) this PR fixes:

Fixes #8347

Special notes for your reviewer:

Does this PR introduce a user-facing change?

Cluster API Provider's implementors can now provide the architecture and the operating system of a future node in their machine template at the field status.nodeInfo to inform these values for scaling from zero.

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

• KEP: 📖 Update autoscaling from zero enhancement proposal with support for platform-aware autoscale from zero kubernetes-sigs/cluster-api#11962
• Other doc: https://cluster-api.sigs.k8s.io/developer/providers/contracts/infra-machine

NONE

[elmiko]

on balance this is making sense, i think we need to clean up a couple things.

reducing the number of api server calls is important for the capi provider as we tend to be very noisy from an HTTP perspective.

[elmiko]

this mostly makes sense to me, i have a couple questions.

[elmiko]

/lgtm

@jackfrancis would you mind taking a look as well 🙏

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: aleskandro
Once this PR has been reviewed and has the lgtm label, please ask for approval from elmiko. For more information see the Code Review Process.

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

Needs approval from an approver in each of these files:

• cluster-autoscaler/cloudprovider/clusterapi/OWNERS

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

[jackfrancis]

/label tide/merge-method-squash

[jackfrancis]

/lgtm
/assign @elmiko

[elmiko]

code looks good to me, apologies @aleskandro , i changed the test structure to make it less complex with a builder pattern. you'll need to update the unit tests and then probably add a WithNodeInfo function to the builder.

[elmiko]

thanks for the updates @aleskandro , i think this is looking good.

/lgtm

i'd like to give @jackfrancis a chance to review again, but i have a feeling we can approve this soon.

[jackfrancis]

This is a bit academic, but now that there's a chance we'll be passing in a nil map[string]string to cloudprovider.JoinStringMaps, let's update the existing TestJoinStringMaps UT to validate that use case.

Something like

$ git diff
diff --git a/cluster-autoscaler/cloudprovider/util_test.go b/cluster-autoscaler/cloudprovider/util_test.go
index ba23d6180..ee99f2bcb 100644
--- a/cluster-autoscaler/cloudprovider/util_test.go
+++ b/cluster-autoscaler/cloudprovider/util_test.go
@@ -44,9 +44,11 @@ func TestBuildKubeProxy(t *testing.T) {
 }
 
 func TestJoinStringMaps(t *testing.T) {
+       emptyMapBeginning := make(map[string]string)
        map1 := map[string]string{"1": "a", "2": "b"}
        map2 := map[string]string{"3": "c", "2": "d"}
        map3 := map[string]string{"5": "e"}
-       result := JoinStringMaps(map1, map2, map3)
+       emptyMapEnd := make(map[string]string)
+       result := JoinStringMaps(emptyMapBeginning, map1, map2, map3, emptyMapEnd)
        assert.Equal(t, map[string]string{"1": "a", "2": "d", "3": "c", "5": "e"}, result)
 }