You can use the descheduler to evict pods based on specific strategies so that the pods can be rescheduled onto more appropriate nodes.
You can benefit from descheduling running pods in situations such as the following:
-
Nodes are underutilized or overutilized.
-
Pod and node affinity requirements, such as taints or labels, have changed and the original scheduling decisions are no longer appropriate for certain nodes.
-
Node failure requires pods to be moved.
-
New nodes are added to clusters.
-
Pods have been restarted too many times.
|
The descheduler does not schedule replacement of evicted pods. The scheduler automatically performs this task for the evicted pods.
|
When the descheduler decides to evict pods from a node, it employs the following general mechanism:
-
Pods in the openshift-*
and kube-system
namespaces are never evicted.
-
Critical pods with priorityClassName
set to system-cluster-critical
or system-node-critical
are never evicted.
-
Static, mirrored, or stand-alone pods that are not part of a replication controller, replica set, deployment, or job are never evicted because these pods will not be recreated.
-
Pods associated with daemon sets are never evicted.
-
Pods with local storage are never evicted.
-
Best effort pods are evicted before burstable and guaranteed pods.
-
All types of pods with the descheduler.alpha.kubernetes.io/evict
annotation are eligible for eviction. This annotation is used to override checks that prevent eviction, and the user can select which pod is evicted. Users should know how and if the pod will be recreated.
-
Pods subject to pod disruption budget (PDB) are not evicted if descheduling violates its pod disruption budget (PDB). The pods are evicted by using eviction subresource to handle PDB.