Feature Request: Global Namespace Exclusion Configuration

[patsevanton]

Is your feature request related to a problem? Please describe.
Currently, there is no way to define a global namespace exclusion for all Descheduler strategies. Each strategy must be configured individually with its own namespaces.exclude list. This becomes difficult to manage and error-prone in large clusters where multiple strategies are enabled and certain namespaces (e.g., kube-system, monitoring, or infra) should always be ignored.

Describe the solution you'd like
I would like to have a global configuration option (for example, globalNamespaceExclusions) that allows specifying a list of namespaces that should be excluded from all Descheduler strategies. This would make configuration simpler, reduce duplication, and ensure consistent behavior across all strategies.

Example configuration:

apiVersion: "descheduler/v1alpha2"
kind: "DeschedulerPolicy"
globalNamespaceExclusions:
  - kube-system
  - monitoring
  - infra
strategies:
  RemoveDuplicates:
    enabled: true
  RemovePodsViolatingInterPodAntiAffinity:
    enabled: true

Describe alternatives you've considered

• Duplicating the excludeNamespaces configuration under each strategy. This works but is hard to maintain and can easily lead to inconsistent configurations.
• Writing an external script or admission controller to patch the Descheduler configuration automatically, but this adds unnecessary operational complexity.

What version of descheduler are you using?
descheduler version: v0.32.0

Additional context
This feature would be especially useful in environments with many namespaces and teams, ensuring that system or critical namespaces are consistently excluded without having to manually edit every strategy configuration.

[ingvagabund]

Hello @patsevanton. Thank you for suggesting the improvements. This is doable. Would the global namespace exclusion be mutually exclusive to per profile namespace exclusion? Or, would the per profile exclusion take precedence over the global one? It would be easier to make it mutually exclusive by the policy validation. On the other hand the restriction would make it less expressive in terms of making the global exclusion for most of the profiles with few exceptions where the exclusion would be different.

[ingvagabund]

The first version of the new global might be more strict so we can collect user feedback and later decide whether to make the restriction more relaxed.

I'd also suggest to keep the original naming even for the global exclusion. I.e. globalNamespaceExclusions -> namespace.exclude so later the namespace config struct can be extended with other fields without introducing deprecation and renaming.