feat: auto-add member-cluster-name label to MemberCluster for override selection by cluster name

[Yetkin Timocin (ytimocin)]

Description of your changes

Automatically adds a kubernetes-fleet.io/member-cluster-name label to MemberCluster objects during reconciliation, enabling users to select clusters by name in ResourceOverride and ClusterResourceOverride via labelSelector.

• New clusters: Label is added on first reconcile (same mechanism as the finalizer)
• Existing clusters after upgrade: Label is added on the next heartbeat-triggered reconcile — no manual action, no downtime
• Self-healing: If removed, the next reconcile restores it
• No infinite reconcile loop: GenerationChangedPredicate filters out metadata-only updates

Fixes #101

I have:

• Associated this change with a known KubeFleet Issue (Bug, Feature, etc).
• Run make reviewable to ensure this PR is ready for review.

How has this code been tested

Locally, yes. Also added necessary tests and updated existing ones.

Special notes for your reviewer

N/A

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[Wei Weng (weng271190436)]

In Azure Kubernetes Fleet Manager, we have these 2 labels on the member cluster (there are more but these 2 are the most relevant ones)

fleet.azure.com/cluster-name=testmember-0
fleet.azure.com/member-name=testmember-0

fleet.azure.com/cluster-name is the AKS cluster name
fleet.azure.com/member-name is the fleet member name

I think this should be named

kubernetes-fleet.io/member-name=testmember-0

, which follows the existing Azure label convention

[Wei Weng (weng271190436)]

Simon Waight (@sjwaight) I think having kubernetes-fleet.io/member-name=testmember-0 in addition to

fleet.azure.com/cluster-name=testmember-0
fleet.azure.com/member-name=testmember-0

is acceptable in Azure Kubernetes Fleet Manager's member cluster CRs?

[Simon Waight (sjwaight)]

I think in an ideal world we would have just the kubernetes-fleet.io labels and retire the fleet.azure.com ones for cluster name and member name, as these concepts are portable between KubeFleet and Fleet Manager. I would recommend we add both: kubernetes-fleet.io/member-name and kubernetes-fleet.io/cluster-name (if it's not already there). We can add these to our documentation for Fleet Manager, but keep the existing labels to not break the current API contract.

[Stéphane Erbrech (serbrech)]

fleet.azure.com labels are owned by the azure service, and the service is the source of truth for them (we set these labels). this ensures parity in label selectors between controlplane and dataplane.

The Kubefleet system should not care more than that about them.

Having built-in labels in kubefleet make sense. They should mirror the ones from the service, when they serve the same purpose. That's what the namespacing of labels is for :).

We will certainly have labels that only kubefleet can define in the future too, because it can get them from the members directly.

I think that we should also always consider built-in kubernetes labels. for example topology has a region and zone label that might be relevant?

https://kubernetes.io/docs/reference/labels-annotations-taints/#topologykubernetesioregion