diff --git a/modules/nodes-scheduler-node-affinity-about.adoc b/modules/nodes-scheduler-node-affinity-about.adoc index addc95eab4c7..9f1765ebe7b0 100644 --- a/modules/nodes-scheduler-node-affinity-about.adoc +++ b/modules/nodes-scheduler-node-affinity-about.adoc @@ -6,9 +6,8 @@ [id="nodes-scheduler-node-affinity-about_{context}"] = Understanding node affinity -Node affinity allows a pod to specify an affinity towards a group of nodes it can be placed on. The node does not have control over the placement. - -For example, you could configure a pod to only run on a node with a specific CPU or in a specific availability zone. +[role="_abstract"] +To specify a preference towards a group of nodes that a pod can be placed on, you can use a node affinity in the pod spec. For example, you could configure a pod to run only on a node with a specific CPU or in a specific availability zone. The node does not have control over the placement. There are two types of node affinity rules: _required_ and _preferred_. @@ -36,15 +35,15 @@ spec: seccompProfile: type: RuntimeDefault affinity: - nodeAffinity: <1> - requiredDuringSchedulingIgnoredDuringExecution: <2> + nodeAffinity: + requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - - key: e2e-az-NorthSouth <3> - operator: In <4> + - key: e2e-az-NorthSouth + operator: In values: - - e2e-az-North <3> - - e2e-az-South <3> + - e2e-az-North + - e2e-az-South containers: - name: with-node-affinity image: docker.io/ocpqe/hello-pod @@ -54,11 +53,16 @@ spec: drop: [ALL] # ... ---- +where: -<1> The stanza to configure node affinity. -<2> Defines a required rule. -<3> The key/value pair (label) that must be matched to apply the rule. -<4> The operator represents the relationship between the label on the node and the set of values in the `matchExpression` parameters in the `Pod` spec. This value can be `In`, `NotIn`, `Exists`, or `DoesNotExist`, `Lt`, or `Gt`. +`spec.affinity.nodeAffinity`:: Specifies the stanza to configure node affinity. +`spec.affinity.nodeAffinity.requiredDuringSchedulingIgnoredDuringExecution`:: Specifies a _required_ rule. Configure the following `nodeSelectorTerms.matchExpressions` parameters: ++ +-- +`key`:: Specifies the key of the key/value pair (label) that must be matched to apply the rule. +`operator`:: Specifies the relationship between the label on the node and the set of values in the `matchExpression` parameters in the `Pod` spec. This value can be `In`, `NotIn`, `Exists`, or `DoesNotExist`, `Lt`, or `Gt`. +`values`:: Specifies the value of the key/value pair (label) that must be matched to apply the rule. +-- The following example is a node specification with a preferred rule that a node with a label whose key is `e2e-az-EastWest` and whose value is either `e2e-az-East` or `e2e-az-West` is preferred for the pod: @@ -75,16 +79,16 @@ spec: seccompProfile: type: RuntimeDefault affinity: - nodeAffinity: <1> - preferredDuringSchedulingIgnoredDuringExecution: <2> - - weight: 1 <3> + nodeAffinity: + preferredDuringSchedulingIgnoredDuringExecution: + - weight: 1 preference: matchExpressions: - - key: e2e-az-EastWest <4> - operator: In <5> + - key: e2e-az-EastWest + operator: In values: - - e2e-az-East <4> - - e2e-az-West <4> + - e2e-az-East + - e2e-az-West containers: - name: with-node-affinity image: docker.io/ocpqe/hello-pod @@ -94,16 +98,17 @@ spec: drop: [ALL] # ... ---- - -<1> The stanza to configure node affinity. -<2> Defines a preferred rule. -<3> Specifies a weight for a preferred rule. The node with highest weight is preferred. -<4> The key/value pair (label) that must be matched to apply the rule. -<5> The operator represents the relationship between the label on the node and -the set of values in the `matchExpression` parameters in the `Pod` spec. -This value can be `In`, `NotIn`, `Exists`, or `DoesNotExist`, `Lt`, or `Gt`. - -There is no explicit _node anti-affinity_ concept, but using the `NotIn` or `DoesNotExist` operator replicates that behavior. +where: + +`spec.affinity.nodeAffinity`:: Specifies the stanza to configure node affinity. +`spec.affinity.nodeAffinity.preferredDuringSchedulingIgnoredDuringExecution`:: Specifies a _preferred_ rule. Configure a weight and the following `preference.matchExpression` parameters: ++ +-- +`weight`:: Specifies a weight for a preferred rule. The node with highest weight is preferred. +`key`:: Specifies the key of the key/value pair (label) that must be matched to apply the rule. +`operator`:: Specifies the relationship between the label on the node and the set of values in the `matchExpression` parameters in the `Pod` spec. This value can be `In`, `NotIn`, `Exists`, or `DoesNotExist`, `Lt`, or `Gt`. There is no explicit _node anti-affinity_ concept, but using the `NotIn` or `DoesNotExist` operator replicates that behavior. +`values`:: Specifies the value of the key/value pair (label) that must be matched to apply the rule. +-- [NOTE] ==== diff --git a/modules/nodes-scheduler-node-affinity-configuring-preferred.adoc b/modules/nodes-scheduler-node-affinity-configuring-preferred.adoc index 8b44402f2517..b6b1316bb49f 100644 --- a/modules/nodes-scheduler-node-affinity-configuring-preferred.adoc +++ b/modules/nodes-scheduler-node-affinity-configuring-preferred.adoc @@ -6,11 +6,14 @@ [id="nodes-scheduler-node-affinity-configuring-preferred_{context}"] = Configuring a preferred node affinity rule -Preferred rules specify that, if the rule is met, the scheduler tries to enforce the rules, but does not guarantee enforcement. +[role="_abstract"] +You can use a _preferred_ rule to instruct the scheduler that if a matching node is not available, schedule the pod on a different node to ensure the workload application runs. -.Procedure +For a preferred rule, the scheduler tries to enforce the rule, but does not guarantee enforcement. + +The following procedure demonstrates a simple configuration that creates a node and a pod that the scheduler tries to place on the node. -The following steps demonstrate a simple configuration that creates a node and a pod that the scheduler tries to place on the node. +.Procedure ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[] . Add a label to a node using the `oc label node` command: @@ -37,23 +40,29 @@ kind: Pod metadata: name: s1 spec: - affinity: <1> + affinity: nodeAffinity: - preferredDuringSchedulingIgnoredDuringExecution: <2> - - weight: <3> + preferredDuringSchedulingIgnoredDuringExecution: + - weight: preference: matchExpressions: - - key: e2e-az-name <4> + - key: e2e-az-name values: - e2e-az3 - operator: In <5> + operator: In #... ---- -<1> Adds a pod affinity. -<2> Configures the `preferredDuringSchedulingIgnoredDuringExecution` parameter. -<3> Specifies a weight for the node, as a number 1-100. The node with highest weight is preferred. -<4> Specifies the `key` and `values` that must be met. If you want the new pod to be scheduled on the node you edited, use the same `key` and `values` parameters as the label in the node. -<5> Specifies an `operator`. The operator can be `In`, `NotIn`, `Exists`, or `DoesNotExist`. For example, use the operator `In` to require the label to be in the node. +where: + +`spec.affinity.nodeAffinity`:: Specifies the stanza to configure node affinity. +`spec.affinity.nodeAffinity.preferredDuringSchedulingIgnoredDuringExecution`:: Specifies a _preferred_ rule. Configure a weight and the following `preference.matchExpressions` parameters. If you want the new pod to be scheduled on the node you edited, use the same `key` and `values` parameters as the label in the node. ++ +-- +`weight`:: Specifies a weight for the node, as a number 1-100. The node with highest weight is preferred. +`key`:: Specifies the key of the key/value pair (label) that must be matched to apply the rule. +`operator`:: Specifies the relationship between the label on the node and the set of values in the `matchExpression` parameters in the `Pod` spec. This value can be `In`, `NotIn`, `Exists`, or `DoesNotExist`, `Lt`, or `Gt`. There is no explicit _node anti-affinity_ concept, but using the `NotIn` or `DoesNotExist` operator replicates that behavior. +`values`:: Specifies the value of the key/value pair (label) that must be matched to apply the rule. +-- .. Create the pod. + diff --git a/modules/nodes-scheduler-node-affinity-configuring-required.adoc b/modules/nodes-scheduler-node-affinity-configuring-required.adoc index 3c412ddadb80..2624b475244a 100644 --- a/modules/nodes-scheduler-node-affinity-configuring-required.adoc +++ b/modules/nodes-scheduler-node-affinity-configuring-required.adoc @@ -6,12 +6,13 @@ [id="nodes-scheduler-node-affinity-configuring-required_{context}"] = Configuring a required node affinity rule -Required rules *must* be met before a pod can be scheduled on a node. - -.Procedure +[role="_abstract"] +You can use a _required_ rule to instruct the scheduler that the rules *must* be met before a pod can be scheduled on a node. The following steps demonstrate a simple configuration that creates a node and a pod that the scheduler is required to place on the node. +.Procedure + ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[] . Add a label to a node using the `oc label node` command: + @@ -54,22 +55,28 @@ kind: Pod metadata: name: s1 spec: - affinity: <1> + affinity: nodeAffinity: - requiredDuringSchedulingIgnoredDuringExecution: <2> + requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - - key: e2e-az-name <3> + - key: e2e-az-name values: - e2e-az1 - e2e-az2 - operator: In <4> + operator: In #... ---- -<1> Adds a pod affinity. -<2> Configures the `requiredDuringSchedulingIgnoredDuringExecution` parameter. -<3> Specifies the `key` and `values` that must be met. If you want the new pod to be scheduled on the node you edited, use the same `key` and `values` parameters as the label in the node. -<4> Specifies an `operator`. The operator can be `In`, `NotIn`, `Exists`, or `DoesNotExist`. For example, use the operator `In` to require the label to be in the node. +where: + +`spec.affinity.nodeAffinity`:: Specifies the stanza to configure node affinity. +`spec.affinity.nodeAffinity.requiredDuringSchedulingIgnoredDuringExecution`:: Specifies a _required_ rule. Configure the following `nodeSelectorTerms.matchExpressions` parameters: ++ +-- +`key`:: Specifies the key of the key/value pair (label) that must be matched to apply the rule. +`operator`:: Specifies the relationship between the label on the node and the set of values in the `matchExpression` parameters in the `Pod` spec. This value can be `In`, `NotIn`, `Exists`, or `DoesNotExist`, `Lt`, or `Gt`. There is no explicit _node anti-affinity_ concept, but using the `NotIn` or `DoesNotExist` operator replicates that behavior. +`values`:: Specifies the value of the key/value pair (label) that must be matched to apply the rule. +-- .. Create the pod: + diff --git a/modules/nodes-scheduler-node-affinity-example.adoc b/modules/nodes-scheduler-node-affinity-example.adoc index 62933e0db22f..1c93d46c8365 100644 --- a/modules/nodes-scheduler-node-affinity-example.adoc +++ b/modules/nodes-scheduler-node-affinity-example.adoc @@ -6,7 +6,10 @@ [id="nodes-scheduler-node-affinity-example_{context}"] = Sample node affinity rules -The following examples demonstrate node affinity. +[role="_abstract"] +To use node affinity, the pod spec that you want to schedule on a node must have a node selector that matches a label on the node. + +The following examples demonstrate node affinity with or without matching labels. [id="admin-guide-sched-affinity-examples1_{context}"] == Node affinity with matching labels diff --git a/modules/nodes-scheduler-pod-affinity-about.adoc b/modules/nodes-scheduler-pod-affinity-about.adoc index 750370e349fe..96d6c9ff72f5 100644 --- a/modules/nodes-scheduler-pod-affinity-about.adoc +++ b/modules/nodes-scheduler-pod-affinity-about.adoc @@ -6,7 +6,8 @@ [id="nodes-scheduler-pod-affinity-about_{context}"] = Understanding pod affinity -_Pod affinity_ and _pod anti-affinity_ allow you to constrain which nodes your pod is eligible to be scheduled on based on the key/value labels on other pods. +[role="_abstract"] +You can use _pod affinity_ and _pod anti-affinity_ to constrain which nodes your pod is eligible to be scheduled on based on the key/value labels on other pods. * Pod affinity can tell the scheduler to locate a new pod on the same node as other pods if the label selector on the new pod matches the label on the current pod. * Pod anti-affinity can prevent the scheduler from locating a new pod on the same node as pods with the same labels if the label selector on the new pod matches the label on the current pod. @@ -49,14 +50,14 @@ spec: seccompProfile: type: RuntimeDefault affinity: - podAffinity: <1> - requiredDuringSchedulingIgnoredDuringExecution: <2> + podAffinity: + requiredDuringSchedulingIgnoredDuringExecution: - labelSelector: matchExpressions: - - key: security <3> - operator: In <4> + - key: security + operator: In values: - - S1 <3> + - S1 topologyKey: topology.kubernetes.io/zone containers: - name: with-pod-affinity @@ -66,11 +67,16 @@ spec: capabilities: drop: [ALL] ---- +where: -<1> Stanza to configure pod affinity. -<2> Defines a required rule. -<3> The key and value (label) that must be matched to apply the rule. -<4> The operator represents the relationship between the label on the existing pod and the set of values in the `matchExpression` parameters in the specification for the new pod. Can be `In`, `NotIn`, `Exists`, or `DoesNotExist`. +`spec.affinity.podAffinity`:: Specifies a stanza to configure pod affinity. +`spec.affinity.podAffinity.requiredDuringSchedulingIgnoredDuringExecution`:: Specifies the parameters for a _required_ rule. Configure the following `labelSelector.matchExpressions.key` parameters: ++ +-- +`key`:: Specifies the key of the key/value pair (label) that must be matched to apply the rule. +`values`:: Specifies the value of the key/value pair (label) that must be matched to apply the rule. +`operator`:: Specifies the relationship between the label on the existing pod and the set of values in the `matchExpression` parameters in the specification for the new pod. Can be `In`, `NotIn`, `Exists`, or `DoesNotExist`. +-- .Sample `Pod` config file with pod anti-affinity [source,yaml] @@ -85,14 +91,14 @@ spec: seccompProfile: type: RuntimeDefault affinity: - podAntiAffinity: <1> - preferredDuringSchedulingIgnoredDuringExecution: <2> - - weight: 100 <3> + podAntiAffinity: + preferredDuringSchedulingIgnoredDuringExecution: + - weight: 100 podAffinityTerm: labelSelector: matchExpressions: - - key: security <4> - operator: In <5> + - key: security + operator: In values: - S2 topologyKey: kubernetes.io/hostname @@ -104,12 +110,17 @@ spec: capabilities: drop: [ALL] ---- - -<1> Stanza to configure pod anti-affinity. -<2> Defines a preferred rule. -<3> Specifies a weight for a preferred rule. The node with the highest weight is preferred. -<4> Description of the pod label that determines when the anti-affinity rule applies. Specify a key and value for the label. -<5> The operator represents the relationship between the label on the existing pod and the set of values in the `matchExpression` parameters in the specification for the new pod. Can be `In`, `NotIn`, `Exists`, or `DoesNotExist`. +where: + +`spec.affinity.podAffinity`:: Specifies a stanza to configure pod affinity. +`spec.affinity.podAffinity.preferredDuringSchedulingIgnoredDuringExecution`:: Specifies the parameters for a _preferred_ rule. Configure a weight and the following `podAffinityTerm.labelSelector.matchExpressions` parameters: ++ +-- +`weight`:: Specifies the weight for a preferred rule. The node with the highest weight is preferred. +`key`:: Specifies the key of the key/value pair (label) that must be matched to apply the rule. +`values`:: Specifies the value of the key/value pair (label) that must be matched to apply the rule. +`operator`:: Specifies the relationship between the label on the existing pod and the set of values in the `matchExpression` parameters in the specification for the new pod. Can be `In`, `NotIn`, `Exists`, or `DoesNotExist`. +-- [NOTE] ==== diff --git a/modules/nodes-scheduler-pod-affinity-configuring.adoc b/modules/nodes-scheduler-pod-affinity-configuring.adoc index c849cabb161a..b72ce409bf5f 100644 --- a/modules/nodes-scheduler-pod-affinity-configuring.adoc +++ b/modules/nodes-scheduler-pod-affinity-configuring.adoc @@ -6,7 +6,8 @@ [id="nodes-scheduler-pod-affinity-configuring_{context}"] = Configuring a pod affinity rule -The following steps demonstrate a simple two-pod configuration that creates pod with a label and a pod that uses affinity to allow scheduling with that pod. +[role="_abstract"] +You can use the following example pod specifications to create a pod with a label and a pod that uses affinity to allow scheduling with that pod. [NOTE] ==== @@ -60,25 +61,30 @@ metadata: name: security-s1-east # ... spec: - affinity: <1> + affinity: podAffinity: - requiredDuringSchedulingIgnoredDuringExecution: <2> + requiredDuringSchedulingIgnoredDuringExecution: - labelSelector: matchExpressions: - - key: security <3> + - key: security values: - S1 - operator: In <4> - topologyKey: topology.kubernetes.io/zone <5> + operator: In + topologyKey: topology.kubernetes.io/zone # ... ---- +where: + +`spec.affinity.podAffinity`:: Specifies a stanza to configure pod affinity. +`spec.affinity.podAffinity.requiredDuringSchedulingIgnoredDuringExecution`:: Specifies the parameters for a _required_ rule. Alternatively, you can configure a _preferred_ rule by using the `preferredDuringSchedulingIgnoredDuringExecution` paarmeter. ++ +Configure the following `labelSelector.matchExpressions` parameters. If you want the new pod to be scheduled with the other pod, use the same `key` and `values` parameters as the label on the first pod. + -- -<1> Adds a pod affinity. -<2> Configures the `requiredDuringSchedulingIgnoredDuringExecution` parameter or the `preferredDuringSchedulingIgnoredDuringExecution` parameter. -<3> Specifies the `key` and `values` that must be met. If you want the new pod to be scheduled with the other pod, use the same `key` and `values` parameters as the label on the first pod. -<4> Specifies an `operator`. The operator can be `In`, `NotIn`, `Exists`, or `DoesNotExist`. For example, use the operator `In` to require the label to be in the node. -<5> Specify a `topologyKey`, which is a prepopulated link:https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#interlude-built-in-node-labels[Kubernetes label] that the system uses to denote such a topology domain. +`key`:: Specifies the key of the key/value pair (label) that must be matched to apply the rule. +`value`:: Specifies the value of the key/value pair (label) that must be matched to apply the rule. +`operator`:: Specifies the relationship between the label on the existing pod and the set of values in the `matchExpression` parameters in the specification for the new pod. Can be `In`, `NotIn`, `Exists`, or `DoesNotExist`. +`topologyKey`:: Specifies a prepopulated Kubernetes label that the system uses to denote such a topology domain. -- .. Create the pod. diff --git a/modules/nodes-scheduler-pod-affinity-example.adoc b/modules/nodes-scheduler-pod-affinity-example.adoc index 4c680ad0a236..7c3fd01af98f 100644 --- a/modules/nodes-scheduler-pod-affinity-example.adoc +++ b/modules/nodes-scheduler-pod-affinity-example.adoc @@ -6,7 +6,8 @@ [id="nodes-scheduler-pod-affinity-example_{context}"] = Sample pod affinity and anti-affinity rules -The following examples demonstrate pod affinity and pod anti-affinity. +[role="_abstract"] +Use these configuration examples to understand how matching labels, non-matching labels, and specific label selectors affect how the cluster schedules pods onto nodes. [id="nodes-scheduler-pod-affinity-example-affinity_{context}"] == Pod Affinity diff --git a/modules/nodes-scheduler-pod-anti-affinity-configuring.adoc b/modules/nodes-scheduler-pod-anti-affinity-configuring.adoc index 8adc6c923a42..f78ba6660844 100644 --- a/modules/nodes-scheduler-pod-anti-affinity-configuring.adoc +++ b/modules/nodes-scheduler-pod-anti-affinity-configuring.adoc @@ -6,6 +6,9 @@ [id="nodes-scheduler-pod-anti-affinity-configuring_{context}"] = Configuring a pod anti-affinity rule +[role="_abstract"] +To specify a preference to prevent a pod from being scheduling with another pod, you can create a pod with a label and a pod that uses an anti-affinity preferred rule. + The following steps demonstrate a simple two-pod configuration that creates pod with a label and a pod that uses an anti-affinity preferred rule to attempt to prevent scheduling with that pod. [NOTE] @@ -61,26 +64,34 @@ metadata: # ... spec: # ... - affinity: <1> + affinity: podAntiAffinity: - preferredDuringSchedulingIgnoredDuringExecution: <2> - - weight: 100 <3> + preferredDuringSchedulingIgnoredDuringExecution: + - weight: 100 podAffinityTerm: labelSelector: matchExpressions: - - key: security <4> + - key: security values: - S1 - operator: In <5> - topologyKey: kubernetes.io/hostname <6> + operator: In + topologyKey: kubernetes.io/hostname # ... ---- -<1> Adds a pod anti-affinity. -<2> Configures the `requiredDuringSchedulingIgnoredDuringExecution` parameter or the `preferredDuringSchedulingIgnoredDuringExecution` parameter. -<3> For a preferred rule, specifies a weight for the node, 1-100. The node that with highest weight is preferred. -<4> Specifies the `key` and `values` that must be met. If you want the new pod to not be scheduled with the other pod, use the same `key` and `values` parameters as the label on the first pod. -<5> Specifies an `operator`. The operator can be `In`, `NotIn`, `Exists`, or `DoesNotExist`. For example, use the operator `In` to require the label to be in the node. -<6> Specifies a `topologyKey`, which is a prepopulated link:https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#interlude-built-in-node-labels[Kubernetes label] that the system uses to denote such a topology domain. +where: + +`spec.affinity.podAffinity`:: Specifies a stanza to configure pod affinity. +`spec.affinity.podAffinity.preferredDuringSchedulingIgnoredDuringExecution`:: Specifies the parameters for a _preferred_ rule. Alternatively, you can configure a _required_ rule by using the `requiredDuringSchedulingIgnoredDuringExecution` parameter. ++ +Configure a weight and the following `podAffinityTerm.labelSelector.matchExpressions` parameters. If you want the new pod to be scheduled with the other pod, use the same `key` and `values` parameters as the label on the first pod. ++ +-- +`weight`:: For a preferred rule, specifies a weight for the node, as a number 1-100. The node with highest weight is preferred. +`key`:: Specifies the key of the key/value pair (label) that must be matched to apply the rule. +`value`:: Specifies the value of the key/value pair (label) that must be matched to apply the rule. +`operator`:: Specifies the relationship between the label on the existing pod and the set of values in the `matchExpression` parameters in the specification for the new pod. Can be `In`, `NotIn`, `Exists`, or `DoesNotExist`. +`topologyKey`:: Specifies a prepopulated Kubernetes label that the system uses to denote such a topology domain. +-- .. Create the pod. + diff --git a/modules/nodes-scheduler-profiles-about.adoc b/modules/nodes-scheduler-profiles-about.adoc index dc8b2887fedc..b582654e0bba 100644 --- a/modules/nodes-scheduler-profiles-about.adoc +++ b/modules/nodes-scheduler-profiles-about.adoc @@ -6,7 +6,8 @@ [id="nodes-scheduler-profiles-about_{context}"] = About scheduler profiles -You can specify a scheduler profile to control how pods are scheduled onto nodes. +[role="_abstract"] +You can use scheduler profiles to determine how the cluster distributes pods across nodes based on node resource utilization. The following scheduler profiles are available: diff --git a/modules/nodes-scheduler-profiles-configuring.adoc b/modules/nodes-scheduler-profiles-configuring.adoc index c55f7d3e5b56..e205001f86e1 100644 --- a/modules/nodes-scheduler-profiles-configuring.adoc +++ b/modules/nodes-scheduler-profiles-configuring.adoc @@ -6,7 +6,8 @@ [id="nodes-scheduler-profiles-configuring_{context}"] = Configuring a scheduler profile -You can configure the scheduler to use a scheduler profile. +[role="_abstract"] +To customize how the cluster distributes pods across your nodes based on resource use, you can configure a specific scheduler profile. .Prerequisites @@ -32,9 +33,10 @@ metadata: #... spec: mastersSchedulable: false - profile: HighNodeUtilization <1> + profile: HighNodeUtilization #... ---- -<1> Set to `LowNodeUtilization`, `HighNodeUtilization`, or `NoScoring`. ++ +Set `spec.profile` to `LowNodeUtilization`, `HighNodeUtilization`, or `NoScoring`. . Save the file to apply the changes. diff --git a/modules/olm-overriding-operator-pod-affinity.adoc b/modules/olm-overriding-operator-pod-affinity.adoc index 5e19aca55b56..615c8427f425 100644 --- a/modules/olm-overriding-operator-pod-affinity.adoc +++ b/modules/olm-overriding-operator-pod-affinity.adoc @@ -32,9 +32,10 @@ ifdef::node[] endif::node[] -By default, when you install an Operator, {product-title} installs the Operator pod to one of your worker nodes randomly. However, there might be situations where you want that pod scheduled on a specific node or set of nodes. +[role="_abstract"] +You can use affinities to schedule an Operator pod on a specific node or set of nodes. -The following examples describe situations where you might want to schedule an Operator pod to a specific node or set of nodes: +By default, when you install an Operator, {product-title} installs the Operator pod on one of your compute nodes randomly. However, the following examples describe situations where you might want to schedule an Operator pod to a specific node or set of nodes: ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] * If an Operator requires a particular platform, such as `amd64` or `arm64` @@ -63,7 +64,7 @@ The following examples show how to use node affinity to install an instance of t endif::node[] ifndef::pod[] -.Node affinity example that places the Operator pod on a specific node +The following node affinity example places the Operator pod on a specific node: [source,yaml] ---- apiVersion: operators.coreos.com/v1alpha1 @@ -77,7 +78,7 @@ spec: sourceNamespace: operator-registries config: affinity: - nodeAffinity: <1> + nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: @@ -87,9 +88,10 @@ spec: - ip-10-0-163-94.us-west-2.compute.internal #... ---- -<1> A node affinity that requires the Operator's pod to be scheduled on a node named `ip-10-0-163-94.us-west-2.compute.internal`. -.Node affinity example that places the Operator pod on a node with a specific platform +This node affinity requires the Operator's pod be scheduled on a node named `ip-10-0-163-94.us-west-2.compute.internal`. + +The following node affinity example places the Operator pod on a node with a specific platform: [source,yaml] ---- apiVersion: operators.coreos.com/v1alpha1 @@ -103,7 +105,7 @@ spec: sourceNamespace: operator-registries config: affinity: - nodeAffinity: <1> + nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: @@ -117,7 +119,8 @@ spec: - linux #... ---- -<1> A node affinity that requires the Operator's pod to be scheduled on a node with the `kubernetes.io/arch=arm64` and `kubernetes.io/os=linux` labels. + +This node affinity requires the Operator's pod be scheduled on a node with the `kubernetes.io/arch=arm64` and `kubernetes.io/os=linux` labels. endif::pod[] ifdef::pod[] @@ -125,7 +128,7 @@ The following example shows how to use pod anti-affinity to prevent the installa endif::pod[] ifndef::node[] -.Pod affinity example that places the Operator pod on one or more specific nodes +The following pod affinity example places the Operator pod on one or more specific nodes: [source,yaml] ---- apiVersion: operators.coreos.com/v1alpha1 @@ -139,7 +142,7 @@ spec: sourceNamespace: operator-registries config: affinity: - podAffinity: <1> + podAffinity: requiredDuringSchedulingIgnoredDuringExecution: - labelSelector: matchExpressions: @@ -150,9 +153,10 @@ spec: topologyKey: kubernetes.io/hostname #... ---- -<1> A pod affinity that places the Operator's pod on a node that has pods with the `app=test` label. -.Pod anti-affinity example that prevents the Operator pod from one or more specific nodes +This pod affinity places the Operator's pod on a node that has pods with the `app=test` label. + +The following pod anti-affinity example prevents the Operator pod from one or more specific nodes: [source,yaml] ---- apiVersion: operators.coreos.com/v1alpha1 @@ -166,7 +170,7 @@ spec: sourceNamespace: operator-registries config: affinity: - podAntiAffinity: <1> + podAntiAffinity: requiredDuringSchedulingIgnoredDuringExecution: - labelSelector: matchExpressions: @@ -177,21 +181,22 @@ spec: topologyKey: kubernetes.io/hostname #... ---- -<1> A pod anti-affinity that prevents the Operator's pod from being scheduled on a node that has pods with the `cpu=high` label. + +This pod anti-affinity prevents the Operator's pod from being scheduled on a node that has pods with the `cpu=high` label. endif::node[] -.Procedure +To control the placement of an Operator pod, complete the following steps. -To control the placement of an Operator pod, complete the following steps: +.Procedure . Install the Operator as usual. . If needed, ensure that your nodes are labeled to properly respond to the affinity. . Edit the Operator `Subscription` object to add an affinity: -+ ifndef::pod[] ifdef::oplm[] ++ [source,yaml] ---- apiVersion: operators.coreos.com/v1alpha1 @@ -204,7 +209,7 @@ spec: source: my-operators sourceNamespace: operator-registries config: - affinity: <1> + affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: @@ -215,10 +220,13 @@ spec: - ip-10-0-185-229.ec2.internal #... ---- -<1> Add a `nodeAffinity`, `podAffinity`, or `podAntiAffinity`. See the Additional resources section that follows for information about creating the affinity. +where: + +`spec.config.affinity`:: Specifies a `nodeAffinity`, `podAffinity`, or `podAntiAffinity`. See the Additional resources section that follows for information about creating the affinity. endif::oplm[] ifdef::node[] ++ [source,yaml] ---- apiVersion: operators.coreos.com/v1alpha1 @@ -231,7 +239,7 @@ spec: source: my-operators sourceNamespace: operator-registries config: - affinity: <1> + affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: @@ -242,12 +250,14 @@ spec: - ip-10-0-185-229.ec2.internal #... ---- -<1> Add a `nodeAffinity`. -endif::node[] +where: +`spec.config.affinity`:: Specifies a `nodeAffinity`. +endif::node[] endif::pod[] ifdef::pod[] ++ [source,yaml] ---- apiVersion: operators.coreos.com/v1alpha1 @@ -261,7 +271,7 @@ spec: sourceNamespace: operator-registries config: affinity: - podAntiAffinity: <1> + podAntiAffinity: requiredDuringSchedulingIgnoredDuringExecution: podAffinityTerm: labelSelector: @@ -273,7 +283,9 @@ spec: topologyKey: topology.kubernetes.io/zone #... ---- -<1> Add a `podAffinity` or `podAntiAffinity`. +where: + +`spec.config.affinity`:: Specifies a `podAffinity` or `podAntiAffinity`. endif::pod[] .Verification @@ -286,7 +298,6 @@ $ oc get pods -o wide ---- + .Example output -+ [source,terminal] ---- NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES diff --git a/nodes/scheduling/nodes-scheduler-node-affinity.adoc b/nodes/scheduling/nodes-scheduler-node-affinity.adoc index ceecdb3bfb0e..a92e80b68d18 100644 --- a/nodes/scheduling/nodes-scheduler-node-affinity.adoc +++ b/nodes/scheduling/nodes-scheduler-node-affinity.adoc @@ -7,8 +7,8 @@ include::_attributes/common-attributes.adoc[] toc::[] - -Affinity is a property of pods that controls the nodes on which they prefer to be scheduled. +[role="_abstract"] +You can use a node affinity to control which nodes your pod can be scheduled on based on node labels. Node affinity helps you ensure your applications run on nodes with specific capabilities or configurations. In {product-title} node affinity is a set of rules used by the scheduler to determine where a pod can be placed. The rules are defined using custom labels on the nodes and label selectors specified in pods. diff --git a/nodes/scheduling/nodes-scheduler-pod-affinity.adoc b/nodes/scheduling/nodes-scheduler-pod-affinity.adoc index ee8e06fd7aea..aefc79941a25 100644 --- a/nodes/scheduling/nodes-scheduler-pod-affinity.adoc +++ b/nodes/scheduling/nodes-scheduler-pod-affinity.adoc @@ -6,6 +6,9 @@ include::_attributes/common-attributes.adoc[] toc::[] +[role="_abstract"] +To control workload distribution, you can use pod affinity and anti-affinity rules to specify whether pods must be scheduled close to or separate from other pods. + include::snippets/about-pod-affinity.adoc[] include::modules/nodes-scheduler-pod-affinity-about.adoc[leveloffset=+1] @@ -20,3 +23,9 @@ ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[] include::modules/olm-overriding-operator-pod-affinity.adoc[leveloffset=+1] endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[] + +[role="_additional-resources"] +[id="additional-resources_{context}"] +== Additional resources + +* link:https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#built-in-node-labels[Node label (Kubernetes documentation)] diff --git a/nodes/scheduling/nodes-scheduler-profiles.adoc b/nodes/scheduling/nodes-scheduler-profiles.adoc index abdc671e1cdd..5b82667749d3 100644 --- a/nodes/scheduling/nodes-scheduler-profiles.adoc +++ b/nodes/scheduling/nodes-scheduler-profiles.adoc @@ -6,7 +6,8 @@ include::_attributes/common-attributes.adoc[] toc::[] -You can configure {product-title} to use a scheduling profile to schedule pods onto nodes within the cluster. +[role="_abstract"] +You can use a scheduling profile to configure how the scheduler spreads pods across nodes to enforce low or high node utilization. // About scheduler profiles include::modules/nodes-scheduler-profiles-about.adoc[leveloffset=+1]