Discovering DaemonSets in Kubernetes

Objectives
After completing this lesson, you will be able to:

After completing this lesson, you will be able to:

  • Compare ReplicaSets and DaemonSets
  • Produce a DaemonSet manifest for a workload

DaemonSets in Kubernetes

Usage scenario

As a developer, you now have to run a workload on each node in your cluster explicitly. You have tried to use Deployments for this. A more experienced colleague has told you that you should use a DaemonSet instead. You want to know what a DaemonSet is and how it works.

What are DaemonSets in Kubernetes?

With ReplicaSets, you can specify how many replicas of a given pod should be running in your cluster. However, you cannot determine on which nodes the pods should be running. Kubernetes, as a container orchestrator, will decide on which nodes the pods should be scheduled based on the available resources on the nodes. But in some cases there must be only one copy of the pod running on a given set of nodes in your cluster.

A DaemonSet is a unique Kubernetes workload that ensures that a given pod runs on a subset of nodes in your Kubernetes cluster. Typically, DaemonSets are helpful for services such as logging agents, monitoring agents, or other services that need to run as a single copy on a subset of nodes in your cluster.

Workloads defined as DaemonSets are not scheduled by the default scheduler kube-scheduler. Instead, the DaemonSet controller creates a pod on each node by default. A subset of nodes can be selected by specifying a node selector. The DaemonSet controller will then create a pod on each node that matches the specified node selector.

The controller ensures that the pod is running on the node. If the node is deleted, the controller creates a new pod on the new node. Like the kube-scheduler, the DaemonSet controller also runs the reconciliation loop to ensure that the desired state is always met and reschedules the pod if necessary.

The DaemonSet Manifest

A simple DaemonSet manifest to declare a logging agent, such as fluentd, could look like this:

Code snippet
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: fluentd-daemon
spec:
  selector:
    matchLabels:
      app: fluentd-daemon
template:
   metadata:
     labels:
       app: fluentd-daemon
   spec:
      containers:
      - name: fluentd-daemon
        image: fluent/fluentd
...
Copy code

There is now an explicit node selector specified in this example. As a result, the DaemonSet controller will schedule a pod on all worker nodes. By adding a node selector, you define a selector of labels assigned to the nodes. The DaemonSet controller will then create a pod on each node that labels match the specified selector.

Code snippet
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: fluentd-daemon
spec:
  selector:
    matchLabels:
      app: fluentd-daemon
  template:
    metadata:
      labels:
        app: fluentd-daemon
    spec:
      nodeSelector:
        run-fluentd: "true"
      containers:
      - name: fluentd-daemon
        image: fluent/fluentd
...
Copy code

Nodes labeled via kubectl label nodes <node-name> run-fluentd=true will then be selected by the node selector, and the DaemonSet controller will schedule a pod on each of these nodes.

To read more about DaemonSets, please refer to the official Kubernetes documentation.

Summary

In this lesson, you learned about the differences between ReplicaSets and DaemonSets. You also learned how to use DaemonSets in Kubernetes to ensure that a given pod runs on a subset of nodes in your cluster.

Further Reading About Explaining DaemonSets in Kubernetes

Read more about DaemonSets in Kubernetes here: DaemonSet.

Log in to track your progress & complete quizzes