While the scheduler is used to determine the most suitable node to host a new Pod, the descheduler can be used to evict a running Pod so that the Pod can be rescheduled onto a more suitable node.

The descheduler is a Technology Preview feature only. Technology Preview features are not supported with Red Hat production service level agreements (SLAs) and might not be functionally complete. Red Hat does not recommend using them in production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process.

For more information about the support scope of Red Hat Technology Preview features, see https://access.redhat.com/support/offerings/techpreview/.

About the descheduler

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:

  • 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 ReplicationController, ReplicaSet, Deployment or Job are never evicted because these Pods will not be recreated.

  • Pods associated with DaemonSets are never evicted.

  • Pods with local storage are never evicted.

  • BestEffort Pods are evicted before Burstable and Guaranteed Pods.

  • All types of Pods with the descheduler.alpha.kubernetes.io/evict annotation are evicted. 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.

Descheduler strategies

The following descheduler strategies are available:

Low node utilization

The LowNodeUtilization strategy finds nodes that are underutilized and evicts Pods, if possible, from other nodes in the hope that recreation of evicted Pods will be scheduled on these underutilized nodes.

The underutilization of nodes is determined by several configurable threshold parameters: CPU, memory, and number of Pods. If a node’s usage is below the configured thresholds for all parameters (CPU, memory, and number of Pods), then the node is considered to be underutilized.

You can also set a target threshold for CPU, memory, and number of Pods. If a node’s usage is above the configured target thresholds for all parameters, then the node’s Pods might be considered for eviction.

Additionally, you can use the NumberOfNodes parameter to set the strategy to activate only when the number of underutilized nodes is above the configured value. This can be helpful in large clusters where a few nodes might be underutilized frequently or for a short period of time.

Duplicate Pods

The RemoveDuplicates strategy ensures that there is only one Pod associated with a ReplicaSet, ReplicationController, Deployment, or Job running on same node. If there are more, then those duplicate Pods are evicted for better spreading of Pods in a cluster.

This situation could occur after a node failure, when a Pod is moved to another node, leading to more than one Pod associated with a ReplicaSet, ReplicationController, Deployment, or Job on that node. After the failed node is ready again, this strategy evicts the duplicate Pod.

Violation of inter-pod anti-affinity

The RemovePodsViolatingInterPodAntiAffinity strategy ensures that Pods violating inter-pod anti-affinity are removed from nodes.

This situation could occur when anti-affinity rules are created for Pods that are already running on the same node.

Violation of node affinity

The RemovePodsViolatingNodeAffinity strategy ensures that Pods violating node affinity are removed from nodes.

This situation could occur if a node no longer satisfies a Pod’s affinity rule. If another node is available that satisfies the affinity rule, then the Pod is evicted.

Violation of node taints

The RemovePodsViolatingNodeTaints strategy ensures that Pods violating NoSchedule taints on nodes are removed.

This situation could occur if a Pod is set to tolerate a taint key=value:NoSchedule and is running on a tainted node. If the node’s taint is updated or removed, the taint is no longer satisfied by the Pod’s tolerations and the Pod is evicted.

Too many restarts

The RemovePodsHavingTooManyRestarts strategy ensures that Pods that have been restarted too many times are removed from nodes.

This situation could occur if a Pod is scheduled on a node that is unable to start it. For example, if the node is having network issues and is unable to mount a networked persistent volume, then the Pod should be evicted so that it can be scheduled on another node. Another example is if the Pod is crashlooping.

This strategy has two configurable parameters: PodRestartThreshold and IncludingInitContainers. If a Pod is restarted more than the configured PodRestartThreshold value, then the Pod is evicted. You can use the IncludingInitContainers parameter to specify whether restarts for Init Containers should be calculated into the PodRestartThreshold value.

Installing the descheduler

The descheduler is not available by default. To enable the descheduler, you must install the Kube Descheduler Operator from OperatorHub. After the Kube Descheduler Operator is installed, you can then configure the eviction strategies.

Prerequisites
  • Cluster administrator privileges.

  • Access to the OKD web console.

