NodeIP  with hostPort 

Pods in the DaemonSet can specify a hostPort  and become reachable via the node IP addresses and the specified port. Since the combination of hostIp  and hostPort  and protocol  must be unique, the number of places where a Pod can be scheduled is limited. 

Push 

The application in the DaemonSets Pod can push data to a well-known location or service that’s external to the Pod. No consumer needs to reach the Daemon‐ Sets Pods. 

## Static Pods 

Another way to run containers similar to the way a DaemonSet does is through the static Pods  mechanism. The Kubelet, in addition to talking to the Kubernetes API Server and getting Pod manifests, can also get the resource definitions from a local directory. Pods defined this way are managed by the Kubelet only and run on one node only. The API service is not observing these Pods, and there are no controller and no health checks performed on them. The Kubelet watches such Pods and restarts them when they crash. Similarly, the Kubelet also periodically scans the con‐ figured directory for Pod definition changes and adds or removes Pods accordingly. 

Static Pods can be used to spin off a containerized version of Kubernetes system pro‐ cesses or other containers. But DaemonSets are better integrated with the rest of the platform and recommended over static Pods. 

## Discussion 

In this book, we describe patterns and Kubernetes features primarily used by devel‐ opers rather than platform administrators. A DaemonSet is somewhere in the middle, inclining more toward the administrator toolbox, but we include it here because it also has applicability to application developers. DaemonSets and CronJobs are also perfect examples of how Kubernetes turns single-node concepts such as Crontab and daemon scripts into multinode clustered primitives for managing distributed sys‐ tems. These are new distributed concepts developers must also be familiar with. 

