✨ Surface aggregated machine versions in status

[miltalex]

What this PR does / why we need it:

• Introduces status.versions (aggregated Kubernetes version + replica counts) across core APIs: Cluster control plane/workers, MachineSet, MachineDeployment, MachinePool, and
  KubeadmControlPlane.
• Add a shared version aggregation helper and use it in controllers to report versions from machine kubelet versions.
• Updates topology upgrade checks to use status.versions when available, reducing the need to list machines/nodes for simple version drift detection.
• Adds tests covering aggregation, controller status updates, and upgrade-check behavior.

Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes #13303

P.S: I have tested the above changes locally using the docker provider. For example during upgrade

  Control Plane:
    Available Replicas:   0
    Desired Replicas:     3
    Ready Replicas:       0
    Replicas:             4
    Up To Date Replicas:  1
    Versions:
      Replicas:  3
      Version:   v1.34.3
      Replicas:  1
      Version:   v1.35.1

Control Plane:
   Available Replicas:   0
   Desired Replicas:     3
   Ready Replicas:       0
   Replicas:             4
   Up To Date Replicas:  2
   Versions:
     Replicas:  2
     Version:   v1.34.3
     Replicas:  1
     Version:   v1.35.1

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

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

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

Details

Needs approval from an approver in each of these files:

• OWNERS

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]

This PR is currently missing an area label, which is used to identify the modified component when generating release notes.

Area labels can be added by org members by writing /area ${COMPONENT} in a comment

Please see the labels list for possible areas.

Details

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]

Hi @miltalex. Thanks for your PR.

I'm waiting for a kubernetes-sigs 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.

Details

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]

PR needs rebase.

Details

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.

[zjs]

thought: This function looks very similar to internal/util/version.VersionsFromMachines, except that it operates on collections.Machines rather than []*clusterv1.Machine.

Would it make sense to call internalversion.VersionsFromMachines(machines.UnsortedList()) here instead, to avoid maintaining two copies of the same logic?

Is there some nuanced difference between the functions? (If so, that'd be useful to note in a comment.)

[zjs]

question: The version comparison here uses raw string equality while the existing fallback path below parses versions with semver.ParseTolerant. If a provider or kubelet ever reports the version in a slightly different form (e.g. "1.32.0" vs "v1.32.0"), this could give a different answer than the fallback path. Is raw string comparison intentional here for simplicity, or would it be worth using semver-tolerant comparison for consistency?

[zjs]

question: Would it make sense to require that at least one of these is implemented? (It seems like the weaker language unintentionally allows providers to drop version reporting entirely, but I don't think that's the intent.)

[zjs]

question: Given that Version is +required, does this validation provide value? I don't think it's incorrect, but may be noise in the CRD schema.