hello everyone welcome back to my channel my name is p and this is video number 12 in the cies CK 2024 in this video we'll be looking into cron jobs jobs and the important concept of demon set so we'll be covering all these although Crown job and jobs are not really important From cka perspective it's more on the ckad curriculum but we'll have a look at that we'll see some basics of it because I just wanted to cover uh some fundamentals of it so that's why I've included it but demon set is important from this exam perspective and from uh the kubernetes point of view as well so we'll be looking those as well and uh the likes Target for this video is 200 likes and comment Target is 120 comments in the next 24 hours I hope you guys can do it so yeah without any further Ado let's start the video okay so in the previous videos we have looked into Damon sets rep replica spots and how they are deployed in multiple nodes the way it works is uh we specify a field called replicas in the yaml file in the Manifest of that kubernetes object like in the deployment we specified replicas as three so that is the reason it actually created three different parts like engine X1 engine X2 and engine X3 three different parts on multiple nodes like irrespective of number of nodes that are there so so that's how it distributed it demon setes work similarly with a slight change instead of creating replicas on multiple nodes as we have specified what it will do it will create the replicas in all the nodes one replica each node that's how it does so let's say we have uh we have a demon set demon set called sample let's say we have a Damon set of a agent like a monitoring agent okay so what it will do it will create Three Bs because we have three nodes running so it will create here one pod second pod and third pod so it will create one pod in each of the nodes and as soon as we add a new node let's say over here in the cluster there is a new node added this is our newer node that we have just added it will detect that that there has been a new node created and it will create a new replica of the demon set it doesn't happen in case of deployments or replica sets or uh just the Standalone pods but it happens in case of demon set and as soon as we delete this node okay this demon set replica will also be deleted so there are certain use cases why we use demon set one is I've already mentioned uh monitoring agent the other is logging agent um we have some control plane components as well and some networking components such as Q proxy right Q proxy is deployed in the cluster as a demon set then we have certain networking Concepts such as um weet so this is uh cni plugin for networking uh we'll look that in detail when we look into the networking section of this course but uh so there is weet then we have there are some Alternatives of it we have plenel and if you are working with kubernetes so you might have heard Calico so these all are the uh networking cnis right and these all are deployed as a Damon set so I hope you would have Now understand the importance of demon set and why do we use it so it makes sure that the number of replicas is equal to number of nodes and each node has one running replica all the time right it works the same way if we delete one replica it will instantly recreate it because of the controller controller takes care of that and uh there are certain applications where we use it why do we need to use it in uh monitoring and logging agent because you know let's say uh monitoring agent is something that has to run all the time to gather all the metrics from the node and it has to run on each node right and the same way logging agent maybe it has to report certain logs or it has to stream certain logs application logs or node level logs to a third party system such as plunk or elk or something else then also it has to run all the time on all the nodes so that's one of the um requirements then we have q proxy which is a control plane component and it is responsible for Port Port networking which we have already seen and again it has to run on all the nodes to make that possible now uh let's go to our console and let's see how do we create it so I have actually okay let me delete this first okay so um the yaml is pretty much the same the specification is same as deployment let me create this again so uh we had a deploy yaml I'll take this one so the one that we've used in the deployment video we have seen it multiple times so I'm not going to create it from the scratch but I'm sure by this time you know how to create the yaml for a manifest and all the different fields right so I have taken the deployment EML that we have created earlier and I've pasted it over here so let's make few changes instead of deployment let's change it to replica set sorry should not be replica set it should be a Damon set right and uh the API version is same as deployment uh you can verify it with Cube CTL explain demon set and let's call it DS okay and over here you see there was a field called replicas because the difference between deployment replica sets and Demon set is that in in deployment sets we actually specify the number of replicas that we run and controller and scheduler schedule the pods based on the availability based on the resources available on the notes and few other constant resource and limits Tain and Toleration and other Concepts right but in demonst set it irrespective of the replicas that we want it creates one replica of that Damon set on each of the available nodes that's what it do right so we don't need this field in Demon set so I'm going to remove it now let's apply this ds. ML and it says it's created now we do Cube C get pods you will see only two pods running but now you would say you have just mentioned that it it should run on all the available nodes so we have three nodes running why it is running two parts this is for the reason that control plane node has something called as taint that means we can only schedule control plane components on control plane node and this is a workload this is a custom workload that we have just deployed from our side it is not part of control plane components so that node is not able to tolerate this that is why did not schedule it on we'll see that Concept in deep right and we'll practice it because this is an important concept TT and Toleration but over here because it did not schedule the port that is why I wanted to mention the reason why did not schedule the pod on that note again we can try deleting this one of the pods so Cube C delete pod okay it says it deleted and if we do get pods again now we see two pods are running again it recreated it the way deployments or replica sets work let's see the other component that I've mentioned Q proxy so get DS okay so we have this current only one but we have to check in all the name spaces because Cube proxy run on Cube system name space so for that we can do two things we can either do get DS hyph a capital A this will return turn the object from all the name spaces capital A for all the name spaces or we can specify Nam space as cube system if we know in which name space we are looking for certain object right because we know Q proxy reside in Cube system name space so we can specify that as well so now it says we have actually two uh demon sets running one is kind net which is uh created by kind for networking and then we have q proxy with three desired three ready and three available replicas we have three nodes and it deployed Cube proxy in all three nodes like how it's supposed to be now let's have a look at a single node cluster running as well let's see how many replicas of these demon sets are there so kind uh get clusters I guess that's the single node one so I'm going to use I'm going to switch to that by Cube CTL config use context and I'm going to name the context kind single node okay now I have switched to that and if we do Cube CTL get nodes there is only one node which is a control plane node and if we do CTL get demon set hyph all so we have again Cube proxy Cube net but you see because these both of these are demon sets one desired one current and one ready and if if we do get pods hyph all okay and you see uh one Q proxy pod and one kind net pod and that's it because this is running as a Damon set and we only have one available node that is why I deployed that on one single node right so this is the concept of demon set and how do we do it and let's switch back to um the other one the other cluster that we were working on so instead of this one I'm just going to say cluster cka cluster 3 okay and get notes um I'm back on this cluster okay so now if we do CU CTL get BS iph n Cube system and let's actually use a grap on Q proxy okay so we have these three Q proxy pod running oh no not Q proxy the one U that we have created so it should be available in the default Nam space this one so let's copy this and we can inspect that in same way that we do because it is underneath a pod so we can do a describe on it we can do a log on it we can even EXA into it so if we do uh Cube CTL describe B right um it shows the same type of events and then uh it is running on Port 80 it uses engine X image and it is part of a demon set that is why it is says controlled by Damon set this uh in case of replica or deployment it says controlled by deployment this right so yeah that's uh that's that's about the demon set um now let's have a look at cron we have two more um similar object types in kubernetes one is a crown job and another one is a job so before looking into Cron job uh we'll just have a Overlook of it so if we go to Crown job over here on the documentation you see Crown job is basically a type of job that we execute on a certain time at a certain day or after a certain interval and we specify that schedule with the help of this format now if you are not aware of how cron syntax work this is the cron syntax and it's uh mostly used in Unix based system so we set cron synex like this and it will make sure that a script or a command or a build is triggered at that particular schedule that we have specified so if you are new to this let's quickly see overview of how it works and few example then we'll come back to this so there are usually five fields in this synex represented default by five srick so the first one represents minutes and allowed values are 0 to 59 second one is R allowed values are 0 to 23 third one is day of month and allowed value is 1 to 31 the next one is month allowed value as you have guessed right 1 to 12 and then day of week this is from 0 to 6 and it starts with Sunday and ends on Saturday so let's see you want to trigger a build on every Saturday every Saturday the option that we have provided is a day of the week so we'll be updating this particular field over here day of the week and you see Saturday is 6 number six so this is what we'll use so over here in place of asri it will be six and rest of the places it will be asri so let's say you want to trigger your build on every Saturday but only at 11:00 p. m.
at a certain time so first you will use 6 for Saturday and then we have an hour of the day right 11:00 p. m. which is this one because this is represented in 24 hours format so we'll be using 23 over here as 11:00 p.
m. right and for rest of the places we'll use asri so now this build will run on every Saturday at 11:00 p. m.
at 2300 hours let's see one more example if we want to trigger the build on every Saturday at 11:45 p. m. so we have one more condition added which is minutes so for Saturday again 6 for 11 p.
m. it is r and for 45 minutes this should be the first one so Saturday 11:45 p. m.
and for rest it should be star I hope you have got it now and you could practice this more you could understand the crown syntax better I'll paste the link as well of the official Crown page and you could just have a glance at it there is one more thing that I want to discuss it with you before we move ahead so let's say if you want to trigger build at every 5 minutes so for that you have have to use hric divide by n to every nth interval of time what I mean by that is if you want to run your build at every 10 minutes then you would use star divide by 10 and for rest of the places as estri so for this example if we want to run it for every 5 minutes then it will be estri by five so this build will run at every 5 minutes with star and estri at the rest of the places I hope this would be clear now okay now that we know the about the cron syntax and now that we know that putting all the star here means it will run every single minute or we can do star/ one to run it every 1 minute and so on so we have seen enough examples I'm sure you can practice that and you would understand the syntax of Aon now so what it will do so if we uh use this manifest I'm not going to run it now because as I've said it's not really important from the exam perspective but I'm just providing you an overview so um if you use this yaml right what it will do first it will run every single minute and what it will do it will spin up a pod with uh the name hello and with busy box 1.