Procedure
  1. Log in to the OKD web console.

  2. Create the required namespace for the Kube Descheduler Operator.

    1. Navigate to AdministrationNamespaces and click Create Namespace.

    2. Enter openshift-kube-descheduler-operator in the Name field and click Create.

  3. Install the Kube Descheduler Operator.

    1. Navigate to OperatorsOperatorHub.

    2. Type Kube Descheduler Operator into the filter box.

    3. Select the Kube Descheduler Operator and click Install.

    4. On the Create Operator Subscription page, select A specific namespace on the cluster. Select openshift-kube-descheduler-operator from the drop-down menu.

    5. Adjust the values for the Update Channel and Approval Strategy to the desired values.

    6. Click Subscribe.

  4. Create a descheduler instance.

    1. From the OperatorsInstalled Operators page, click the Kube Descheduler Operator.

    2. Select the Kube Descheduler tab and click Create KubeDescheduler.

    3. Edit the settings as necessary and click Create.

You can now configure the strategies for the descheduler. There are no strategies enabled by default.

Configuring descheduler strategies

You can configure which strategies the descheduler uses to evict Pods.

Prerequisites
  • Cluster administrator privileges.

Procedure
  1. Edit the KubeDescheduler object:

    $ oc edit kubedeschedulers.operator.openshift.io cluster -n openshift-kube-descheduler-operator
  2. Specify one or more strategies in the spec.strategies section.

    apiVersion: operator.openshift.io/v1beta1
    kind: KubeDescheduler
    metadata:
      name: cluster
      namespace: openshift-kube-descheduler-operator
    spec:
      deschedulingIntervalSeconds: 3600
      strategies:
        - name: "LowNodeUtilization" (1)
          params:
           - name: "CPUThreshold"
             value: "10"
           - name: "MemoryThreshold"
             value: "20"
           - name: "PodsThreshold"
             value: "30"
           - name: "MemoryTargetThreshold"
             value: "40"
           - name: "CPUTargetThreshold"
             value: "50"
           - name: "PodsTargetThreshold"
             value: "60"
           - name: "NumberOfNodes"
             value: "3"
        - name: "RemoveDuplicates" (2)
        - name: "RemovePodsHavingTooManyRestarts" (3)
          params:
           - name: "PodRestartThreshold"
             value: "10"
           - name: "IncludingInitContainers"
             value: "false"
    1 The LowNodeUtilization strategy provides additional parameters, such as CPUThreshold and MemoryThreshold, that you can optionally configure.
    2 The RemoveDuplicates, RemovePodsViolatingInterPodAntiAffinity, RemovePodsViolatingNodeAffinity, and RemovePodsViolatingNodeTaints strategies do not have any additional parameters to configure.
    3 The RemovePodsHavingTooManyRestarts strategy requires the PodRestartThreshold parameter to be set. It also provides the optional IncludingInitContainers parameter.

    You can enable multiple strategies and the order that the strategies are specified in is not important.

  3. Save the file to apply the changes.

Configuring additional descheduler settings

You can configure additional settings for the descheduler, such as how frequently it runs.

Prerequisites
  • Cluster administrator privileges.

Procedure
  1. Edit the KubeDescheduler object:

    $ oc edit kubedeschedulers.operator.openshift.io cluster -n openshift-kube-descheduler-operator
  2. Configure additional settings as necessary:

    apiVersion: operator.openshift.io/v1beta1
    kind: KubeDescheduler
    metadata:
      name: cluster
      namespace: openshift-kube-descheduler-operator
    spec:
      deschedulingIntervalSeconds: 3600 (1)
      flags:
      - --dry-run (2)
      image: quay.io/openshift/origin-descheduler:4.4 (3)
    ...
    1 Set number of seconds between descheduler runs. A value of 0 in this field runs the descheduler once and exits.
    2 Set one or more flags to append to the descheduler Pod. This flag must be in the format ready to pass to the binary.
    3 Set the descheduler container image to deploy.
  3. Save the file to apply the changes.