Kubernetes: Run A Pod Per Node With Daemon Sets
My initial title to this article was just “Daemon Sets” with the assumption that it would be enough to get the point across to anyone interested in reading. But quickly I thought back to when I first saw Daemon Sets in the Kubernetes documentation and remembered my own curiosity and also my own ambivalence to the topic. However, in some situations Daemon Sets will get you out of a very specific bind. Let’s explore more.
So by now we know already that Kubernetes is a mixture of Pods that run on Nodes. Easy enough. However there is no promise of which Node a pod will run or that there will be some uniform spacing of Pods over Nodes.
If you have a situation where you need a Pod to be tied 1–1 with a Node (such as a Monitoring or Logging Pod) then how can you guarantee that there will be the necessary Pod to Node layout? Daemon Sets, that’s how. Daemon Sets create a Pod for each Node that is created. So if a new Node is spun up, so is the Daemon Set’s Pod to be run on that Node. If a Node is removed, so too is the Daemon Set’s Pods that belonged to that Node.
Let’s look at how to define a Daemon Set and see one in action.
If you haven’t gone through or even read the first part of this series you might be lost of have questions where this code is or what was done previously. Remember this assumes you’re using GCP and GKE.
This is the obligatory step one Kubernetes post. If you’re interested in Kubernetes you’ve probably read 100 of these…medium.com
Creating A Kubernetes Daemon Set
If you read through a few of my other posts (you should!), the following yaml file is going to seem very familiar to others. You’ll notice the
.metadata section as you’ve seen before along with the
.spec section. What makes a Daemon Set different is the
.kind parameter. If set to
Daemon Set then Kubernetes will automatically create the Pod described in the
.spec.template under each Node in your Kubernetes Cluster.
kind: DaemonSet # it is a daemonset
name: daemonset-pods # name of the daemon set
# any Pods with matching labels are included in this Daemon Set
# Pods will match with the following labels
# Pod Template
# Pod's labels
# the container(s) in this Pod
- name: daemon-container
# environment variables for the Pod
- name: GCLOUD_PROJECT
- containerPort: 80
Kubernetes Daemon Sets In Action
To test the DaemonSet we will start by creating our Kubernetes Cluster as we have in many previous articles. The following scripts, when run in your Google Cloud Shell will create a Kubernetes Cluster and deploy the Daemon Set yaml file to your Cluster.
$ git clone https://github.com/jonbcampos/kubernetes-series.git
$ cd ~/kubernetes-series/daemon/scripts
$ sh startup.sh
$ sh deploy.sh
$ sh check-endpoint.sh endpoints
It is important to note that this is a 3 Node Cluster in Kubernetes. This is important because as soon as you run the deploy script you can see in your
GCP Kubernetes > Workloads view that you will have a Daemon Set Pod named
daemonset-pods deployed, specifically 3 of these pods.
Now I created a pretty crude script to scale the Cluster by X nodes. You can run that script as such:
$ cd ~/kubernetes-series/daemon/scripts
$ sh scale.sh 3 # scale up by 3 nodes
This script adds a node-pool named
my-pool and tells the node-pool to add X (3 in this case) Nodes to the Cluster. If you go back to your Workflows view you see immediately that the new Nodes are spinning up… and so are Daemon Set’s Pods.
After a moment when everything is ready our Kubernetes Cluster is officially at 6 Nodes with 6 Daemon Set Pods and still the original 3
It is always a wonderful thing to see how easily Kubernetes handles a problem while giving you the flexibility to solve problems specific to your applications. Now you can see how to schedule Pods based on Nodes rather than the random Pod to Node assigning that is default to Kubernetes.
Before you leave make sure to cleanup your project so you aren’t charged for the VMs that you’re using to run your cluster. Return to the Cloud Shell and run the teardown script to cleanup your project. This will delete your cluster and the containers that we’ve built.
Other Posts In This Series
Sometimes your work isn’t transactional. Instead of waiting for a user to click a button and have systems light up we…medium.com
When building an application it is common that you’ll need to interact with external services to complete your business…medium.com
I remember when I was first getting into Kubernetes. Everything was new and shiny and about scale. As I continued…medium.com
With Pod Autoscaling your Kubernetes Cluster can monitor the load of your existing Pods and determine if we need more…medium.com
In case there was any question about this feature, I am writing about it specifically to state that this is not an…itnext.io
Jonathan Campos is an avid developer and fan of learning new things. I believe that we should always keep learning and growing and failing. I am always a supporter of the development community and always willing to help. So if you have questions or comments on this story please ad them below. Connect with me on LinkedIn or Twitter and mention this story.