Assign pod to nodes

Node Selector

nodeSelector is a selector which allows you to assign a pod to a specific node. It matches a node key/value pair, also known as a Label, which tells the Kubernetes scheduler which node to schedule the pod to.

If the label specified as nodeSelector doesn't exist on any node, then the pod will fail to be scheduled. If we still want to schedule our pod (even though the label doesn't exist on a node), we need to use Node/Pod affinity and Anti-affinity which is still in beta. We will cover and discuss this later in this scenario.

Note: By default, Kubernetes adds labels to nodes such as kubernetes.io/hostname, beta.kubernetes.io/arch and so on. For further information, read Built-in node labels in the Kubernetes documenation.

Schedule happypanda pod to node01 by using nodeSelector(disk=ssd)

Discover node labels

First of all, let's look at the current node labels:

kubectl get nodes --show-labels

Add a new node label

Now, add the label disk=ssd to node01:

kubectl label nodes node01 disk=ssd

Ensure the label we've just created has been added to node01:

kubectl get nodes --show-labels

Assign happypanda pod to node01, matching `disk:ssd` label

View the file pod-nodeselector.yaml:

cat /manifests/pod-nodeselector.yaml

Notice that nodeSelector is matching the label we just added to the node - disk:ssd. The Kubernetes scheduler will use this label to try and schedule pods onto a node with the label.

Create `happypanda` pod:

kubectl apply -f /manifests/pod-nodeselector.yaml

Check that `happypanda` has been successfully scheduled on node01:

kubectl get pods -o wide

Deleting happypanda pod and label

Delete happypanda pod:

kubectl delete -f /manifests/pod-nodeselector.yaml

or

kubectl delete pod happypanda

Remove label from node01:

kubectl label node node01 disk-

Node Affinity and Anti-Affinity

In the previous chapter, we introduced nodeSelector. This works well if your nodes have the required node labels, but if the nodeSelector doesn't match a label on a node, then the pod will not be scheduled. Node/Pod Affinity and Anti-Affinity resolves this issue by introducing soft and hard conditions.

type-affinity-anti-affinity

Note: As this is a beta feature, we won't be running any of them in this exercise, however it's important to understand the basic concepts. For more information, read the Kubernetes documentation on Affinity and Anti-Affinity.

Node Affinity

When you look at the Kubernetes API Reference, you'll notice that the two specs for Node Affinity are:

spec.affinity.nodeAffinity.preferredDuringSchedulingIgnoredDuringExecution - Soft NodeAffinity and Anti-Affinity: If the node label exists, the Pod will be ran there. If not, then the Pod will be rescheduled elsewhere within the cluster.
spec.affinity.nodeAffinity.requiredDuringSchedulingIgnoredDuringExecution - Hard NodeAffinity and Anti-Affinity: If the node label doesn't exist, then the pod won't be scheduled at all.

Soft Node Affinity

Let's inspect the node-soft-affinity.yaml manifest:

cat /manifests/node-soft-affinity.yaml

node-soft-affinity

The manfifest reads as: "If there are no nodes labelled as apple, then still schedule the pod to a node".

Hard Node Affinity

Now inspect the node-hard-affinity.yaml manifest:

cat /manifests/node-hard-affinity.yaml

node-hard-affinity

The manifest reads as: "If there are no nodes labelled as apple, then this pod won't be assigned a node by the scheduler".

Node Anti-Affinity

Node anti-affinity can be achieved by using the NotIn operator. This will help us to ignore nodes while scheduling.

Here is an example:

node-anti-affinity

Pod Affinity and Anti-Affinity

NodeAffinity allows you to schedule pods on specific nodes. But what if you want to run multiple pods on specific nodes? Pod affinity helps with that.

Note: As this is a beta feature, we won't be running any of them in this exercise, however it's important to understand the basic concepts. For more information, read the Kubernetes documentation on Affinity and Anti-Affinity.

Pod Affinity

When you look at the Kubernetes API Reference, you'll notice that the two specs for Pod Affinity are:

spec.affinity.podAffinity.preferredDuringSchedulingIgnoredDuringExecutionis for Soft Pod Affinity. If the preferred option is available, the Pod will run there. If not, the Pod can still be scheduled elsewhere.
spec.affinity.podAffinity.requiredDuringSchedulingIgnoredDuringExecution is for Hard Pod Affinity. If the required option is not available, the Pod cannot run.

Hard Pod Affinity

Let's inspect the pod-hard-affinity.yaml file:

cat /manifests/pod-hard-affinity.yaml

pod-hard-affinity

This is a hard pod affinity. If none of the nodes are labelled with fruit=apple, then the pod won't be scheduled.

The topologyKey is a label of a node, such as kubernetes.io/hostname (as seen in the picture).

Soft Pod Affinity

Soft Pod Affinity will schedule the Pod even though is not finding a pod running with label fruit=apple.

Pod Anti-Affinity

When you look at the Kubernetes API Reference, you'll notice that the two specs for Pod Anti-Affinity are:

spec.affinity.podAntiAffinity.preferredDuringSchedulingIgnoredDuringExecutionis for Soft Pod Anti-Affinity. If the preferred option is available, the Pod will run there. If not, the Pod can still be sheduled elsewhere.
spec.affinity.podAntiAffinity.requiredDuringSchedulingIgnoredDuringExecution is for Hard Pod Anti-Affinity. If the required option is not available, the Pod cannot run.

Pod anti-affinity works the opposite way of pod affinity. If one of the nodes has a pod running with label fruit=apple, the pod will be scheduled on different node.

Congratulations!

You've completed the scenario!

Scenario Rating

Steps