Introduction : Kubernetes is an open-source container orchestration platform that provides powerful tools for managing and deploying containerized applications at scale. Two important concepts in Kubernetes are DaemonSets and Static Pods. DaemonSets ensure that a specific pod is running on every node in the cluster, while Static Pods are simple pods that are managed directly by the kubelet on a specific node. While both of these features offer similar functionality, there are key differences between them that can impact how you deploy and manage your applications. In this article, we’ll explore the differences between DaemonSets and Static Pods in Kubernetes, including their use cases, benefits, and drawbacks.

Prerequisites: A fundamental understanding of kubernetes and its various components.

Let’s Go !

Daemon Sets and Static Pods are two types of pods in Kubernetes that run on nodes in a cluster. However, there are some key differences between these two :

1. Daemon Sets: Daemon sets are used to ensure that a single instance of a pod runs on every node in a cluster. This is useful for running system-level services such as log collectors, network proxies, and monitoring agents. The pods created by a Daemon Set are managed by the Kubernetes control plane, and if a node goes down, the Daemon Set controller will automatically reschedule the pod to another node.

2. Static Pods: Static Pods are pods that are directly created on the host rather than being managed by the Kubernetes control plane. This means that the control plane does not have control over the lifecycle of the pod, and it will not reschedule it in case of a node failure. Static pods are useful in cases where there is a need for more control over the pod, or in scenarios where the control plane itself is not available.

3. Daemon set ensures that one instance of an application is available on all node in a kubernetes cluster and this is handled by the deamon set controller through the api server.

4. Static pods are created directly by the kubelet without any inteference from the kube api-server or the rest of the other control plane components.

5. Both static pods and the pods created by the daemon set are ignored by the kube-scheduler.

In summary, Daemon Sets are easier to manage and provide more automatic recovery, while Static Pods offer more control and can be useful in certain scenarios where the control plane is not available.

Here are two examples of how Daemon Sets and Static Pods can be used:

1. Daemon Set Example: Imagine you have a logging system for your cluster, and you want to ensure that a logging agent is running on every node to collect logs from the containers running on that node. In this case, you could use a Daemon Set to automatically deploy a logging agent pod to every node in the cluster. The Daemon Set controller would take care of creating, updating, and deleting pods as needed to ensure that there is always one instance of the logging agent running on each node.

2. Static Pod Example: Imagine you have a critical application running in your cluster that requires a specific version of a database. You don’t want the Kubernetes control plane to interfere with the running of this database, as any downtime could cause problems for your application. In this case, you could use a Static Pod to run the database on each node. By creating the Static Pod directly on the host, you bypass the control plane and have more control over the lifecycle of the pod.

These are just two examples of how Daemon Sets and Static Pods can be used in a Kubernetes cluster. Both types of pods have their use cases, and the choice between the two will depend on your specific needs and requirements.

Here’s an example of how you might use a Static Pod to deploy a critical database to a Kubernetes cluster:

1. Create a YAML file for the Static Pod definition, for example let call this yaml file db.yaml

apiVersion: v1
kind: Pod
metadata:
  name: database
spec:
  containers:
  - name: database
    image: myregistry/database:v1.0
    ports:
    - containerPort: 5432
    volumeMounts:
    - name: data
      mountPath: /var/lib/data
  volumes:
  - name: data
    hostPath:
      path: /var/lib/data

2. move the YAML file to the /etc/kubernetes/manifests directory on each node where you want the database to run:

$ mv db.yaml /etc/kubernetes/manifests

3. Restart the kubelet service

$ systemctl restart kubelet

4. Verify that the Static Pod has been successfully created and is running on each node:

$ kubectl get pods

By copying the YAML file to the /etc/kubernetes/manifests directory on each node, the Static Pod is directly created on the host and is not managed by the Kubernetes control plane but instead it is managed by the kubelet on that Node. This provides more control over the lifecycle of the pod and ensures that the database is running even if the control plane is not available.

Here’s an example of how you might use a Daemon Set to deploy a logging agent to every node in a Kubernetes cluster:

1. Create a YAML file for the Daemon Set definition, for example:

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: logging-agent
spec:
  selector:
    matchLabels:
      app: logging-agent
  template:
    metadata:
      labels:
        app: logging-agent
    spec:
      containers:
      - name: logging-agent
        image: myregistry/logging-agent:v1.0
        ports:
        - containerPort: 8080
        volumeMounts:
        - name: logs
          mountPath: /var/logs
      volumes:
      - name: logs
        hostPath:
          path: /var/logs

2. Apply the Daemon Set definition using the kubectl apply command:

$ kubectl apply -f logging-agent-daemonset.yaml

3. Verify that the Daemon Set has been successfully created and that a pod has been created on each node in the cluster:

$ kubectl get daemonset

In this example, the Daemon Set definition specifies a template for the logging agent pod, including the Docker image to use and the volumes to mount. The Daemon Set controller takes care of creating one instance of the pod on each node in the cluster and managing its lifecycle, ensuring that there is always a logging agent running on every node.

In conclusion, Daemon Sets and Static Pods are two distinct concepts in Kubernetes that can be used to deploy and manage your applications. While Daemon Sets are best suited for deploying and managing background processes that need to run on all nodes in a Kubernetes cluster, Static Pods are ideal for deploying and managing simple, single-instance pods that run on a specific node.

By understanding the differences between these two concepts and their use cases, you can make informed decisions when it comes to deploying and managing your applications in Kubernetes.