:_mod-docs-content-type: ASSEMBLY
:context: nodes-pods-daemonsets
[id="nodes-pods-daemonsets"]
= Running background tasks on nodes automatically with daemon sets
include::_attributes/common-attributes.adoc[]

toc::[]

[role="_abstract"]
Daemon sets ensure that pods run on all or specific nodes in a cluster, enabling cluster-wide services such as logging agents, monitoring tools, and shared storage that must be present on every node.

As an administrator, you can create and use daemon sets to run replicas of a pod on specific or all nodes in
ifndef::openshift-rosa,openshift-rosa-hcp[]
an {product-title} cluster.
endif::openshift-rosa,openshift-rosa-hcp[]
ifdef::openshift-rosa,openshift-rosa-hcp[]
a {product-title} cluster.
endif::openshift-rosa,openshift-rosa-hcp[]

A daemon set ensures that all (or some) nodes run a copy of a pod. As nodes are added to the cluster, pods are added to the cluster.
As nodes are removed from the cluster, those pods are removed through garbage collection. Deleting a daemon set will clean up the pods it created.

You can use daemon sets to create shared storage, run a logging pod on every node in
your cluster, or deploy a monitoring agent on every node.

For security reasons, the cluster administrators and the project administrators can create daemon sets.

[IMPORTANT]
====
Daemon set scheduling is incompatible with the project's default node selector.
If you fail to disable it, the daemon set gets restricted by merging with the default node selector.
This results in frequent pod recreates on the nodes that got unselected by the merged node selector, which in turn puts unwanted load on the cluster.
====

== Scheduled by default scheduler

A daemon set ensures that all eligible nodes run a copy of a pod. Normally, the node that a pod runs on is selected by the Kubernetes scheduler. However, daemon set pods are created and scheduled by the daemon set controller. That introduces the following issues:

* Inconsistent pod behavior: Normal pods waiting to be scheduled are created and in Pending state, but daemon set pods are not created in `Pending` state. This is confusing to the user.
* Pod preemption is handled by default scheduler. When preemption is enabled, the daemon set controller will make scheduling decisions without considering pod priority and preemption.

The *ScheduleDaemonSetPods* feature, enabled by default in {product-title}, lets you schedule daemon sets using the default scheduler instead of the daemon set controller, by adding the `NodeAffinity` term to the daemon set pods, instead of the `spec.nodeName` term. The default scheduler is then used to bind the pod to the target host. If node affinity of the daemon set pod already exists, it is replaced. The daemon set controller only performs these operations when creating or modifying daemon set pods, and no changes are made to the `spec.template` of the daemon set.

[source,yaml]
----
kind: Pod
apiVersion: v1
metadata:
  name: hello-node-6fbccf8d9-9tmzr
#...
spec:
  nodeAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
      nodeSelectorTerms:
      - matchFields:
        - key: metadata.name
          operator: In
          values:
          - target-host-name
#...
----

In addition, a `node.kubernetes.io/unschedulable:NoSchedule` toleration is added automatically to daemon set pods. The default scheduler ignores unschedulable Nodes when scheduling daemon set pods.


// The following include statements pull in the module files that comprise
// the assembly. Include any combination of concept, procedure, or reference
// modules required to cover the user story. You can also include other
// assemblies.

include::modules/nodes-pods-daemonsets-creating.adoc[leveloffset=+1]

[role="_additional-resources"]
== Additional resources

* link:https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/[Kubernetes documentation about daemon sets]
