1

00:00:00,830 --> 00:00:06,320

Hello and welcome to this lecture, in this lecture, we look at demon sets in coronets.



2

00:00:07,610 --> 00:00:14,060

So far, we have deployed various parts on different nodes in our cluster with the help of replica sets



3

00:00:14,060 --> 00:00:21,230

and deployments, we made sure multiple copies of our applications are made available across various



4

00:00:21,230 --> 00:00:22,550

different worker nodes.



5

00:00:23,530 --> 00:00:30,730

Demon sets are like replica sets, as in it helps you deploy multiple instances of pot, but it runs



6

00:00:30,730 --> 00:00:34,830

one copy of your pod on each node in your cluster.



7

00:00:35,470 --> 00:00:42,910

Whenever a new node is added to the cluster, a replica of the pod is automatically added to that node.



8

00:00:43,180 --> 00:00:47,470

And when a node is removed, the pod is automatically removed.



9

00:00:48,160 --> 00:00:55,780

The demon said ensures that one copy of the pod is always present in all nodes in the cluster.



10

00:00:56,830 --> 00:01:03,040

So what are some use cases of demonises say you would like to deploy a monitoring agent or log collector



11

00:01:03,040 --> 00:01:07,360

on each of your nodes in the cluster so you can monitor your cluster better.



12

00:01:07,670 --> 00:01:14,650

A demon set is perfect for that, as it can deploy your monitoring agent in the form of a pod in all



13

00:01:14,650 --> 00:01:16,060

the nodes in your cluster.



14

00:01:17,190 --> 00:01:22,530

Then you don't have to worry about adding or removing monitoring agents from these nodes when there



15

00:01:22,530 --> 00:01:29,040

are changes in your cluster, as the demon said, will take care of that for you earlier while discussing



16

00:01:29,040 --> 00:01:30,300

the architecture.



17

00:01:30,600 --> 00:01:36,780

We learned that one of the worker node components that is required on every node in the cluster is a



18

00:01:36,780 --> 00:01:37,820

cube proxy.



19

00:01:38,640 --> 00:01:41,400

That is one good use case of demon sets.



20

00:01:41,430 --> 00:01:45,870

The cube proxy component can be deployed as a demon said in the cluster.



21

00:01:46,590 --> 00:01:48,750

Another use case is for networking.



22

00:01:49,140 --> 00:01:54,970

Networking solutions like Livnat requires an agent to be deployed on each node in the cluster.



23

00:01:55,710 --> 00:01:59,880

We will discuss about networking concepts in much more detail later during this course.



24

00:02:00,360 --> 00:02:02,780

But I just wanted to point it out here for now.



25

00:02:04,460 --> 00:02:08,300

Creating a demon set is similar to the replica set creation process.



26

00:02:08,780 --> 00:02:15,380

It has nested part specification under the template section and selectors to link the demon set to the



27

00:02:15,380 --> 00:02:15,860

parts.



28

00:02:16,590 --> 00:02:20,010

A demon set definition file has a similar structure.



29

00:02:20,690 --> 00:02:24,230

We start with the API version kind of metadata and spec.



30

00:02:24,680 --> 00:02:26,270

The API version is apps.



31

00:02:26,600 --> 00:02:28,760

We one kind is demon set.



32

00:02:28,910 --> 00:02:32,870

Instead of replica set, we will set the name to a monitoring demon.



33

00:02:33,200 --> 00:02:36,700

Under spec you have a selector and a part specification template.



34

00:02:37,160 --> 00:02:43,070

It's almost exactly like the classic definition, except that the kind is a demon set.



35

00:02:44,010 --> 00:02:50,310

Ensure the labels in The Selecter matches the ones in the pot template ones really create the demons



36

00:02:50,310 --> 00:02:53,610

that is in the control create demons, said Command.



37

00:02:54,620 --> 00:03:00,260

To view the creative demons that run to keep control, get demons that command and of course, to view



38

00:03:00,260 --> 00:03:04,490

more details on the keep control, describe demons that command.



39

00:03:07,770 --> 00:03:09,390

So how does it work?



40

00:03:09,950 --> 00:03:15,450

How does it schedule part on each node and how does it ensure that every node has a pod?



41

00:03:16,400 --> 00:03:20,720

If you were asked to schedule a part on each node in the cluster, how would you do it?



42

00:03:21,410 --> 00:03:27,440

In one of the previous lectures in this section, we discussed that we could set the node name properly



43

00:03:27,440 --> 00:03:32,730

on the pod to bypass the scheduler and get the part placed on a node directly.



44

00:03:33,230 --> 00:03:40,040

So that's one approach on each part, said the node name, property and its specification before it



45

00:03:40,040 --> 00:03:40,660

is created.



46

00:03:41,000 --> 00:03:45,260

And when they are created, they automatically land on the respective NOT.



47

00:03:46,360 --> 00:03:53,470

So that's how it used to be until Criminal's version 1.0 12 from version 1.0 12 onwards, the demon



48

00:03:53,470 --> 00:03:59,440

set uses the default scheduler and node affinity rules that we learned in one of the previous lectures



49

00:03:59,830 --> 00:04:01,810

to schedule part on not.



50

00:04:02,740 --> 00:04:07,960

Well, that's it for this lecture, head over to the practice test and practice working with demonises.