mirror of
https://github.com/openshift/openshift-docs.git
synced 2026-02-05 12:46:18 +01:00
118 lines
4.5 KiB
Plaintext
118 lines
4.5 KiB
Plaintext
// Module included in the following assemblies:
|
|
//
|
|
// * nodes/nodes-scheduler-node-affinity.adoc
|
|
|
|
:_mod-docs-content-type: CONCEPT
|
|
[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.
|
|
|
|
There are two types of node affinity rules: _required_ and _preferred_.
|
|
|
|
Required rules *must* be met before a pod can be scheduled on a node. Preferred rules specify that, if the rule is met, the scheduler tries to enforce the rules, but does not guarantee enforcement.
|
|
|
|
[NOTE]
|
|
====
|
|
If labels on a node change at runtime that results in an node affinity rule on a pod no longer being met, the pod continues to run on the node.
|
|
====
|
|
|
|
You configure node affinity through the `Pod` spec file. You can specify a required rule, a preferred rule, or both. If you specify both, the node must first meet the required rule, then attempts to meet the preferred rule.
|
|
|
|
The following example is a `Pod` spec with a rule that requires the pod be placed on a node with a label whose key is `e2e-az-NorthSouth` and whose value is either `e2e-az-North` or `e2e-az-South`:
|
|
|
|
.Example pod configuration file with a node affinity required rule
|
|
[source,yaml]
|
|
----
|
|
apiVersion: v1
|
|
kind: Pod
|
|
metadata:
|
|
name: with-node-affinity
|
|
spec:
|
|
securityContext:
|
|
runAsNonRoot: true
|
|
seccompProfile:
|
|
type: RuntimeDefault
|
|
affinity:
|
|
nodeAffinity: <1>
|
|
requiredDuringSchedulingIgnoredDuringExecution: <2>
|
|
nodeSelectorTerms:
|
|
- matchExpressions:
|
|
- key: e2e-az-NorthSouth <3>
|
|
operator: In <4>
|
|
values:
|
|
- e2e-az-North <3>
|
|
- e2e-az-South <3>
|
|
containers:
|
|
- name: with-node-affinity
|
|
image: docker.io/ocpqe/hello-pod
|
|
securityContext:
|
|
allowPrivilegeEscalation: false
|
|
capabilities:
|
|
drop: [ALL]
|
|
# ...
|
|
----
|
|
|
|
<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`.
|
|
|
|
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:
|
|
|
|
.Example pod configuration file with a node affinity preferred rule
|
|
[source,yaml]
|
|
----
|
|
apiVersion: v1
|
|
kind: Pod
|
|
metadata:
|
|
name: with-node-affinity
|
|
spec:
|
|
securityContext:
|
|
runAsNonRoot: true
|
|
seccompProfile:
|
|
type: RuntimeDefault
|
|
affinity:
|
|
nodeAffinity: <1>
|
|
preferredDuringSchedulingIgnoredDuringExecution: <2>
|
|
- weight: 1 <3>
|
|
preference:
|
|
matchExpressions:
|
|
- key: e2e-az-EastWest <4>
|
|
operator: In <5>
|
|
values:
|
|
- e2e-az-East <4>
|
|
- e2e-az-West <4>
|
|
containers:
|
|
- name: with-node-affinity
|
|
image: docker.io/ocpqe/hello-pod
|
|
securityContext:
|
|
allowPrivilegeEscalation: false
|
|
capabilities:
|
|
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.
|
|
|
|
[NOTE]
|
|
====
|
|
If you are using node affinity and node selectors in the same pod configuration, note the following:
|
|
|
|
* If you configure both `nodeSelector` and `nodeAffinity`, both conditions must be satisfied for the pod to be scheduled onto a candidate node.
|
|
|
|
* If you specify multiple `nodeSelectorTerms` associated with `nodeAffinity` types, then the pod can be scheduled onto a node if one of the `nodeSelectorTerms` is satisfied.
|
|
|
|
* If you specify multiple `matchExpressions` associated with `nodeSelectorTerms`, then the pod can be scheduled onto a node only if all `matchExpressions` are satisfied.
|
|
====
|