<commit_before>// Module included in the following assemblies:
//
// * nodes/nodes-scheduler-descheduler.adoc

[id='nodes-scheduler-descheduling-about_{context}']
= Understanding how to evict pods in {product-title}

Because {product-title} clusters are highly dynamic and their state changes over time 
your cluster can benefit from descheduling pods from one node and rescheduling onto a more appropriate node for various reasons:

* Nodes are under- or over-utilized.
* Pod and node affinity requirements, such as taints or labels, have changed and the original scheduling decisions are longer appropriate for certain nodes.
* Node failure requires pods to be moved.
* New nodes are added to clusters.

The descheduler does not schedule replacement of evicted pods. The scheduler automatically performs this task for the evicted pods.

It is important to note that there are a number of core components, such as Heapster and DNS, that are critical to a fully functional cluster,
but, run on a regular cluster node rather than the master. A cluster may stop working properly if the component is evicted. To prevent the
descheduler from removing these pods, configure the pod as a critical pod by adding a priority class to the pod specification.

[NOTE]
====
The descheduler job is considered a critical pod, which prevents the descheduler pod from being evicted by the descheduler.
====

The descheduler job and descheduler pod are created in the `kube-system` project, which is created by default.

[IMPORTANT]
====
The descheduler is a Technology Preview feature only.
ifdef::openshift-enterprise[]
Technology Preview features are not supported with Red Hat production service
level agreements (SLAs), might not be functionally complete, and Red Hat does
not recommend to use them for 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 on Red Hat Technology Preview features support scope, see
https://access.redhat.com/support/offerings/techpreview/.
endif::[]
====

The descheduler does not evict the following types of pods:

