RX-M instructor Iliyan Petkov explores the fundamentals of Kubernetes DaemonSets, their uses, and how to create them. Kubernetes DaemonSets are a type of controller that allows users to deploy a Kubernetes pod on every node in the cluster. DaemonSet pods are typically used for storage, networking, and observability agents and will scale with the cluster. Check out Iliyan’s demo for DaemonSet scaling behavior.
Video Transcript
Hello and welcome back to yet another RX-M Cloud Native Short Take! My name is Iliyan Petkov and today we’re going to talk about Kubernetes DaemonSets. We are going to discuss what DaemonSets are, what is their use case–their purpose in Kubernetes environments, and how we create and manage them.
Kubernetes DaemonSets are controllers similar to Deployments, StatefulSets or Jobs; their main goal is to manage and make sure that exactly one pod instance of a specific pod is running on every single cluster node. Every time we scale our cluster horizontally by adding an additional cluster node, the DaemonSet will create a new pod and the scheduler will start it on the new node added to the Kubernetes cluster. Similarly, when we scale down the cluster and we remove node(s) the pod running on that node will be garbage collected by the DaemonSet controller. All right, so for what purpose do we use the DaemonSet? Usually we need DaemonSets when we must make sure that exactly one single instance of a pod is running on every single node inside the cluster. Such cases are when we deploy networking or storage plugins, monitoring or security agents.
DaemonSets, as is the case with most Kubernetes resources, are created by specifying a yaml document. Let’s see how this is actually working in practice; for this we are going to create a small Kubernetes cluster ad hoc using Minikube that will consist of two nodes. We’ll be using the profile name demo. This is any arbitrary name that we can specify. And we are going to use the latest version of Kubernetes. For creation of the Kubernetes cluster we are going to use a container runtime in this case that will be Docker Desktop. Creation of the cluster will take a couple of seconds so we are going to fast forward.
All right, Minikube just created our Kubernetes cluster and configured our kubectl client. We can check that by using kubectl get nodes and as you see we have a small two node cluster consisting of a control plane node and worker node. Both of them are in the ready state. Next let’s apply the DaemonSet spec; in order to create it we use kubectl apply -f <filename>. All right, so our DaemonSet has been created and if we take a look inside the namespace kube-system where the DaemonSet has been created we’ll see that in the DaemonSet exists. It has two desired replicas; currently we have two; two of them are ready; both are up to date; both are available. We haven’t specified any node selector so that column shows none and the DaemonSet has been created 22 seconds ago.
A couple of seconds have passed; now let’s clear the screen and look at the pods that this DaemonSet manages. We are showing the pods using kubectl get pods in the kube-system namespace and we are selecting the pods by the label that has been assigned to them during creation. We are also using the -o wide flag, so that will also show us additional information about the nodes where the pods have been created. Currently we have two nodes in our cluster and we have two pods created by the DaemonSet–one every node.
Now imagine a situation where we want to horizontally scale our Kubernetes cluster because we need more compute resources or memory resources to deploy more workloads. This is easily achieved using Minikube by using minikube -p <profile of the Kubernetes cluster that we want to modify> and then node add. Let’s quickly verify–if we use kubectl get nodes we’ll see that now our Kubernetes cluster consists of actually one control plane node and two worker nodes. Let’s see what is happening now after this change with our pods managed by the DaemonSet. As we see we still have the original two pods created on the control plane node and the first worker node but now we also see that a new pod has been created on the newly added node to our Kubernetes cluster–that’s great!
Now let’s see what will happen if we scale down the cluster by removing one of the nodes. Again this operation will take a couple of seconds. Okay so it’s ready and if we get the pods managed by the DaemonSet we’ll see that the output shown will not be changed. It will take a couple of seconds for this information to be updated, so, fast forwarding a couple of seconds–all right! So as we see eventually the pod has been garbage collected by the DaemonSet and again we see only two pods, one for each of the nodes in our Kubernetes cluster.
Lastly, if we delete the DaemonSet every single pod that was managed by the DaemonSet will also be deleted. So let’s quickly take a look, and we see that there are no more pods left!
Kubernetes DaemonSets are just one of the things that we teach at RX-M in our classes. If you want to participate in any of them please visit us at our web page rx-m.com where you can find more than 200 classes that we offer in our course catalog covering various technology topics. You can also build a custom class using our Course Builder including any topics that you might be interested in.
I’ve been Iliyan Petkov from RX-M and this has been another RX-M Cloud Native Short Take. Thank you for watching and see you next time!