WEBVTT 00:00.910 --> 00:03.730 Hello and welcome to this lecture. In this lecture 00:03.730 --> 00:11.470 we look at daemon Sets in Kubernetes. So far we have deployed various pods on different nodes in our 00:11.470 --> 00:18.700 cluster. With the help of replica sets and deployments we made sure multiple copies of our applications 00:18.820 --> 00:26.540 applications are made available across various different worker nodes. Daemon set are like replica sets, as in it helps 00:26.540 --> 00:35.570 you deploy multiple instances of pod. But it runs one copy of your pod on each node in your cluster. 00:35.570 --> 00:42.920 Whenever a new node is added to the cluster a replica of the pod is automatically added to that node 00:43.310 --> 00:47.950 and when a node is removed the pod is automatically removed. 00:48.260 --> 00:56.820 The demon set ensures that one copy of the pod is always present in all nodes in the cluster. 00:56.880 --> 00:59.220 So what are some use cases of daemonsets? 00:59.340 --> 01:05.040 Say you would like to deploy a monitoring agent or log collector on each of your nodes in the cluster 01:05.340 --> 01:07.780 so you can monitor your cluster better. 01:07.890 --> 01:13.970 Demon set is perfect for that as it can deploy your monitoring agent in the form of a pod 01:14.130 --> 01:21.010 in all the nodes in your cluster. Then, you don’t have to worry about adding/removing monitoring agents 01:21.250 --> 01:24.370 from these nodes when there are changes in your cluster. 01:24.370 --> 01:28.300 as the daemon set will take care of that for you. 01:28.330 --> 01:33.460 While discussing the kubernetes architecture we learned that one of the worker node components that 01:33.460 --> 01:38.460 is required on every node in the cluster is a kube-proxy. 01:38.710 --> 01:45.370 That is one good use case of daemon Sets. The kubeproxy component can be deployed as a daemon set in the 01:45.370 --> 01:46.750 cluster. 01:46.750 --> 01:53.320 Another use case is for networking. Networking solutions like weave net requires an agent to be deployed 01:53.440 --> 01:55.720 on each node in the cluster. 01:55.780 --> 02:01.000 We will discuss about networking concepts in much more detail later during this course but I just wanted 02:01.000 --> 02:02.770 to point it out here for now. 02:04.520 --> 02:08.770 Creating a DaemonSet is similar to the ReplicaSet creation process. 02:08.870 --> 02:15.380 It has nested pod specification under the template section and selectors to link the daemon set to the 02:15.380 --> 02:20.710 PODs. A daemonSet definition file has a similar structure. 02:20.750 --> 02:23.050 We start with apiVersion, kind, 02:23.120 --> 02:30.450 metadata and spec. The api version is apps/v1. Kind is DaemonSet instead of ReplicaSet. 02:30.500 --> 02:36.230 We will set the name to monitoring daemon. Under spec you have a selector and a pod specification 02:36.230 --> 02:37.030 template. 02:37.250 --> 02:45.210 It's almost exactly like ReplicaSet definition except that the kind is a demon set. Ensure the labels 02:45.240 --> 02:51.240 in the selector matches the ones in the pod template. Once ready create the daemonset using the kubectl 02:51.240 --> 02:58.650 create daemonset command. To view the created daemonset run the kubectl get daemonset 02:58.650 --> 02:59.170 command. 02:59.340 --> 03:02.430 And of course to view more details run the kubectl 03:02.430 --> 03:07.780 describe demonSet command. 03:07.860 --> 03:09.950 So how does a demon set work. 03:09.990 --> 03:16.970 How does it schedule pods on each node? and How does it ensure that every node has a pod? if you were 03:17.000 --> 03:19.940 asked to schedule a pod on each node in the cluster. 03:19.940 --> 03:24.320 how would you do it? In one of the previous lectures in this section. 03:24.320 --> 03:30.680 we discussed that we could set the nodeName property on the pod to bypass the scheduler and get the 03:30.680 --> 03:38.300 pod placed on a node directly. So that’s one approach. On each pod, set the nodeName property in its 03:38.360 --> 03:44.870 specification before it is created and when they are created, they automatically land on the respective 03:44.870 --> 03:53.020 nodes. So that’s how it used to be until kubernetes version v1.12. From v1.12 onwards 03:53.060 --> 03:58.880 the Daemon set uses the default scheduler and node affinity rules that we learned in one of the previous 03:58.880 --> 04:02.760 lectures to schedule pods on nodes. 04:02.830 --> 04:04.150 Well that's it for this lecture. 04:04.150 --> 04:08.020 Head over to the practice test and practice working with DaemonSets.