Kubernetes : Scheduling ( Part 2)

In the previous article, we saw one of factors that the Scheduler considers to choose the appropriate node to deploy pods in kubernetes.

In this blog post, we’ll continue our journey with Scheduler and we will cover another two factors called node Selector and node affinity.

Scheduler & Node Selector

See that we have a Kubernetes Cluster with 3 nodes and 3 pods that needs to be deployed on those nodes.

One of those pods (Red Pod) contain a critical application that need to be deployed on a node configured with higher ressources, which his name is high :

In the default Scheduler’s configuration, any pods can be deployed on any nodes and this is not what we want. In this case the red pod may end up on node 2 or node 3. So we have to tell the scheduler to deploy the red pod on high.

Pod configuration :

To do that, we add the nodeSelector property to the spec section on the pod’s definition yaml file like this :

apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod
spec:
  containers:
  - name: nginx-container
    image: nginx:latest
    ports:
    - containerPort: 80
nodeSelector: 
  ressources: high

Once the prod is created, it is deployed on node 1 with the high ressources.

But how the Scheduler know there is a node named « high » ?

Well that’s because a label named « high » has been assigned to this node to be identified.

So to assign a label to a node, use the command bellow :

kubectl label nodes <node_name> key=value

In our case I use the command bellow :

kubectl label nodes node1 ressources=high

So first thing to do is to set a label to the node and then add the property nodeSelector in the pod definition file to select this node.

Now we are sur that our pod end up to the node with high ressources :

Now see that we have a cluster with 3 nodes with different ressources size like bellow :

We want to tell scheduler to deploy the pod B on node « high » or on node « medium ». Also do not deploy the pod C on low node.

We can’t use those expression with « nodeSelector« , it doesn’t understant that.

That’s why we need another factor that scheduler use called nodeaffinity.

Scheduler & node affinity

nodeaffinity preperty allow us to be more flexebilty on choosing the appropriate node.

For exemple we can tell Scheduler to deploy the pod on the node with high ressources or the one who has medium ressources. In this cas the Scheduler will try to run the pod on high node first. But if it cannot for some reason, the pod will be deployed on the medium node.

Another nodeaffinity’s use case, is to tell Scheduler do not run a pod on Low node, so the pod will bu run either on the high node or the medium node.

Here is a link to kubernetes documentation if you want to learn more about this topic.