kubernetes-sigs / descheduler

Descheduler for Kubernetes
https://sigs.k8s.io/descheduler
Apache License 2.0
4.51k stars 675 forks source link

All nodes are underutilized, nothing to do here #755

Closed ghostsquad closed 2 years ago

ghostsquad commented 2 years ago

What version of descheduler are you using?

descheduler version: 0.23.1

Does this issue reproduce with the latest release?

Yes.

Which descheduler CLI options are you using?

image: "k8s.gcr.io/descheduler/descheduler:v0.23.1"
command:
  - "/bin/descheduler"
args:
  - "--policy-config-file"
  - "/policy-dir/policy.yaml"
  - "--descheduling-interval"
  - 5m
  - "--v"
  - "3"
policy.yaml: |
  apiVersion: "descheduler/v1alpha1"
  kind: "DeschedulerPolicy"
  strategies:
    LowNodeUtilization:
      enabled: true
      params:
        nodeResourceUtilizationThresholds:
          targetThresholds:
            cpu: 80
            memory: 80
            pods: 80
          thresholds:
            cpu: 60
            memory: 60
            pods: 70
    HighNodeUtilization:
      enabled: true
      params:
        nodeResourceUtilizationThresholds:
          thresholds:
            cpu: 60
            memory: 60
            pods: 70
    RemoveDuplicates:
      enabled: true
    RemovePodsViolatingInterPodAntiAffinity:
      enabled: true
    RemovePodsViolatingNodeAffinity:
      enabled: true
      params:
        nodeAffinityType:
        - requiredDuringSchedulingIgnoredDuringExecution
    RemovePodsViolatingNodeTaints:
      enabled: true

What k8s version are you using (kubectl version)?

kubectl version Output
$ kubectl version
Client Version: version.Info{Major:"1", Minor:"21", GitVersion:"v1.21.9", GitCommit:"b631974d68ac5045e076c86a5c66fba6f128dc72", GitTreeState:"clean", BuildDate:"2022-01-19T17:51:12Z", GoVersion:"go1.16.12", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"21+", GitVersion:"v1.21.5-eks-bc4871b", GitCommit:"5236faf39f1b7a7dabea8df12726f25608131aa9", GitTreeState:"clean", BuildDate:"2021-10-29T23:32:16Z", GoVersion:"go1.16.8", Compiler:"gc", Platform:"linux/amd64"}

What did you do?

just applying the descheduler to a test/dev cluster for the first time. Nothing special.

What did you expect to see?

Here was the starting point, (from spotinst), which I'm trying to optimize.

image

4 Nodes, I expect to see at least one of the nodes to be cordoned and drained as to improve the utilization overall. I wouldn't mind this happening in cycles, where at least 1 node is cordoned & drained, waiting for pods to be rescheduled before then rechecking for utilization, and repeating until reaching some equilibrium.

What did you see instead?

1 highnodeutilization.go:90] "Criteria for a node below target utilization" CPU=60 Mem=60 Pods=70
1 highnodeutilization.go:91] "Number of underutilized nodes" totalNumber=4
1 highnodeutilization.go:102] "All nodes are underutilized, nothing to do here"

1 lownodeutilization.go:101] "Criteria for a node under utilization" CPU=60 Mem=60 Pods=70
1 lownodeutilization.go:102] "Number of underutilized nodes" totalNumber=4
1 lownodeutilization.go:115] "Criteria for a node above target utilization" CPU=80 Mem=80 Pods=80
1 lownodeutilization.go:116] "Number of overutilized nodes" totalNumber=0
1 lownodeutilization.go:129] "All nodes are underutilized, nothing to do here"
ghostsquad commented 2 years ago

So, I didn't realize that the high and low strategies are in fact opposite. I thought highutilization would try to selectively lower the utilization of over-burdened nodes, and lowutilization would attempt to eliminate those nodes (by evicting, and having the pods move elsewhere).

I understand that, I have these backwards. Highutilization is the goal (thus it eliminates low utilization nodes through eviction). In theory, I could still run lowutilization strategy, but I'd have to make sure the targets were sufficient different between these 2 strategies as to avoid a perpetual back and forth eviction.

Regardless of this misunderstanding, it seems when all nodes are under utilized, neither strategy does anything. I expect at minimum (at this point), that the highnodeutilization strategy would loop through all under utilized nodes and begin evicting until node utilization reaches a specific threshold OR there are less than the NumberOfNodes flag.

JaneLiuL commented 2 years ago

hi , thanks for raise this issue, actually we have a very similar issue: #725

ghostsquad commented 2 years ago

Thank you. I'll close as duplicate