.In this lecture we will discuss about the part to note relationship and how you can restrict what parts
are placed on what notes the concept of teens and toleration can be a bit confusing for beginners.
So we will try to understand what they are using an analogy of a bug approaching a person.
Now my apologies in advance but this is the best I could come up with to prevent the bug from landing
on the person.
We spray the person with a repellent spray or attained as we will call it.
In this lecture the book is intolerant to the smell.
So on approaching the person detained applied on the person throws the bug off however there could be
other books that are tolerant to the smell and so the taint doesn't really affect them.
And so they end up landing on the person.
So there are two things that decide if a bug can land on a person.
First the taint on the person.
And second the bugs toleration level to that particular taint getting back to Cuba.
NET is the person is a node and the bugs are pods.
Now teens and toleration have nothing to do with security or intrusion on the Cluster.
Teens and toleration are used to set restrictions on what parts can be scheduled.
On a note let us start with a simple cluster with three worker notes the notes are named one two and
three.
We also have a set of paths that are to be deployed on these notes.
Let's call them A B C and D.
When the parts are created common it is scheduler tries to place these parts on the available worker
nodes.
As of now there are no restrictions are limitations and as such the scheduler places the parts across
all of the nodes to balance them out equally.
Now let us assume that we have dedicated resources on Node 1 for a particular use case or application
so we would like only those parts that belong to this application to be placed on Node 1.
First we prevent all parts from being placed on the Node by placing a taint on the Node.
Let's call it blue by default.
Paths have no toleration which means unless specified otherwise none of the parts can tolerate any taint.
So in this case none of the parts can be placed on Node 1 as none of them can tolerate the team.
Blue this solves half of our requirement no unwanted parts are going to be placed on this note.
The other half is to enable certain parts to be placed on this note.
For this we must specify which parts are tolerant to this particular attempt.
In our case we would like to allow only Part D to be placed on this note so we add a toleration to Part
D.
Part D is now tolerant to blue so when the scheduler tries to place this part on Node 1 it goes through
Node 1 can now only accept parts that can tolerate the taint.
Blue so with all the teens and toleration is in place.
This is how the parts would be scheduled.
The scheduler tries to place part a on not one but due to the team it is thrown off and it goes to note
to the scheduler then tries to place part B on not one but again due to the taint it is thrown off and
is placed on Node 3 which happens to be the next free node.
The scheduler then tries to place part c to the Node 1 it is thrown off again and ends up on Node 2.
Finally the scheduler tries to place part D on Node 1 since the part is tolerant to Node 1.
It goes through so remember trains are set on nodes and toleration are set on pods.
So how do you do this.
Use the cube control taint nodes command to taint in node specify the name of the node to train followed
by the train itself which is a key value pair.
For example if you would like to dedicate the Node 2 parts in application blue then the key value pair
would be ab equals blue the taint effect defines what would happen to the pods.
If they do not tolerate the taint there are three taint effects no schedule which means the parts will
not be scheduled on the node which is what we have been discussing.
Prefer No schedule which means the system will try to avoid placing a part on the node but that is not
guaranteed.
And third is no execute.
Which means that new parts will not be scheduled on the node and existing parts on the node if any will
be evicted if they do not tolerate the taint.
These parts may have been scheduled on Node before the 10th was applied to the node.
An example command would be detained Node node one with the key value pair app equals blue and an effect
of no schedule toleration is are added to parts to add a toleration to a pod.
First pull up the pod definition file in the spec section of the pod definition file had a section called
toleration move the same values used to while creating the taint under this section.
The key is app operator is equal value is blue and the effect is no should you.
And remember all of these values need to be encoded in double codes.
When the pods are now created or updated with the new toleration they are either not scheduled on nodes
or evicted from the existing nodes depending on the effect set let us try to understand the No.
Execute takes effect in a bit more depth.
In this example we have three nodes running some workload.
We do not have any teens or toleration at this point so they are scheduled this way.
We then decided to dedicate Node 1 for a special application and as such we obtained the node with the
application name and add a toleration to the part that belongs to the application which happens to be
part D.
In this case while tending the node we set the taint effect to no execute and as such.
Once detained on the Node takes effect it evokes Part C from the node which simply means that the part
is killed.
The Part D continues to run on the node as it has a toleration to the change.
Now going back to our original scenario where we have teens and toleration is configured.
Remember teens and toleration are only meant to restrict nodes from accepting certain parts.
In this case no one can only accept Part D but it does not guarantee that Part D will always be placed
on Node 1.
Since there are no teens or restrictions applied on the other two nodes Part D may very well be placed
on any of the other two nodes so remember teens and toleration does not tell the part to go to a particular
node.
Instead it tells the node to only accept parts with certain toleration.
If your requirement is to restrict a part to certain nodes it is achieved through another concept called
Ask node affinity which we will discuss in the next lecture finally.
While we're on this topic let us also take a look at an interesting fact.
So far we have only been referring to the worker nodes.
But we also have master nodes in the cluster which is technically just another note that has all the
capabilities of hosting a part.
Plus it runs all the management software.
Now I'm not sure if you noticed the scheduler does not schedule any part on the master node.
Why is that when the covenant is cluster is first setup.
It teams is set on the master node automatically that prevents any parts from being schedule on this
note.
You can see this as well as modified his behavior if required.
However a best practice is to not deploy application workloads on a master server to see this taint
run a cube.
Control described node command with Cube master as the node name and look for the tail section.
You will see a taint set to not schedule any parts on the master node.
Well that's it for this lecture.
Head over to the coding exercises section and practice working with teens and toleration is.