Enable 'Namespace filtering' for 'LowNodeUtilization' strategy

[jlegido]

Is your feature request related to a problem? Please describe.
Basically my use case is not covered by the prodyct.

Describe the solution you'd like
Enable 'Namespace filtering' for 'LowNodeUtilization' strategy.

Describe alternatives you've considered
Enable 'Label filtering' for 'LowNodeUtilization' strategy.

What version of descheduler are you using?

descheduler version: Commit 31fd097c0a02adee30b98aab838f326ca1c22879, I guess version v0.20.0

Additional context
First of all many thanks to all the people involved in this project for their time, I really appreciate it.

My use case is that I need to make sure that for each one of the workers (2 in my case) at least one pod of a certain kind (either filter by namespace or label would suffice). Below scenario does NOT meets my requirements:

kubectl get nodes -n ingress-nginx 

I have 2 worker nodes, k8s3 and k8s4:

NAME   STATUS   ROLES                  AGE   VERSION
k8s2   Ready    control-plane,master   7d    v1.21.1
k8s3   Ready    <none>                 7d    v1.21.1
k8s4   Ready    <none>                 7d    v1.21.1

But all pods (from a certain namespace) are running on worker k8s3:

kubectl get pods -n ingress-nginx -o wide

NAME                                        READY   STATUS    RESTARTS   AGE   IP            NODE   NOMINATED NODE   READINESS GATES
ingress-nginx-controller-76fb77985c-27jkk   1/1     Running   0          45m   10.244.1.24   k8s3   <none>           <none>
ingress-nginx-controller-76fb77985c-q6rpr   1/1     Running   0          44m   10.244.1.25   k8s3   <none>           <none>

My configmap is as below:

kubectl edit configmaps -n kube-system descheduler-policy-configmap 

apiVersion: v1
data:
  policy.yaml: |
    apiVersion: "descheduler/v1alpha1"
    kind: "DeschedulerPolicy"
    strategies:
      "RemoveDuplicates":
         enabled: true
      "RemovePodsViolatingInterPodAntiAffinity":
         enabled: true
      "LowNodeUtilization":
         enabled: true
         params:
           namespaces:
             include:
               - "ingress-nginx"
           nodeResourceUtilizationThresholds:
             thresholds:
               "pods": 1
             targetThresholds:
               "pods": 1
kind: ConfigMap
metadata:
  creationTimestamp: "2021-05-21T08:30:47Z"
  name: descheduler-policy-configmap
  namespace: kube-system
  resourceVersion: "204442"
  uid: 62432622-a03a-4b69-a7a8-0efc1db0d558

Yes, I know, I added a non working option namespaces just in case, but not working.

Thanks.

[damemi]

Hi @jlegido
Unfortunately we do not plan to enable namespace filtering for LowNodeUtilization, this issue appears to be a duplicate of #391 (where you can find much more discussion on the reasons why). tl;dr, LowNodeUtilization is intentionally designed to balance entire clusters, not just specific pods.

However if you are just trying to make sure the pods are spread among your worker nodes, I would recommend using pod topology spread constraints rather than LowNodeUtilization, anyway.

If you would like to continue the discussion on this, please feel free to join in the issue I linked. Closing this as a duplicate
/close

[k8s-ci-robot]

@damemi: Closing this issue.

In response to this:

Hi @jlegido
Unfortunately we do not plan to enable namespace filtering for LowNodeUtilization, this issue appears to be a duplicate of #391 (where you can find much more discussion on the reasons why). tl;dr, LowNodeUtilization is intentionally designed to balance entire clusters, not just specific pods.

However if you are just trying to make sure the pods are spread among your worker nodes, I would recommend using pod topology spread constraints rather than LowNodeUtilization, anyway.

If you would like to continue the discussion on this, please feel free to join in the issue I linked. Closing this as a duplicate
/close

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/test-infra repository.

[jlegido]

@damemi many thanks for your quick reply and sorry for duplicating the issue, I had to previously search a little bit.

Unless I'm missing something pod topology spread constraints it's not an option for me, since the nginx ingress controller uses Service instead of Pod.

[damemi]

@jlegido you would place the constraints on the deployment podSpec, and the scheduler will distribute the nginx pods to the appropriate nodes when they are created. The service talks to those pods by label selectors

[jlegido]

Leaving here just in case somebody else have same requirements:

1. Edit your deployment

kubectl edit deployments.apps -n ingress-nginx  ingress-nginx-controller 

2. Add below key under spec.template.spec:

      affinity:
        # Prevent starting pod in a node which already have one pod started
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchExpressions:
              - key: app.kubernetes.io/component
                operator: In
                values:
                - controller
            topologyKey: kubernetes.io/hostname
        # Prevent starting pod in the master node
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              - key: node-role.kubernetes.io/control-plane
                operator: DoesNotExist

Many thanks again @damemi

[damemi]

@jlegido no problem, just as a note though using podAntiAffinity will limit you to 1 replica per node. Topology spreading constraints allow you to evenly spread 2+ replicas per node