Bug 1904501 - [Descheduler] descheduler does not evict any pod when PodTopologySpreadConstraint strategy is set
Summary: [Descheduler] descheduler does not evict any pod when PodTopologySpreadConstr...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: kube-scheduler
Version: 4.7
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: ---
: 4.7.0
Assignee: Mike Dame
QA Contact: RamaKasturi
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-12-04 16:05 UTC by RamaKasturi
Modified: 2021-02-24 15:39 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2021-02-24 15:37:53 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github openshift descheduler pull 48 0 None open Bug 1904501: sync upstream 2020-12-04 17:38:19 UTC
Red Hat Product Errata RHSA-2020:5633 0 None None None 2021-02-24 15:39:59 UTC

Description RamaKasturi 2020-12-04 16:05:20 UTC
Description of problem:
Descheduler does not evict any pod when PodTopologySpreadConstraint strategy is set


Version-Release number of selected component (if applicable):
clusterkubedescheduleroperator.4.7.0-202012031911.p0

How reproducible:
Always

Steps to Reproduce:
1. Install latest 4.7 cluster, install descheduler
2. Enable profile TopologyAndDuplicates
3. label two nodes with zone=zoneA & zone=zoneB respectively
3. Now create 3 pods on one node and one pod on another node

Actual results:
Descheduler does not evict anypod

Expected results:
Descheduler should evict pods to get 2 = 2, i.e 2 pods on one node another 2 pods on second node.

Additional info:
o it works for me to run the descheduler without the operator, but with the operator it doesn’t evict anything. The only difference is that we’re passing in a list of excluded namespaces in the operator, so I think this line might be breaking it: https://github.com/kubernetes-sigs/descheduler/blob/master/pkg/descheduler/strategies/topologyspreadconstraint.go#L113
in this case includedNamespaces is empty, so it won’t have the namespace… but included+excluded is >0 since we’re passing a list of excluded namespaces. So this is skipping every namespace

Comment 2 RamaKasturi 2020-12-07 16:56:03 UTC
Verified bug with payload below and i see that pods get evicted when PodTopologySpreadConstraint is enabled.

[knarra@knarra openshift-client-linux-4.7.0-0.nightly-2020-12-04-013308]$ ./oc get csv
NAME                                                   DISPLAY                            VERSION                 REPLACES   PHASE
clusterkubedescheduleroperator.4.7.0-202012050255.p0   Kube Descheduler Operator          4.7.0-202012050255.p0              Succeeded

[knarra@knarra openshift-client-linux-4.7.0-0.nightly-2020-12-04-013308]$ ./oc get clusterversion
NAME      VERSION                             AVAILABLE   PROGRESSING   SINCE   STATUS
version   4.7.0-0.nightly-2020-12-04-013308   True        False         13h     Cluster version is 4.7.0-0.nightly-2020-12-04-013308

registry.redhat.io/openshift4/ose-descheduler@sha256:1da501059d77a6fa72e6d10b0b1a7a0cc50f2abdffa07daef742b77c889964ea
registry.redhat.io/openshift4/ose-cluster-kube-descheduler-operator@sha256:3585a22428dd6fb2cd3b363667b134e1374dd250a6bc381ff665003e9a303381

I1207 16:37:54.002204       1 topologyspreadconstraint.go:109] "Processing namespaces for topology spread constraints"
I1207 16:37:54.102887       1 evictions.go:117] "Evicted pod" pod="knarra/mypod2h5l2k" reason=" (PodTopologySpread)"
I1207 16:37:54.117557       1 evictions.go:117] "Evicted pod" pod="knarra/mypod2d67q5" reason=" (PodTopologySpread)"

Based on the above moving bug to verified state.

Comment 5 errata-xmlrpc 2021-02-24 15:37:53 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (Moderate: OpenShift Container Platform 4.7.0 security, bug fix, and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2020:5633


Note You need to log in before you can comment on or make changes to this bug.