This is used to limit the overall set of Nodes that are considered eligible for scheduling, before the matchExpressions are evaluated. Pod affinities also offer a reduced set of comparison operators: you can use In, NotIn, Exists and DoesNotExist. For soft matches, this in turn should be located within a podAffinityTerm. Each matchExpressions constraint needs to be nested under a labelSelector. The format differs slightly from Node Affinity. RequiredDuringSchedulingIgnoredDuringExecution: These should be nested under the or fields depending on whether you want to increase or reduce the Pod’s affinity upon a successful match.

The “hard” and “soft” modes are indicated using the same requiredDuringSchedulingIgnoredDuringExecution and preferredDuringSchedulingIgnoredDuringExecution fields. Inter-Pod Affinities work very similarly to Node Affinities but do have some important differences. Each Node that matches a preference has its total affinity weight incremented by the set amount the Node that ends up with the highest overall weight will be allocated the Pod. Preference-based rules have an additional field called weight that accepts an integer from 1 to 100. PreferredDuringSchedulingIgnoredDuringExecution: A future Kubernetes release could add support for this behavior via the reserved requiredDuringSchedulingRequiredDuringExecution phrase. Changes to the Node won’t cause a Pod eviction due to changed affinity values. Once a Pod has made it onto a Node, affinity isn’t re-evaluated. The IgnoredDuringExecution part of these verbose names makes it explicit that affinity is only considered while scheduling Pods. preferredDuringSchedulingIgnoredDuringExecution – This is the “soft” matcher to express a preference that’s ignored when it can’t be fulfilled.requiredDuringSchedulingIgnoredDuringExecution – This is the “hard” affinity matcher that requires the Node meet the constraints you define.Node Affinity has two distinct sub-types: A Pod with the same condition but defined as an Inter-Pod Affinity will be scheduled to a Node that already hosts a Pod with a label=value label. In the simplest possible example, a Pod that includes a Node Affinity condition of label=value will only be scheduled to Nodes with a label=value label. Inter-Pod Affinity can be either an attracting affinity or a repelling anti-affinity. Inter-Pod Affinity – Used to constrain the Nodes that can receive a Pod by matching labels of the existing Pods already running on each of those Nodes.Node Affinity can only be used to set positive affinities that attract Pods to the Node. Node Affinity – Used to constrain the Nodes that can receive a Pod by matching labels of those Nodes.There are currently two different kinds of affinity that you can define: A Node that doesn’t meet the condition will still be selected if necessary. “Soft” affinities act as a preference, indicating to the scheduler that it should use a Node with the characteristics if one is available. A “hard” result means the Node must have the characteristics defined by the affinity expression. Affinity assessments can produce either hard or soft outcomes.

What is kubernetes pod