Add default selectorLabel to topologySpreadConstraints if not otherwise specified
If someone defines one or more entries in the topologySpreadConstraints list and does not define the labelSelectors.matchLabels keys then default values will be added. Most people are likely going to want the default selectorLabels so the spread constraints match what they are deploying with this chart.
The alternative to this is to run the configuration in this key through the tpl function to allow users the ability to call named templates. Similar to how extraObjects is handled.
I'm afraid I don't know enough about topologySpreadConstraints to comment 😓
Disclaimer: Bear with me as I ramp up in this area.
Would this be considered a breaking change? Per https://kubernetes.io/docs/concepts/scheduling-eviction/topology-spread-constraints/ I think this can change pod grouping.
I think this has the potential to cause a "breaking" change in that it may cause the spread constraint functionality to begin working as intended. That is, if a user has not explicitly defined the selectorLabel field in their values file, then no matching pods will be selected and the spread constraint feature will not function as expected.
I tested this behavior on the HEAD of the develop branch using kind (kubernetes version 1.32) and I received the following warning from kubernetes:
W0217 11:08:54.767705 6459 warnings.go:70] spec.template.spec.topologySpreadConstraints[0].labelSelector: a null labelSelector results in matching no pod
The chart installed successfully and the pod is running. With this PR, however, there was no such warning and, presumably, the spread constraint feature will operate as expected.
@pront, I see you approved this a while back. Is there anything else you want to see before merging?