* Critical pods (with an appropriate priority class).
* Pods (link:https://kubernetes.io/docs/tasks/administer-cluster/static-pod/[static and mirror pods] or pods in standalone mode) not associated with a ReplicaSet, Replication Controller, Deployment, or Job (because these pods are not recreated).
* Pods associated with DaemonSets.
* Pods with local storage.
* Pods subject to Pod Disruption Budget (PDB) are not evicted if descheduling violates the PDB. The pods can be evicted using
an eviction policy.

[NOTE]
====
Best efforts pods are evicted before Burstable and Guaranteed pods.
====

The following sections describe the process to configure and run the descheduler:

* Create a role with the needed permissions. 

* Define the descheduling behavior in a policy file. 

* Create a configuration map to reference the policy file.

* Create the descheduler job configuration.

* Run the descheduler job.

[[nodes-scheduler-descheduling-policy-about]]
== Understanding descheduler policies

There are four default strategies that can be used with the descheduler.

Move pods to underutilized nodes::
The `LowNodeUtilization` strategy finds nodes that are underutilized and evicts pods from other nodes so that the evicted pods can be scheduled on these underutilized nodes.

The underutilization of nodes is determined by a configurable threshold, `thresholds`, for CPU, memory, or number of pods (based on percentage). If a node usage is below all these thresholds, the node is considered underutilized and the descheduler can evict pods from other nodes. Pods request resource requirements are considered when computing node resource utilization.

A high threshold value, `targetThresholds` is used to determine properly utilized nodes. Any node that is between the _thresholds_ and _targetThresholds_ is considered properly utilized and is not considered for eviction. The threshold, `targetThresholds`, can be configured for CPU, memory, and number of pods (based on percentage).

These thresholds could be tuned for your cluster requirements.

The `numberOfNodes` parameter can be configured to activate the strategy only when number of underutilized nodes is above the configured value. Set this parameter if it is acceptable for a few nodes to go underutilized. By default, `numberOfNodes` is set to zero.

Remove Duplicate Pods::
The `RemoveDuplicates` strategy ensures that there is only one pod associated with a ReplicaSet, Replication Controller, DeploymentConfig, or Job running on same node.
If there are other pods associated with those objects, the duplicate pods are evicted. Removing duplicate pods results in better spreading of pods in a cluster.

For example, duplicate pods could happen if a node fails and the pods on the node are moved to another node, leading to more than one pod associated with an ReplicaSet or Replication Controller, running on same node. After the failed node is ready again, this strategy could be used to evict those duplicate pods.

There are no parameters associated with this strategy.

Remove Pods Violating Inter-Pod Anti-Affinity::
The `interpodantiaffinity` strategy ensures that pods violating inter-pod anti-affinity are removed from nodes.

For example, *Node1* has *podA*, *podB*, and *podC*. *podB* and *podC* have anti-affinity rules that prohibit them from running on the same node as *podA*. *podA* will be evicted from the node so that *podB* and *podC* can run on that node. This situation could happen if the anti-affinity rule was applied when *podB* and *podC* were running on the node.

Remove Pods Violating Node Affinity::
The `RemovePodsViolatingNodeAffinity` strategy ensures that pods violating node affinity are removed from nodes. 

For example, *nodeA* has *podA* which satisfied the node affinity rules at the time of scheduling. If over time *nodeA* no longer satisfies the rule and *nodeB* is available that satisfies the node affinity rule, *podA* is be evicted from *nodeA*.
<commit_msg>typo per PR-13702<commit_after>// Module included in the following assemblies:
//
// * nodes/nodes-scheduler-descheduler.adoc

[id='nodes-scheduler-descheduling-about_{context}']
= Understanding how to evict pods in {product-title}

Because {product-title} clusters are highly dynamic and their state changes over time 
your cluster can benefit from descheduling pods from one node and rescheduling onto a more appropriate node for various reasons:

* Nodes are under- or over-utilized.
* 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.

The descheduler does not schedule replacement of evicted pods. The scheduler automatically performs this task for the evicted pods.

It is important to note that there are a number of core components, such as Heapster and DNS, that are critical to a fully functional cluster,
but, run on a regular cluster node rather than the master. A cluster may stop working properly if the component is evicted. To prevent the
descheduler from removing these pods, configure the pod as a critical pod by adding a priority class to the pod specification.

[NOTE]
====
The descheduler job is considered a critical pod, which prevents the descheduler pod from being evicted by the descheduler.
====

The descheduler job and descheduler pod are created in the `kube-system` project, which is created by default.

[IMPORTANT]
====
The descheduler is a Technology Preview feature only.
ifdef::openshift-enterprise[]
Technology Preview features are not supported with Red Hat production service
level agreements (SLAs), might not be functionally complete, and Red Hat does
not recommend to use them for 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 on Red Hat Technology Preview features support scope, see
https://access.redhat.com/support/offerings/techpreview/.
endif::[]
====

The descheduler does not evict the following types of pods:

* Critical pods (with an appropriate priority class).
* Pods (link:https://kubernetes.io/docs/tasks/administer-cluster/static-pod/[static and mirror pods] or pods in standalone mode) not associated with a ReplicaSet, Replication Controller, Deployment, or Job (because these pods are not recreated).
* Pods associated with DaemonSets.
* Pods with local storage.
* Pods subject to Pod Disruption Budget (PDB) are not evicted if descheduling violates the PDB. The pods can be evicted using
an eviction policy.

[NOTE]
====
Best efforts pods are evicted before Burstable and Guaranteed pods.
====

The following sections describe the process to configure and run the descheduler:

* Create a role with the needed permissions. 

* Define the descheduling behavior in a policy file. 

* Create a configuration map to reference the policy file.

* Create the descheduler job configuration.

* Run the descheduler job.

[[nodes-scheduler-descheduling-policy-about]]
== Understanding descheduler policies

There are four default strategies that can be used with the descheduler.

Move pods to underutilized nodes::
The `LowNodeUtilization` strategy finds nodes that are underutilized and evicts pods from other nodes so that the evicted pods can be scheduled on these underutilized nodes.

The underutilization of nodes is determined by a configurable threshold, `thresholds`, for CPU, memory, or number of pods (based on percentage). If a node usage is below all these thresholds, the node is considered underutilized and the descheduler can evict pods from other nodes. Pods request resource requirements are considered when computing node resource utilization.

A high threshold value, `targetThresholds` is used to determine properly utilized nodes. Any node that is between the _thresholds_ and _targetThresholds_ is considered properly utilized and is not considered for eviction. The threshold, `targetThresholds`, can be configured for CPU, memory, and number of pods (based on percentage).

These thresholds could be tuned for your cluster requirements.

The `numberOfNodes` parameter can be configured to activate the strategy only when number of underutilized nodes is above the configured value. Set this parameter if it is acceptable for a few nodes to go underutilized. By default, `numberOfNodes` is set to zero.

Remove Duplicate Pods::
The `RemoveDuplicates` strategy ensures that there is only one pod associated with a ReplicaSet, Replication Controller, DeploymentConfig, or Job running on same node.
If there are other pods associated with those objects, the duplicate pods are evicted. Removing duplicate pods results in better spreading of pods in a cluster.

For example, duplicate pods could happen if a node fails and the pods on the node are moved to another node, leading to more than one pod associated with an ReplicaSet or Replication Controller, running on same node. After the failed node is ready again, this strategy could be used to evict those duplicate pods.

There are no parameters associated with this strategy.

Remove Pods Violating Inter-Pod Anti-Affinity::
The `interpodantiaffinity` strategy ensures that pods violating inter-pod anti-affinity are removed from nodes.

For example, *Node1* has *podA*, *podB*, and *podC*. *podB* and *podC* have anti-affinity rules that prohibit them from running on the same node as *podA*. *podA* will be evicted from the node so that *podB* and *podC* can run on that node. This situation could happen if the anti-affinity rule was applied when *podB* and *podC* were running on the node.

Remove Pods Violating Node Affinity::
The `RemovePodsViolatingNodeAffinity` strategy ensures that pods violating node affinity are removed from nodes. 

For example, *nodeA* has *podA* which satisfied the node affinity rules at the time of scheduling. If over time *nodeA* no longer satisfies the rule and *nodeB* is available that satisfies the node affinity rule, *podA* is be evicted from *nodeA*.

{'fraction_non_alphanumeric': 0.048964677222898906, 'fraction_numerical': 0.0005684125050751116, 'mean_word_length': 4.924001924001924, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 4, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '4661116', 'n_tokens_mistral': 3055, 'n_tokens_neox': 2939, 'n_words': 1755}