Kubernetes DaemonSet – All you need to know!

Filed Under: Random
Kubernetes Daemonset

Hello, readers! In this article, we will be focusing on one of the most interesting concepts – Kubernetes DaemonSet, in detail.

So, let us begin! 馃檪


What is a Kubernetes DaemonSet?

Before exploring Kubernetes DaemonSet, image the below scenario..

Kubernetes provides us with various resources such as Pods, deployments, services that we can be bound to a namespace and been worked on the following the limit.

But what if you require any deployment through a Pod to run on a cluster level dynamically?

For example, you want the proxy set up that establishes a connection between the cluster and the desktop users over private network to be available continuously. In such scenarios, you would need a deployment that would spin up a pod every time making it available on every node of the cluster.

This is when DaemonSet comes into picture.

DaemonSet makes sure that a copy of the Pod with some specific functionality keeps running on every node within the cluster.

Also, whenever we spin up a new node in the cluster, the newly entered node should also run a copy of that Pod. The moment we delete a node from the cluster, all the pods set up by the DaemonSet gets deleted.

Let us now focus on the creation of one such DaemonSet in the upcoming sections.


Creating a Kubernetes DaemonSet

Have a look at the below YAML schema of a Kubernetes DaemonSet–

apiVersion: apps/v1
kind: DaemonSet

metadata:
  name: demo-daemonset
  namespace: demo

spec:
  selector:
    matchLabels:
      name: demo-pod
  template:
    metadata:
      labels:
        name: demo-pod
    spec:
      tolerations:
      - key: node-role.kubernetes.io/master
        effect: NoSchedule
      containers:
      - name: demo-daemonset
        image: search:v1.0
        resources:
          limits:
            memory: 500Mi
          requests:
            cpu: "1"
            memory: 100Mi
  • The above DaemonSet YAML includes the apiVersion, kind and metadata, which is of course the basic requirement of every kubernetes resource.
  • It needs a Pod template that would include all the information (YAML schema) to create a Pod once we spin up a new node within the cluster.
  • We would further need to include a Pod selector template that would select and apply only those pod schema’s that match the labels with the selectors.
  • A nodeselector label would be needed(taint and toleration) to select on which node would we want to spin up the pod continuously. If we don’t specify any node selector, the DaemonSet spins up pods on all the nodes within the cluster. In the above structure, we have tainted the pods to spin up on the master nodes within the kubernetes cluster.

Establishing Communication with DaemonSet

  • Service: In order to communicate with the DaemonSet, we can create a service with the same label as that of the Pod, which would help the DaemonSet reach any random node.
  • DNS: We can have a headless service with the pod selector and then spin up a pod to see the communication like retrieval of records from DNS.
  • NodeIP: We can communicate with the Pods through the Nodes using the node IP range values.

Conclusion

By this, we have come to the end of this topic. Feel free to comment below, in case you come across any question. For more such posts related to Docker and Kubernetes, Stay tuned with us.

Till then, Happy Learning!! 馃檪

Leave a Reply

Your email address will not be published. Required fields are marked *

close
Generic selectors
Exact matches only
Search in title
Search in content