Enable descheduler by default in management cluster with rules for pods violating affinity/antiaffinity (!7800) · Merge requests · Sylva-projects / sylva-core

What does this MR do and why?

This MR configures the descheduler by adding safe plugins that evict misplaced pods, such as:

RemovePodsViolatingInterPodAntiAffinity
RemovePodsViolatingNodeAffinity in order to allow us to use softAntiAffinity in various places which is putting less constraints during node rolling upgrades without the drawback of having collocated pods as they'll be re-scheduled.

Test coverage

The RemovePodsViolatingNodeAffinity was tested on my CAPO environment and everything worked fine. I added a label (disktype=ssd) to one of my nodes (teodora-cluster-cp-137a48c076-8drsk) and I created a deployment with 1 replica that contained this NodeAffinity:

     affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              - key: disktype
                operator: In
                values:
                - ssd

k get po -n sylva-system  affinity-test-76fc97768d-6qsph  -o wide
NAME                             READY   STATUS    RESTARTS   AGE   IP             NODE                                  NOMINATED NODE   READINESS GATES
affinity-test-76fc97768d-6qsph   1/1     Running   0          16s   100.72.79.92   teodora-cluster-cp-137a48c076-8drsk   <none>           <none>

Once I created the deployment, it was scheduled on the labeled node. In order to test the plugin, I labeled another node (teodora-cluster-cp-137a48c076-7nr78) and deleted it from the one that the pod was placed on (teodora-cluster-cp-137a48c076-8drsk). Right after, I created a job similar to the descheduler, and the pod was evicted.


kubectl logs job/descheduler-test2 -n kube-system  | grep -i evict
I0512 12:54:30.413885       1 descheduler.go:235] Resetting pod evictor counters
I0512 12:54:30.415068       1 profile.go:387] "Total number of evictions/requests" extension point="Deschedule" evictedPods=0 evictionRequests=0
I0512 12:54:30.417343       1 node_affinity.go:143] "Evicting pod" plugin="RemovePodsViolatingNodeAffinity" pod="sylva-system/affinity-test-76fc97768d-6qsph"
I0512 12:54:30.442937       1 evictions.go:558] "Evicted pod" pod="sylva-system/affinity-test-76fc97768d-6qsph" reason="" strategy="RemovePodsViolatingNodeAffinity" node="teodora-cluster-cp-137a48c076-8drsk" profile="sylva"
I0512 12:54:30.443357       1 profile.go:387] "Total number of evictions/requests" extension point="Deschedule" evictedPods=1 evictionRequests=0
I0512 12:54:30.443984       1 profile.go:417] "Total number of evictions/requests" extension point="Balance" evictedPods=0 evictionRequests=0
I0512 12:54:30.444522       1 profile.go:417] "Total number of evictions/requests" extension point="Balance" evictedPods=0 evictionRequests=0
I0512 12:54:30.444532       1 descheduler.go:252] "Number of evictions/requests" totalEvicted=1 evictionRequests=0

k get po -n sylva-system affinity-test-76fc97768d-4jf84 -o wide
NAME                             READY   STATUS    RESTARTS   AGE   IP             NODE                                  NOMINATED NODE   READINESS GATES
affinity-test-76fc97768d-4jf84   1/1     Running   0          27m   100.72.13.78   teodora-cluster-cp-137a48c076-7nr78   <none>           <none>

Regarding RemovePodsViolatingInterPodAntiAffinity, I tried to test it by creating different pods & deployments containing anti-affinity rules. When it comes to pods, it is impossible to edit the affinity rules once they are already running. I also tested it using deployments with multiple replicas, but theRemoveDuplicates plugin was triggered instead of RemovePodsViolatingInterPodAntiAffinity.

CI configuration

Below you can choose test deployment variants to run in this MR's CI.

Click to open to CI configuration

Legend:

Icon	Meaning	Available values
☁️	Infra Provider	`capd`, `capo`, `capm3`
🚀	Bootstrap Provider	`kubeadm` (alias `kadm`), `rke2`, `okd`, `ck8s`
🐧	Node OS	`ubuntu`, `suse`, `na`, `leapmicro`
🛠️	Deployment Options	Deployment option list and description
🎬	Pipeline Scenarios	Available scenario list and description
🟢	Enabled units	Any available units name, by default apply to management and workload cluster. Can be prefixed by `mgmt:` or `wkld:` to be applied only to a specific cluster type
🔴	Disabled units	Any available units name, by default apply to management and workload cluster. Can be prefixed by `mgmt:` or `wkld:` to be applied only to a specific cluster type
🏗️	Target platform	Can be used to select specific deployment environment Available platform list and description
⚡	Pipeline control	`autorun`, `manual` or `blocking`. Can be used to override global config and start a deployment pipeline the required way

Global config for deployment pipelines

autorun pipelines
allow failure on pipelines
record sylvactl events

Notes:

Enabling autorun will make deployment pipelines to be run automatically without human interaction
Disabling allow failure will make deployment pipelines mandatory for pipeline success.
if both autorun and allow failure are disabled, deployment pipelines will need manual triggering but will be blocking the pipeline

Be aware: after configuration change, pipeline is not triggered automatically. Please run it manually (by clicking the run pipeline button in Pipelines tab) or push new code.

Edited May 18, 2026 by Thomas Morin

Enable descheduler by default in management cluster with rules for pods violating affinity/antiaffinity

What does this MR do and why?

Related reference(s)

Test coverage

CI configuration

Global config for deployment pipelines

Merge request reports