Every node will have a copy of the pod. When nodes are added to the cluster, PODs are added to them and when nodes are removed from the cluster, the PODs are removed. If we delete a DaemonSet it will clean up the PODs it created.
So far we have deployed various PODs on different nodes in our cluster. With the help of replica sets and deployments we made sure multiple copies of our applications are made available across various different worker nodes.
Whenever a new node is added to the cluster a replica of the POD is automatically added to that node.
And when the node is removed from the cluster then the POD is automatically removed.
The daemon sets ensure that one copy of the POD always present in all nodes in the cluster.
Use cases of daemon sets
For example you would like to deploy a monitoring agent or log collector on each nodes in the cluster. So you can monitor your cluster better. Daemon set is perfect for that as it can deploy your monitoring agent in the form of a POD in all the nodes in the cluster.
Then, you don’t have to worry about adding/removing monitoring agents from these nodes when there are changes in your cluster. As the daemon set will take care of that for you.
apiVersion: apps/v1 kind: DaemonSet metadata: name: monitoring-daemon spec: template: metadata: labels: app: monitoring-agent spec: containers: - name: monitoring-agent image: monitoring-agent selector: matchLabels: app: monitoring-agent
Once ready, create the daemon set using the following command.
$ kubectl create -f daemon-set-definition.yaml
Now, to view the created daemon set run the following command.
$ kubectl get daemonsets
And of course to view more details run the following command.
$ kubectl describe daemonsets monitoring-daemon
How does it work?
So, how does a daemon set work? How does it schedule PODs on each node? and how does it ensure that every node has a POD?
Now, If you were asked to schedule a POD on each node in the cluster, how would you do it?
Firstly, On each POD set the nodeName property in its specification before it is created, they automatically land on the respective nodes.
So, that’s how it is used to be until Kubernetes version v1.12. From v1.12 on wards the daemon set used the default scheduler and node affinity rules that we discussed in