通过该控制器的名称我们可以看出他的用法daemon,就是用来部署守护进程的，daemonSet用于在每个kubernetes节点中将守护进程的副本作为后台进程运行，说白了就是每个节点部署一个pod副本，当节点加入到kubennetes集群中，pod会被调度到该节点上运行，当节点从集群只能够被移除后，该节点上的pod也会被移除，当然我们删除daemonSet，所有和这些对象相关的pods都会被删除。
集群存储守护程序，glusterd ceph要部署在每个节点上提供持久性存储
节点监控守护进程，prometheus监控集群，可以在每个节点上运行一个node-exporter进程来收集监控节点的信息
日志收集守护程序，节点网络插件，特别是关于daemonSet运行的pod的调度问题，正常情况下，pod运行在那个节点上有kubernetes的调度器策略来决定，然而有daemonSet控制器创建的pod实际上提前已经确定了在那个节点上了，pod创建时指定.spec.nodeName
DaemonSet并不关心一个节点的unshedulable字段，这个我们会在后面的调度章节
DaemonSet可以创建pod，即使调度器还没启动
[root@master1 ~]# cat nginx-ds.yaml
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: nginx-ds
namespace: default
spec:
selector:
matchLabels:
k8s-app: nginx
template:
metadata:
labels:
k8s-app: nginx
spec:
containers:
- image: nginx:1.7.9
name: nginx
ports:
- name: http
containerPort: 80
我们观察可以发现除了master节点之外的4个节点上都有一个相应的pod运行，因为master节点上默认打上污点，所以默认情况下不能调度普通的pod上去
集群中的pod和node是意义对应，而daemonSet会管理全部机器上的pod副本，负责对他们进行更新和删除。
那么daemonSet控制器是如何保证每个node上有且只有一个被管理的pod呢？
首先控制器从etcd获取到所有的node列表，然后遍历所有的node
根据资源对象定义是否有调度相关的配置，然后分别检车node是否符合要求
运行pod的节点上检查是否已有对应的pod，如果没有，则在这个node上创建该pod,如果有，并且数量大于1，那就把多余的pod从这个节点删除，
