Discovering DaemonSets in Kubernetes

Objectives

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.

Diagram showing a DaemonSet in Kubernetes deploying a Pod on each of three nodes (Node 1, Node 2, Node 3). Each Pod contains two containers: a Log Collector and a Monitoring Agent.

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:

YAML
1234567891011121314151617
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 ...

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.

YAML
12345678910111213141516171819
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 ...

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