Last updated：2021-09-29 22:05:17
Similar to the node selector policy, the node affinity policy allows you to specify the nodes onto which pods can be scheduled based on node labels.
- You can go to the Deployment, StatefulSet, or DaemonSet page as required.
The following table describes the detailed settings of a node affinity policy.
|Required||The rules that the target node must meet. This parameter corresponds to the requiredDuringSchedulingIgnoredDuringExecution parameter in Kubernetes. You can click Add Scheduling Rule in the Required section to add multiple required rules. Pods can be scheduled onto a node if the node meets one or more required rules.|
|Preferred||The rules that the target node is expected to meet. This parameter corresponds to the preferredDuringSchedulingIgnoredDuringExecution parameter in Kubernetes. Pods are preferentially scheduled onto a node that meets preferred rules. You can set weights in preferred rules. If multiple nodes meet the specified rules during scheduling, pods are preferentially scheduled onto the node with the highest weight. You can click Add Scheduling Rule in the Preferred section to add multiple preferred rules. Pods can be scheduled onto a node regardless of whether a preferred rule is met.|
Selectors correspond to the matchExpressions parameter in Kubernetes. You can click Add Selector to add multiple selectors. Pods can be scheduled onto a node only when the conditions of all selectors are met.
|In||Indicates that the label value is included in the value list.|
|NotIn||Indicates that the label value is not in the specified list.|
|Gt||Indicates that the label value is greater than the specified value.|
|Lt||Indicates that the label value is less than the specified value.|
|Exists||Indicates that the specified label exists.|
|DoesNotExist||Indicates that the specified label does not exist.|
Did you find the above information helpful?
Please give us your feedback.
Thank you for your feedback.