"EmptyNode" Descheduler Stratergy

[Sujit-sys]

Is "EmptyNode" Deccheduler Stratergy valid? Can this be used to evict a pod except Daemonsets from a Empty Node or alomst empty node to facilitate their scale-down by the Cluster Autoscaler.
I don't see any such Stratergy in the Descheduler documentation.
Is "EmptyNode" Deccheduler Stratergy a production ready solution? On what condition it determines a node to be Almost empty ..is it Non Daemonset Pod count or the node resource utilization. Are there any thershold to be configured or it is self intelligent to take a decision. Please refer to the below sample descheduler policy and let me know if this is good to be used-

deschedulerPolicy:
profiles:
- name: EmptyNodeEviction
pluginConfig:
- name: EmptyNode # This is the key plugin for your goal
args: {} # No specific args needed for EmptyNode strategy, it just checks for empty nodes
- name: DefaultEvictor # Essential evictor to perform the eviction
args:
evictFailedBarePods: false
evictLocalStoragePods: false # Be cautious with local storage pods
evictSystemCriticalPods: false
evictDaemonSetPods: false # Usually you don't want to evict DaemonSets as they'll just reschedule
ignorePvcPods: false # Set to true if you have PVCs you don't want to evict
nodeFit: true # Crucial: only evict if the pod can be scheduled elsewhere
plugins:
deschedule:
enabled:
- EmptyNode # Enable the EmptyNode strategy

[googs1025]

Is this scenario already covered by the LowNodeUtilization plugins? Or should we just can use kubectl drain?

[Sujit-sys]

LowNodeUtilization evicts pods from OverUtilized nodes to a LowUtilized nodes, my query is how can we achieve the other way around i.e. evicting pods from a Low utilized nodes so that it gets empty and Cluster Auto Scaler can identify that node and terminate. Drin is somthing that needs manual intervention..

This "EmptyNode" stratergy is somthing which would be highly helpful here...I wanted that to be checked with our Community here

[ingvagabund]

There's a HighNodeUtilization strategy focusing on evicting pods from lowly utilized nodes. Have you had a chance to explore this plugin?

[Sujit-sys]

@ingvagabund I have explored highnodeutilisation , but on what basis is this strategy marking the nodes as “overutilized” as its policy threshold only decides the “underutilized” nodes if I am only using Highnodeutilization strategy.

I have tested few scenarios wherein inspite of node being marked Underutilised by descheduler its not evicting the pods from there as all the other nodes are marked as overutilized. I want to understand on what basis they are being marked as overutilized by descheduler.

Please share if there is any community slack channel where we can discuss this more.

[ricardomaraschini]

@Sujit-sys I think there is an example on how to make nodes over utilized in the README. I reproduce it here for easy reference:

apiVersion: "descheduler/v1alpha2"
kind: "DeschedulerPolicy"
profiles:
  - name: ProfileName
    pluginConfig:
    - name: "HighNodeUtilization"
      args:
        thresholds:
          "cpu" : 20
          "memory": 20
          "pods": 20
        evictableNamespaces:
          exclude:
          - "kube-system"
          - "namespace1"
        evictionModes:
          - "OnlyThresholdingResources"
    plugins:
      balance:
        enabled:
          - "HighNodeUtilization"

Specifically the thresholds section. Nodes with usage below these thresholds are deemed underutilized and their pods are eligible to be evicted.

EDIT For sake of completeness, nodes that aren't deemed underutilized are deemed overutilized (i.e. they are the nodes to which we want to migrate pods).

[ingvagabund]

@Sujit-sys is this issue still relevant for you? Have you had a chance to explore #1730 (comment)?