- Daemonsets are used to ensure a copy of a pod runs on each node within a cluster
- Nodes can be included/excluded from the scope using node selectors
- They automatically deploy a copy of the pod to any nodes that are added to the cluster
- Garbage collection removes the pod when the nodes are removed
- Deleting a Daemonset deletes all the associated pods on the nodes
- When labels are changed on cluster nodes the Daemonset will automatically add/remove pods from the nodes to ensure each node with a matching label has a running pod, and that the pod doesn’t run on any nodes that are no longer labelled
- It is not possible to update or change the pods within a Daemonset without deleting and recreating
- Usecases include running a logging pod on each node such as fluentd
- Multiple Daemonsets can be created for different usecases
- Pods created by Daemonsets are not controlled by the Kubernetes scheduler, instead they are controlled by the DaemonSet controller
- The DaemonSet controller can create pods even when the Kubernetes scheduler is unavailable
- The DaemonSet controller will ensure pods are restarted based on the RestartPolicy within the pod spec being set to Always, which is a requirement for DaemonSets
- The spec used to create Daemonsets has to specify:
- The metadata for the Daemonset
- The selector spec
- The pod template spec to use for the pods (basic spec as per the pod specification without the apiVersion and kind values)
- The container spec to use for the pods