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.
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!! 🙂