Hello and welcome to this lecture, in this lecture, we look at demon sets in coronets.
So far, we have deployed various parts on different nodes in our cluster with the help of replica sets
and deployments, we made sure multiple copies of our applications are made available across various
different worker nodes.
Demon sets are like replica sets, as in it helps you deploy multiple instances of pot, but it runs
one copy of your pod on each node in your cluster.
Whenever a new node is added to the cluster, a replica of the pod is automatically added to that node.
And when a node is removed, the pod is automatically removed.
The demon said ensures that one copy of the pod is always present in all nodes in the cluster.
So what are some use cases of demonises say you would like to deploy a monitoring agent or log collector
on each of your nodes in the cluster so you can monitor your cluster better.
A demon set is perfect for that, as it can deploy your monitoring agent in the form of a pod in all
the nodes in your cluster.
Then you don't have to worry about adding or removing monitoring agents from these nodes when there
are changes in your cluster, as the demon said, will take care of that for you earlier while discussing
the architecture.
We learned that one of the worker node components that is required on every node in the cluster is a
cube proxy.
That is one good use case of demon sets.
The cube proxy component can be deployed as a demon said in the cluster.
Another use case is for networking.
Networking solutions like Livnat requires an agent to be deployed on each node in the cluster.
We will discuss about networking concepts in much more detail later during this course.
But I just wanted to point it out here for now.
Creating a demon set is similar to the replica set creation process.
It has nested part specification under the template section and selectors to link the demon set to the
parts.
A demon set definition file has a similar structure.
We start with the API version kind of metadata and spec.
The API version is apps.
We one kind is demon set.
Instead of replica set, we will set the name to a monitoring demon.
Under spec you have a selector and a part specification template.
It's almost exactly like the classic definition, except that the kind is a demon set.
Ensure the labels in The Selecter matches the ones in the pot template ones really create the demons
that is in the control create demons, said Command.
To view the creative demons that run to keep control, get demons that command and of course, to view
more details on the keep control, describe demons that command.
So how does it work?
How does it schedule part on each node and how does it ensure that every node has a pod?
If you were asked to schedule a part on each node in the cluster, how would you do it?
In one of the previous lectures in this section, we discussed that we could set the node name properly
on the pod to bypass the scheduler and get the part placed on a node directly.
So that's one approach on each part, said the node name, property and its specification before it
is created.
And when they are created, they automatically land on the respective NOT.
So that's how it used to be until Criminal's version 1.0 12 from version 1.0 12 onwards, the demon
set uses the default scheduler and node affinity rules that we learned in one of the previous lectures
to schedule part on not.
Well, that's it for this lecture, head over to the practice test and practice working with demonises.