Kubernetes DaemonSet: What It Is and 5 Ways to Use It
Tags: kubernetes, vcluster, devspace, loft
Published: 2022-09-28 14:15:19

By Mercy Kibet

Kubernetes DaemonSet is a powerful tool for managing persistent workloads on your system. It ensures that each instance of an application running on your system will always be running. When starting a Kubernetes cluster, you must configure the services or applications you want running in your cluster. 

In this post, we'll explain the problem it solves and five ways to use it. 

## What Is a DaemonSet in Kubernetes?

A DaemonSet ensures that a specified collection of pods runs on the specified nodes. DaemonSet makes sure one pod exists per node. 

Kubernetes DaemonSets can be used for various applications, including key-value stores, caches, and servers that require high availability, like messaging apps. A DaemonSet will allow you to specify how many instances your app should run in the cluster and guarantee a consistent state among all pods running in the cluster. 

Kubernetes DaemonSet can run Docker containers without managing the underlying infrastructure. You don't have to worry about scaling your clusters or where the container data is stored. 

![alt_text](https://loft.sh/blog/images/content/peapod.jpg "image_tooltip")

## What Is the Difference Between DaemonSet and Deployment?

DaemonSet manages the number of pod copies to run in a node. However, a deployment manages the number of pods and where they should be on nodes. Deployment selects nodes to place replicas using labels and other functions (e.g., tolerations). 

A DaemonSet doesn't need external resources like IP addresses or port numbers. However, you must provide them if you create a deployment. 

Additionally, a DaemonSet doesn't need to know the number of nodes in your [Kubernetes cluster.](https://loft.sh/blog/multi-cluster-kubernetes-part-one-defining-goals-and-responsibilities/) However, you must provide it if you create a deployment. 

Last, a DaemonSet doesn't need runtime state information, like the number of pods currently running on each node or the number of replicas running on each pod (although these things can still be specified). 

## Ways to Use a DaemonSet

1. **Running a backup job**—You can have a DaemonSet running on every node in your cluster responsible for running backups of your etcd, MySQL data files, and PostgreSQL data files. If one pod fails for any reason, the other backup pods in the set will take over.
2. **Logging**—Another use case is to install an agent such as Sysdig on each node and launch a DaemonSet to manage all of these agents in a cluster-ready state.
3. **Enforcing network policy**—If you have a multi-tenant cluster and wish to lock down each tenant to its range of IPs, you can create a DaemonSet for each tenant that ensures every node is running the pods for that tenant's range of IPs, which is defined as part of the pod spec.
4. **Docker registry**—Maintaining a highly available and scalable Docker registry in Kubernetes is an example of another use case for DaemonSet. Ensure your Docker registry always has two replicas running in a cluster-ready state.
5. **Log aggregation**—If you want to aggregate your container logs and ship them off to a centralized logging tool like Logz.io, you can create a DaemonSet that launches a tail-logs pod and replicates it many times as required.

## Creating a DaemonSet Is Simple With an Example of Nginx

First, we need to create a [Manifest file](https://en.wikipedia.org/wiki/Manifest_file) which will contain all of the necessary configuration information for our DaemonSet. 

```
apiVersion: extensions/v1beta1 
kind: DaemonSet 
metadata: 
  name: nginx-example 
spec: template: metadata : labels : app : nginx spec : nodeSelector : role : web containers : - name : nginx image : nginx ports : - containerPort : 80
```

Specifying the node selector allows you to control which nodes the pod will run on. You could spread your pods across multiple nodes for load balancing, high availability, and more. You can use the labels for pod selection and service discovery. 

In this example, we created a DaemonSet with all nodes in the cluster. 

From this example, we can use multiple containers in a DaemonSet. You could use CoreDNS (a DNS server) to spin up on every node in your cluster, or even an image library for processing images on every node for faster processing of your containers. 

The “spec” section tells Kubernetes what the pod is supposed to do; the “node selector” is how you choose which machines the pod is running on. 

![alt_text](https://loft.sh/blog/images/content/spec.png "image_tooltip")

## Creating and Managing Kubelet DaemonSet

If you add a node to your cluster, then you can create a new DaemonSet and add it to the node. If you want to ensure the required number of pods run on a subset of nodes, you can create multiple DaemonSets. Once created, they need to be managed by an operator. 

### Managing Sysdig Ops Agent with Kubernetes DaemonSet

Here, these steps explain how to use Kubernetes to manage your cluster's kubelet agent (Sysdig) and how it compares with creating a deployment. 

1. Create the DaemonSet object in Kubernetes. 

```
curl -s create-daemonset.sh -H "Content-Type: application/json" -d '{"kind":"DaemonSet", "apiVersion":"v1", "metadata": {"name": "sysdig"}}' | kubectl
 --kubeconfig=/etc/kubernetes/admin.kubeconfig apply -f-
```

2. The following is created in your Kubernetes cluster: 

```
$ kubectl --kubeconfig=/etc/kubernetes/admin.kubeconfig get svc/sysdig-k8s-agent

NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE

sysdig-k8s-agent ClusterIP 10.157.194.75 <none> 80:31185/TCP,443:31186/TCP 1m
```

3. Check the pod status to see how many pods are running in a cluster-ready state on your node. 

```
curl -s http://10.157.194.75:31186/api/v1/namespaces/system:pod/pods | jq '.status.containerStatus'

"active" "running" "stopped-for-preview"
```

4. Use the kubectl top command to list all DaemonSets you've created, then check the status of your DaemonSet in a cluster-ready state for a pod (Sysdig pod). 
5. Use the **kubectl delete** command to remove your DaemonSet after using it successfully. 
6. To view the pod status of your DaemonSet in a cluster-ready state, use the **kubectl get** command. 
7. To launch a DaemonSet, use the command below: 

kubectl create -f daemonset.yaml --namespace=system/daemonset 

![alt_text](https://loft.sh/blog/images/content/pepper.jpg "image_tooltip")

## How to Use a Kubernetes DaemonSet for Log Collection

DaemonSet is a collection of log files available to your application. You use it for collecting performance, usage, and error logs. 

DaemonSet contains a few components—a daemon, a set of clients (logs and other activity watchers), and a central log handler. It all comes together through the standard protocol described below, allowing seamless integration with your application's ongoing activity. 

DaemonSet collects logs, errors, and other system statistics and doesn't interfere with your application's behavior. 

The handler receives logs from clients and does the work of processing and sending them to the desired destination. You can have multiple handlers in a single DaemonSet. 

DaemonSet uses a flexible messaging format over TCP connection (by default, on port 9000) that allows for sending various messages to the handler(s). 

![alt_text](https://loft.sh/blog/images/content/daemonset.png "image_tooltip")

## Conclusion

Kubernetes DaemonSet is a great way to manage and deploy applications in a clustered environment. It's easy to use and has a wide range of features, making it an ideal choice for managing applications in a production environment. 

You can use DaemonSet to run a cluster storage, log collection, and node monitoring demon on each node. Now that you know how to spin up a DaemonSet, check out [Loft](https://loft.sh/), a platform that gives you autonomy to fully leverage DaemonSet's capabilities. 

*This post was written by Mercy Kibet. [Mercy](https://hashnode.com/@eiMJay) is a full-stack developer with a knack for learning and writing about new and intriguing tech stacks.*