Daemon Service mode allows for scheduling and running high-priority, infrastructure-focused Pods on target nodes. administrators primarily use it to run node-specific Pods to enhance the Kubernetes platform.

Existence of problems

The concept of daemon processes in software systems exists at many levels. At the operating system level, a daemon is a long-running, self-recovering computer program that runs as a background process. In Unix, daemon names end with a “d”, such as httpd, named, and sshd. In other operating systems, alternative terms such as service-initiated tasks and ghost jobs are used.

Regardless of what they are called, the common feature of these programs is that they run as processes, usually without interacting with the monitor, keyboard, and mouse, and are started at system startup. A similar concept exists at the application level. For example, in the JVM daemon threads run in the background and provide support services to user threads. These daemon threads have a low priority, run in the background, have no say in the application lifecycle, and perform tasks similar to garbage collection or termination.

Similarly, the concept of DaemonSet is available in Kubernetes. Considering that Kubernetes is a distributed platform, spread across multiple nodes, with the primary goal of managing application Pods, DaemonSet is represented by Pods running on cluster nodes and provides some background functionality to the other nodes of the cluster.

Solution

ReplicaSet and its predecessor, ReplicationController, are control structures responsible for ensuring that a specific number of Pods are running. These controllers constantly monitor the list of running Pods and ensure that the actual number of Pods always matches the desired number. In this respect, DaemonSet is a similar structure responsible for ensuring that a certain number of Pods are always running. The difference is that the former two run a specific number of Pods, usually driven by application requirements for high availability and user load, regardless of the number of nodes.

DaemonSet, on the other hand, is not driven by consumer load when deciding how many Pod instances to run and where to run them. Its main purpose is to keep one Pod running per node or on a specific node. let’s see the definition of such a DaemonSet next in Example 1-1.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

1.1 DaemonSet 实例
apiVersion: extensions/v1beta1
kind: DaemonSet
metadata: 
  name: random-refresher
spec:
  selector:
    matchLabels:
      app: random-refresher
  template:
    metadata:
      labels:
        app: random-refresher
    spec: 
      nodeSelector:
        feature: hw-rng 
      containers:
      - image: k8spatterns/random-generator:1.0
        name: random-generator
        command:
        - sh
        - -c
        - >-
          "while true; do
          java -cp / RandomRunner /host_dev/random 100000;
          sleep 30; done"          
        volumeMounts:
        - mountPath: /host_dev
          name: devices
        volumes:
        - name: devices
          hostPath:
            path: /dev

Given this behavior, the primary candidates for DaemonSet are usually infrastructure-related processes such as log collectors, metric exporters, or even kube-proxy, which perform cluster-wide operations. there are many differences between how DaemonSet and ReplicaSet are managed, but the main ones are as follows.

  • By default, DaemonSet schedules a Pod instance for each node. This can be controlled and limited to a subset of nodes by using the nodeSelector field.
  • Pods created by DaemonSet already have a nodeName specified. therefore, DaemonSet does not require the presence of a Kubernetes scheduler to run the container. This also allows the use of DaemonSet to run and manage Kubernetes components.
  • Pods created by DaemonSet can run before the scheduler starts, which allows them to run before any other Pods are scheduled on the node.
  • Pods managed by DaemonSet should only run on the target node and, therefore, be treated with higher priority and differently by many controllers. For example, the descheduler avoids evicting such Pods, the cluster autoscaler manages them separately, etc.

Typically, a DaemonSet creates a single Pod on each node or subset of nodes. given this, there are several ways in which DaemonSets managed Pods can be reached.

  • Service

    Create a Service with the same Pod selector as the DaemonSet and use that Service to reach a daemon Pod load balanced to a random node.

  • DNS

    Create a headless service with the same Pod selector as DaemonSet that can be used to retrieve multiple A records from DNS containing all Pod IPs and ports.

  • NodeIP with HostPort

    Pods in DaemonSet can specify a hostPort and be accessed via the node IP address and the specified port. Since the combination of hostIp and hostPort and protocol must be unique, the number of places a Pod can be dispatched is limited.

  • Push

    Applications in DaemonSets Pods can push data to a specified location or service outside the Pods. There is no need for consumers to reach DaemonSets Pods.

Another way to run containers similar to DaemonSet is through the static Pods mechanism. kubelet can fetch resource definitions from a local directory in addition to talking to the Kubernetes APIServer and getting a list of Pods. Pods defined in this way are managed by Kubelet only and run on only one node. the API service does not watch these Pods, nor does it have a controller or perform health checks on them. kubelet watches such Pods and restarts them when they crash. Similarly, Kubelet periodically scans the configured directory for changes in Pod definitions and adds or removes Pods accordingly.

Static Pods can be used to spin up containerized versions of Kubernetes system processes or other containers. However, DaemonSets are better integrated with the rest of the platform and are recommended over static Pods.

Discussion

The patterns and Kubernetes features we describe are primarily used by developers rather than platform administrators. DaemonSet falls somewhere in between and is more of an administrator toolkit, but we include it here because it has applicability to application developers as well. DaemonSets and CronJobs are also examples of how Kubernetes can incorporate DaemonSets and CronJobs are also perfect examples of how Kubernetes transforms single-node concepts like Crontab and daemon scripts into multi-node cluster primitives for managing distributed systems. These are all new distributed concepts that developers must also be familiar with.