DaemonSet in Kubernetes

What is a Daemonset in Kubernetes?

DaemonSets are not automatically created for all pods in the cluster. They are designed with a specific purpose in mind, which is to manage one pod per node based on selectors defined in their YAML configuration. This means that you need to explicitly define and create a DaemonSet resource if you want to ensure a specific pod runs on every node within the cluster.

When a new node is added to a Kubernetes cluster, a new pod is created on that node.

The DaemonSet controller guarantees that the pod connected with a node gets trash collected when it is deleted. When you delete a DaemonSet, it will delete all of the pods it has produced.

The Kubernetes DaemonSet controller monitors the health of the cluster and responds to node additions and removals via the Kubernetes API server. It monitors the condition of the nodes and responds appropriately by adding or removing pods on each node to preserve the correct pod state.

The DaemonSet is specified in YAML as follows:

Node Addition:

You can add a new node to your Kubernetes cluster using the kubectl command:

The DaemonSet controller, which is always monitoring the condition of the cluster, recognizes the addition of a new node. It then takes steps to guarantee that the required pod state is preserved by scheduling the log collecting agent pod on the new node.

Node Deletion:

You can add a new node to your Kubernetes cluster using the kubectl command:

The DaemonSet controller is once again monitoring the cluster's status and notices that a node has been destroyed. It replies by destroying the appropriate pod instance on that node, preserving the intended pod state.

The DaemonSet controller dynamically adjusts the number of log-collecting agent pods operating on each node using these operations, guaranteeing that there is always one instance of the agent pod on every node in the cluster, regardless of node additions or removals. DaemonSets in Kubernetes share an essential component of a Kubernetes cluster, allowing administrators to quickly setup services (pods) across all or a subset of nodes.

When it comes to log collecting or monitoring agents, using a DaemonSet is an effective way to install and manage these agents consistently across all nodes. Using a DaemonSet for log collection or monitoring ensures that each node in the Kubernetes cluster has its own instance of the agent, allowing for complete and centralized data collection or monitoring throughout this entire infrastructure.

How to Enter Daemonset

Daemonsets are used to make sure that some or all of your K8S nodes run a copy of a pod, enabling you to execute a daemon on each node.

A pod is created to correspond with each additional node you add to the cluster. In a similar manner, the pod is discarded when a node is removed from your cluster. A Daemonset that is deleted removes all pods it had previously produced.

A Daemonset is a different type of controller that controls pods like StatefulSets, ReplicaSets, and Deployments. Its main duty was to make sure the pods it is in charge of running on all cluster nodes. The DaemonSet makes sure that each new node in the cluster has the required pods operating as soon as it joins. Those pods are discarded once the node exits the cluster.

In Kubernetes, Daemonsets are used when you need to execute one or more pods on all (or a subset of) the nodes in a cluster. A Daemonset's usual use case is host logging and monitoring.

Daemonset Kubernetes Use Cases

It can increase the performance of a Kubernetes cluster by distributing maintenance duties and support services across all nodes via Pod deployment. They are ideal for long-running applications such as monitoring or log collection The following are some use cases of DaemonSets in action:

• To launch a log collection daemon, such as Fluentd or logstash, on each node.
• To execute a daemon for node monitoring on each note, such as Prometheus Node Exporter, collected, or Datadog agent.
• You can configure numerous DaemonSets for a single type of daemon, each with various flags, RAM, CPU, and so on, to support multiple setups and hardware types.

How to Create Daemonset Deployment?

A Daemonset in Kubernetes is implemented by defining and setting it up using a YAML file configuration.

The following sections make up the YAML file:

• apiVersion (mandatory)
• kind (needed) - must be Metadata for DaemonSet
• metadata (needed) 
• spec.template (required) - a pod specification for the pod that you want to run across all nodes.
• spec.selector (needed) - a selector for DaemonSet-managed pods. This value must correspond to one of the labels defined in the pod template.
• spec.template.spec.nodeSelector - can be used to execute on only a subset of the nodes that match the selection.
• spec.template.spec.affinity - can be used to execute on just a subset of the nodes that meet the affinity.

After you've finished configuring, build the DaemonSet in your cluster by completing the following:

Getting Details

To interact with a Daemonset in Kubernetes, such as looking at its details or changing its configuration, use the Kubernetes command-line tool kubectl.

To view the list of Daemonsets in your cluster, open a terminal or command prompt and run the following command:

Run the following command to obtain more information about a given DaemonSet and any connected pods:

Replace <daemonset-name> with the actual name of the Daemonset you wish to analyze.

The following command is used to change a DaemonSet's configuration:

This command launches a text editor specified by environment variables on your system to display the Daemonset settings. To apply the modifications to the Daemonset, make the required changes and save the file.

Daemonset Pods

DaemonSet Pods are Kubernetes instances of pods that are automatically produced and maintained by a DaemonSet. These pods are scheduled on each cluster node, guaranteeing that a copy of the given pod executes on each node.

The following are the primary properties of DaemonSet Pods:

• One Pod Per Node:
  A DaemonSet assures that, depending on a template, exactly one pod is executing on each node in the cluster. The DaemonSet controller is in charge of keeping this desired state.
• Automatic Scheduling and Rescheduling :
  The DaemonSet controller schedules pods on new nodes to meet the one-pod-per-node criterion, and reschedules if node fails or is removed.
• Unique Identity and IP Address:
  Each DaemonSet Pod has a distinct identity and IP address connected with the node on which it runs. This prevents pods from overlapping or duplicating across nodes.

Deleting a Kubernetes Daemonset

It is straightforward to delete a DaemonSet. Simply use the kubectl delete command with the DaemonSet to do this. This would erase the DaemonSet along with all of its underlying pods.

We may use the cascade=false parameter in the kubectl delete command to destroy only the DaemonSet and not the pods.

How to Restrict Daemonset to Run on Specific Nodes

Using Nodeselector For Daemonset Pods

To execute the pods on certain nodes, we may use nodeSelector. The Daemonset controller will construct Pods on nodes that match the key and value of the node selector.

To begin, you must add a label to the node.

To mark a node as type=platform-tools, for example, run the following command.

To apply a nodeSelector to a Daemonset, add the nodeSelector with the key and value provided below to the spec section.

In the YAML setup of your DaemonSet, you can set up a node selector to limit DaemonSet pods to specified nodes depending on their labels. Here is an example:

Node Affinity:

Another method is to use node affinity criteria to generate more complicated DaemonSet placement limitations. You can set criteria for node affinity based on node labels, node taints, or other node attributes. In a DaemonSet YAML setup, here's an example of leveraging node affinity:

The requiredDuringSchedulingIgnoredDuringExecution parameter in this example states that DaemonSet pods must be scheduled on nodes that match the supplied label key-value pair (my-label-key=my-label-value).

In the DaemonSet setup, you may limit the DaemonSet pods to only execute on the nodes that satisfy the given requirements by using node selectors or node affinity rules. By doing so, you may target particular nodes in your cluster and have fine-grained control over pod placement.

Reaching DaemonSet Pods

The following are some potential communication patterns for Pods in a DaemonSet:

• Push:
  Pods in the DaemonSet are configured to send changes to another service, such as a statistics database. They have no customers.
• NodeIP and Known Port:
  Pods in the DaemonSet can utilize a hostPort to be reachable through the node IPs. Clients know the list of node IPs and the port via a convention.
• DNS:
  Use the same pod selector to create a headless service, then use the endpoints resource to discover DaemonSets or obtain multiple A records via DNS.
• Service:
  Create a service using the same Pod selector and use it to interact with a daemon on a random node.