DaemonSet in kubernetes

Reading Time: 4 minutes

A Kubernetes DaemonSet is a container tool that ensures that all nodes are running exactly one copy of a pod. DaemonSets will even create pods on new nodes that are added to your cluster! This essentially runs a copy of the desired pod across all nodes.

When a new node is add to a Kubernetes cluster, a new pod will be add to that newly attach node.
When a node is remove, the DaemonSet controller ensures that the pod associated with that node is garbage collect. Deleting a DaemonSet will clean up all the pods that DaemonSet has created.

DaemonSets use cases

It can improve the performance of a Kubernetes cluster by distributing maintenance tasks and support services via deploying Pods across all nodes. They are well suit for long-running services like monitoring or log collection.

Following are some example use cases of DaemonSets:

To run a daemon for logs collection on each node, such as Fluentd and logstash
To run a daemon for node monitoring on every note, such as Prometheus Node Exporter, collectd, or Datadog agent.

Depending on the requirement, you can set up multiple DaemonSets for a single type of daemon, with different flags, memory, CPU, etc. that supports multiple configurations and hardware types.

Scheduling DaemonSets pods

By default, the node that a pod runs on is decide by the Kubernetes scheduler. However, DaemonSet pods are create and scheduled by the DaemonSet controller. Using the DaemonSet controller can lead to Inconsistent Pod behavior and issues in Pod priority preemption.

To mitigate these issues, Kubernetes (ScheduleDaemonSetPods) allows users to schedule DaemonSets using the default scheduler instead of the DaemonSet controller. This is done by adding the NodeAffinity term to the DaemonSet pods instead of the .spec.nodeName term. The default scheduler is then use to bind the Pod to the target host.

The following is a sample NodeAffinity configuration:

Above, we configured NodeAffinity so that a pod will only be created on a node that has the “disktype=ssd” label.

How to create DaemonSets

Like everything else in Kubernetes, DaemonSets can be configure using a YAML file:

As you can notice in the above structure, the **apiVersion**, **kind,** and **metadata** are required fields in every Kubernetes manifest. The DaemonSet specific fields come under the spec section—these fields are both mandatory.

template. This is the pod definition for the Pod that needs to be deploy across all the nodes. A pod template in a DaemonSet must have its RestartPolicy set to “Always,” and by default it will take “Always” if you haven’t specified a RestartPolicy.
selector. The selector for the pods managed by the DaemonSet. This value must be a label specified in the pod template. (In the above example, we have used the name: my-daemonset-container as the selector.) This value is fix and cannot be change after the initial creation of the DaemonSet. Changing this value will cause pods create via that DaemonSet to be orphane. Kubernetes offers two ways to match matchLabels and matchExpressions for creating complex selectors.

Once you’ve got the configuration complete, create the DaemonSet in your cluster by doing the following:

Kubectl apply -f daemonset.yaml

You should see the specified pod running on each node!

Creating a DarmonSet

Now let’s go ahead with creating a sample DaemonSet. Here, we will be using a “fluentd-elasticsearch” image that will run on every node in a Kubernetes cluster. Each pod would then collect logs and send the data to ElasticSearch.

First, let’s create the DaemonSet using the kubectl create command and retrieve the DaemonSet and pod information as follows:

kubectl create -f daemonset-example.yaml

kubectl get daemonset

kubectl get pod -o wide

As you can see from the above output, our DaemonSet has been successfully deploy.

Depending on the nodes available on the cluster, it will scale automatically to match the number of nodes or a subset of nodes on the configuration. (Here, the number of nodes will be one as we are running this on a test environment with a single node Kubernetes cluster.)

Communicating with pods created by DaemonsSet

There are multiple methods to communicate with pods created by DaemonSets.

Push. This way, pods can be configured to send information to other services (monitoring service, stats database). However, they do not receive any data.

NodeIP & Known Port. Pods are reachable via the node IPs using hostPort. Users can then utilize the known ports and the node IP to communicate with the pods.

DNS. In this method, users can configure a headless service with the same pod selector to discover DaemonSet using the endpoints resource.

Service. To select a random node in a DaemonSet, which we can use to create a service with the same pod selector.

Conclusion

In this blog, we learned about Kubernetes DaemonSets. These configurations can easily facilitate monitoring, storage, or logging services that can be used to increase the performance and reliability of both the Kubernetes cluster and the containers. If you find this blog helpful do share this blog.

Thankyou for being with me till here!!!