Assigning Pods to Nodes

In order to use VNGs effectively we will need to use Kubernetes constraints in order to constrain a Pod so that it can only run on a particular set of Nodes, there are several ways to do that using the label selectors mechanism.

Take note that there are Kubernetes built-in labels controlled Azure platform and you cannot use those labels on the VNG. You can review the list of unsupported labels in spot.io documentation

nodeSelectors

nodeSelector is a field of PodSpec. It specifies a map of key-value pairs. For the pod to be eligible to run on a node, the node must have each of the indicated key-value pairs as labels Discuss nodeLabels and taints/tolerations

The Node on which the Pod will be scheduled on can have multiple nodeLabels that are not specified on the Pod nodeSelector section.

Affinity/Anti-Affinity

The affinity/anti-affinity feature expands the types of constraints you can express. The key enhancements are (taken from the official Kubernetes documentation):

  • The affinity/anti-affinity language is more expressive. The language offers more matching rules besides exact matches created with a logical AND operation.
  • you can indicate that the rule is “soft”/“preference” rather than a hard requirement, so if the scheduler can’t satisfy it, the pod will still be scheduled;
  • you can constrain against labels on other pods running on the node (or other topological domain), rather than against labels on the node itself, which allows rules about which pods can and cannot be co-located
  • The affinity feature consists of two types of affinity, “node affinity” and “inter-pod affinity/anti-affinity”. Node affinity is like the existing nodeSelector (but with the first two benefits listed above), while inter-pod affinity/anti-affinity constraints against pod labels rather than node labels, as described in the third item listed above, in addition to having the first and second properties listed above.

Ocean will respect the required affinity/anti-affinity while making scaling decisions.

Taints/Tolerations

Taints allow a node to repel a set of pods. Tolerations are applied to pods, and allow (but do not require) the pods to schedule onto nodes with matching taints.

Taints and tolerations work together to ensure that pods are not scheduled onto inappropriate nodes. One or more taints are applied to a node; this marks that the node should not accept any pods that do not tolerate the taints.

Taints allow Pods who Tolerate them to be scheduled on the specific group of nodes, but it does not force that (e.g - you might also need to use nodeLabels in order to ensure the right behaviour).