Daemon Sets

In this article we will be taking a look at Daemon Sets in Kubernetes.

So far we have learned how to deploy various pods on different nodes in a cluster. With the help of replica sets and deployments we made sure multiple copies of our application are made available across various different worker nodes.

Daemon set are like replica sets, as in it helps you deploy multiple instances of pod. But it runs one copy of your pod on each node in your cluster.

Whenever a new node is added to the cluster a replica of the pod is automatically added to that node and when a node is removed the pod is automatically removed.

The demon set ensures that one copy of the pod is always present in all nodes in the cluster.

So what are some use cases of Daemon Sets?

Say you would like to deploy a monitoring agent or log collector on each of your nodes in the cluster so you can monitor your cluster better.

Demon Set is perfect for that, as it can deploy your monitoring agent in the form of a pod in all the nodes in your cluster. Then, you don’t have to worry about adding/removing monitoring agents from these nodes when there are changes in your cluster.

While discussing the kubernetes architecture we learned that one of the worker node components that is required on every node in the cluster is a kube-proxy.

That is one good use case of daemon Sets. The kubeproxy component can be deployed as a daemon set in the cluster.

Another use case is for networking. Networking solutions like weave-net requires an agent to be deployed on each node in the cluster.

We will expand on networking in much more detail later in another post but I just wanted to point it out for now.

Creating Daemon Sets

Creating a DaemonSet is similar to the ReplicaSet creation process.

replicaset-definition.yaml

apiVersion: apps/v1
kind: ReplicaSet
metadata:
    name: montoring-daemon
spec:
    selector:
        matchLabels:
            app: monitoring-daemon
    template:
        metadata:
            labels:
                app: monitoring-agent
        spec:
            containers:
            - name: monitoring-agent
              image: monitoring-agent

It has nested pod specification under the template section and selectors to link the daemon set to the PODs.

A daemonSet definition file has a similar structure:

daemon-set-definition.yaml

apiVersion: apps/v1
kind: DaemonSet
metadata:
    name: montoring-daemon
spec:
    selector:
        matchLabels:
            app: monitoring-daemon
    template:
        metadata:
            labels:
                app: monitoring-agent
        spec:
            containers:
            - name: monitoring-agent
              image: monitoring-agent

It's almost exactly like ReplicaSet definition except that the kind is a DaemonSet.Ensure the labels in the selector matches the ones in the pod template.

Create DaemonSet Using kubectl command

kubectl create -f daemon-set-definition.yaml

Get DaemonSet

kubectl get daemonsets

Describe a Daemon Set

kubectl describe daemonset monitoring-daemon

How does a Daemon Set Work?

• How does it schedule pods on each node?
• How does it ensure that every node has a pod?

If you were asked to schedule a pod on each node in the cluster how would you do it?

In one of the previous articles in this series. I discussed that we could set the nodeName property on the pod to bypass the scheduler and get the pod placed on a node directly. So that’s one approach. On each pod, set the nodeName property in its specification before it is created and when they are created, they automatically land on the respective nodes. That’s how it used to be until kubernetes version v1.12.

From v1.12 onwards the Daemon Set uses the default scheduler and node affinity rules that we learned in the previous posts to schedule pods on nodes.