hostPath : path : /dev Use only nodes with the label  feature  set to value  hw-rng . DaemonSets often mount a portion of a node’s filesystem to perform mainte‐ nance actions. hostPath  for accessing the node directories directly. Given this behavior, the primary candidates for a DaemonSet are usually infrastructure-related processes such as log collectors, metric exporters, and even kube-proxy, that perform cluster-wide operations. There are many differences in how DaemonSet and ReplicaSet are managed, but the main ones are the following: Typically a DaemonSet creates a single Pod on every node or subset of nodes. Given that, there are several ways for Pods managed by DaemonSets to be reached: Service Create a Service with the same Pod selector as a DaemonSet, and use the Service to reach a daemon Pod load-balanced to a random node. DNS Create a headless Service with the same Pod selector as a DaemonSet that can be used to retrieve multiple A records from DNS containing all Pod IPs and ports. • Pods managed by a DaemonSet are supposed to run only on targeted nodes, and as a result, are treated with higher priority and differently by many controllers. For example, the descheduler will avoid evicting such Pods, the cluster autoscaler will manage them separately, etc. • Since the scheduler is not used, the  unschedulable  field of a node is not respec‐ ted by the DaemonSet controller. • Pods created by a DaemonSet can run before the scheduler has started, which allows them to run before any other Pod is placed on a node. • A Pod created by a DaemonSet already has  nodeName  specified. As a result, the DaemonSet doesn’t require the existence of the Kubernetes scheduler to run con‐ tainers. That also allows using a DaemonSet for running and managing the Kubernetes components. • By default, a DaemonSet places one Pod instance to every node. That can be con‐ trolled and limited to a subset of nodes by using the  nodeSelector  field. Solution  |  75