In this blog post, we’ll discuss what DaemonSets are, what they can be used for, and how to update them.
What is a DaemonSet?
A Kubernetes DaemonSet is a container tool that ensures that all nodes are running exactly one copy of a pod. DaemonSets will even create the pod on new nodes that are added to your cluster. As nodes are removed from the cluster, those Pods are garbage collected. Deleting a DaemonSet will clean up the Pods it created.
DaemonSets are an essential component of a Kubernetes cluster, allowing administrators to easily configure services (pods) across all or a subset of nodes.
DaemonSet use cases -
DaemonSets can boost the performance of a Kubernetes cluster by distributing maintenance tasks and support services across all nodes via Pod deployment. They are ideal for long-running services such as monitoring or log collection.
Some typical uses of a DaemonSet are:
- Running a cluster storage daemon on every node
- Running a logs collection daemon on every node
- Running a node monitoring daemon on every node
You can configure multiple DaemonSets for a single type of daemon, with different flags, memory, CPU, and so on, to support multiple configurations and hardware types.
How Daemon Pods are scheduled?
A DaemonSet ensures that a copy of a Pod is running on all eligible nodes. The Kubernetes scheduler normally chooses the node on which a Pod runs. However, DaemonSet pods are created and scheduled by the DaemonSet controller instead. This raises the following concerns:
- Inconsistent Pod behavior: Normal Pods waiting to be scheduled are created and in Pending state, but DaemonSet 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 DaemonSet controller will make scheduling decisions without considering pod priority and preemption.
ScheduleDaemonSetPods allows you to schedule DaemonSets using the default scheduler instead of the DaemonSet controller, by adding the NodeAffinity term to the DaemonSet 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 DaemonSet pod already exists, it is replaced (the original node affinity was taken into account before selecting the target host). The DaemonSet controller only performs these operations when creating or modifying DaemonSet pods, and no changes are made to the spec.template of the DaemonSet.
Communicating with Daemon Pods
Some patterns for communicating with Pods in a DaemonSet include -
Push: Pods in the DaemonSet are configured to send updates to another service, such as a stats database. They do not have clients.
NodeIP and Known Port: Pods in the DaemonSet can use a hostPort, so that the pods are reachable via the node IPs. Clients know the list of node IPs somehow, and know the port by convention.
DNS: Create a headless service with the same pod selector, and then discover DaemonSets using the endpoints resource or retrieve multiple A records from DNS.
Service: Create a service with the same Pod selector, and use the service to reach a daemon on a random node. (No way to reach specific node.)
Alternatives to DaemonSets
Despite the fact that DaemonSets are extremely powerful, there are other ways to achieve similar workflows within Kubernetes.
1. init
Init scripts could be used to run daemon processes on node startup. However, running such processes through a DaemonSet has several advantages -
- The ability to monitor and manage daemon logs in the same way that applications do.
- For daemons and applications, the same configuration language and tools (e.g., pod templates, kubectl) are used.
- Running daemons in resource-constrained containers increases isolation between daemons and app containers. This can, however, be accomplished by running the daemons in a container rather than a Pod (e.g. start directly via Docker).
2. Bare Pods
It is possible to create Pods directly which specify a particular node to run on. However, a DaemonSet replaces Pods that are deleted or terminated for any reason, such as in the case of node failure or disruptive node maintenance, such as a kernel upgrade. For this reason, you should use a DaemonSet rather than creating individual Pods
3. Static Pods
It is possible to create Pods by writing a file to a certain directory watched by Kubelet. These are called static pods. Static Pods cannot be managed with kubectl or other Kubernetes API clients. They are also do not depend on the apiserver, making them useful in cluster bootstrapping cases.
DaemonSets, like Deployments and StatefulSets, are popular controllers in the Kubernetes system. DaemonSets are a powerful tool for automating and streamlining many time-consuming Kubernetes processes.
With that, I'll conclude this post. I hope you find this information useful.
Thank you for reading!
*** Explore | Share | Grow ***
Comments