The topologySpreadConstraints and node labels is used for equal distribution of pods on nodes for high availability of the application. However, we have multiple critical applications which are in different namespaces, and topologySpreadConstraint is only evaluated for pods in the same namespace: "Only pods within the same namespace are matched and grouped together when spreading due to a constraint." [1]

This was requested upstream some time ago, but it was closed [2].

We'd like to have an option in topologySpreadConstraints to span multiple namespaces, so we can spread the critical application pods, which are in different namespaces, in different nodes.

Example/Use case:

• Critical app1 (cri_app1) in ns1, critical app2 (cri_app2) in ns2 and critical app3 (cri_app3) in ns3
• Openshift cluster with 6 nodes, and each app has 2 pods
• Using topologySpreadConstraints "cluster-wide" (spanning multiple namepaces), the result would be:
  node1: cri_app1_1 | node2 cri_app2_1 | node3 cri_app3_1 | node4 cri_app1_2 | node5 cri_app2_2 | node6 cri_app3_2
• Using topologySpreadConstraints "namespaced" (current behaviour), if node3, node4, node5 and node6 have less free resources, the result is :
  node1: cri_app1_1, cri_app2_1, cri_app3_1 | cri_app1_2, cri_app2_2, cri_app3_2

In order to keep namespaced and cluster-wide compatibility, a parameter can be added in topologySpreadConstraints struct to define the scope, with the possible values:"namespaced", "clusterwide". By default , to be backward compatible, should be namespaced (null "scope" parameter means "namespaced").

[1]

https://github.com/kubernetes/kubernetes/blob/afc57a752110ac0633ff5df896ebe02ee1b19ec5/pkg/scheduler/framework/plugins/podtopologyspread/common.go#L151

[2]

https://github.com/kubernetes/kubernetes/issues/118749

Describe the impact to you or the business
Limitation to schedule critical apps in an efficient way / HA