写留言这篇文章我们来介绍kubernete的一个编排对象，叫DaemonSet，从名字上就能看出，这是一个守护进程。它的作用是在kubernete集群的每个节点上都会创建一个Daemon Pod，而且仅有一个。
作为容器的守护进程，这个Daemon Pod的典型应用是运行网络插件、存储插件、监控和日志组件等。
yaml文件
DaemonSet在yaml中的声明很简单，只要声明api对象的kind是DaemonSet即可。我们写一个文件daemonset.yaml，内容如下：
apiVersion: apps/v1 kind: DaemonSet metadata: name: fluentd-elasticsearch namespace: kube-system labels: k8s-app: fluentd-logging spec: selector: matchLabels: name: fluentd-elasticsearch template: metadata: labels: name: fluentd-elasticsearch spec: tolerations: # this toleration is to have the daemonset runnable on master nodes # remove it if your masters can't run pods - key: node-role.kubernetes.io/master effect: NoSchedule containers: - name: fluentd-elasticsearch image: quay.io/fluentd_elasticsearch/fluentd:v2.5.2 resources: limits: memory: 200Mi requests: cpu: 100m memory: 200Mi volumeMounts: - name: varlog mountPath: /var/log - name: varlibdockercontainers mountPath: /var/lib/docker/containers readOnly: true terminationGracePeriodSeconds: 30 volumes: - name: varlog hostPath: path: /var/log - name: varlibdockercontainers hostPath: path: /var/lib/docker/containers
上面这个yaml文件来自官网。可以看到上面的kind是DaemonSet。这个DaemonSet，管理的pod中的镜像是fluentd-elasticsearch镜像，这个镜像的作用是通过fluentd将Docker容器里的日志收集到ElasticSearch。
下面我对这个yaml文件做一个说明：
- 文件中定义了一个template，这个template声明了labels是fluentd-elasticsearch。
- DaemonSet的yaml文件中，RestartPolicy要不不指定，如果指定必须指定为always，其实不指定默认也是always。
- DaemonSet的yaml文件中必须定义.spec.selector，这个selector跟pod中的selector含义是一样的，包括2个元素，matchLabels(跟replicas中一样)和matchExpressions(通过键值列表构建更复杂的选择器)。这个选项是用来匹配携带.spec.template.metadata.labels标签中的api对象。
调度策略
Daemon pod由kubernete scheduler调度到需要的node上，然后由DaemonSet Controller在node上进行创建和调度。
DaemonSet Controller首先从Etcd里获取所有的Node列表，然后依次遍历Node，如果当前node上没有携带name=fluentd-elasticsearch标签的pod，就创建一个，如果有多余一个，就删除多余的。
跟普通pod不一样的是，Daemon pod在创建之前不会进入pending状态。
那DaemonSet怎么控制pod在指定节点上运行呢？它是通过nodeAffinity这个标签来管理的。在Daemon pod中增加NodeAffinity元素来取代.spec.nodeName，就可以使用默认的scheduler来取代DaemonSet Controller来对DaemonSets进行调度，然后默认的调度器再把pod调度到需要的节点上。如下：
nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchFields: - key: metadata.name operator: In values: - target-host-name
如果node上已经存在affinity的pod，则默认调度器会用新创建的pod取代它。而DaemonSet controller不会这么做。
上面的requiredDuringSchedulingIgnoredDuringExecution是说，这个nodeAffinity必须在每次调度的时候都进行考虑，而在运行阶段不用考虑。而且这个pod只允许运行在metadata.name是target-host-name的节点上创建。
注：上面的operator的语法非常丰富，这里用in是包含关系，也可以是Equal，等于关系。
DaemonSet还会给Daemon Pod加上Tolerations，它的意思是可以容忍一些Taints(污点)
apiVersion: v1 kind: Pod metadata: name: with-toleration spec: tolerations: - key: node.kubernetes.io/unschedulable operator: Exists effect: NoSchedule
这段代码中，effect: NoSchedule就是指node一个Taints即不能被任何pod调度，但是DaemonSet给管理的pod加上Toleration后，Daemon pod就会忽略这个限制，继续对有这个node上的pod进行调度。
这就是DaemonSet的特殊之处，它能够通过tolerations来对有Taints限制的节点上的pod进行调度，比如，我们要对有node.kubernetes.io/network-unavailableTaints的节点进行网络调度，就可以定义如下的tolerations
template: metadata: labels: name: network-plugin-agent spec: tolerations: - key: node.kubernetes.io/network-unavailable operator: Exists effect: NoSchedule
虽然DaemonSet可以在yaml中声明式的定义toleration，但是下面的toleration会自动添加到DaemonSet创建的pod中，如下图：
创建、升级和回滚
执行下面命令，创建Daemon pod
kubectl apply -f daemonset.yaml
过几分钟查看pods，如下：
[root@master k8s]# kubectl get pod -n kube-system -l name=fluentd-elasticsearch NAME READY STATUS RESTARTS AGE fluentd-elasticsearch-5mgqr 1/1 Running 0 147m fluentd-elasticsearch-6nwlp 1/1 Running 0 147m
可以看到DaemonSet创建了2个pod，而我本地的kubernete集群只有2个节点，一个master和一个普通节点，这2个节点都调度了一个Daemon pod，而普通pod是不能调度到master节点的，这就是DaemonSet的tolerations生效了。
我们可以向Deployment那样管理DaemonSet的版本，如下：
kubectl rollout history daemonset fluentd-elasticsearch -n kube-system
接着我们把fluentd-elasticsearch镜像的版本升级到v2.2.0
kubectl set image ds/fluentd-elasticsearch fluentd-elasticsearch=k8s.gcr.io/fluentd-elasticsearch:v2.2.0 --record -n=kube-system
这时我们再查看版本更新的历史，如下：
[root@worker1 ~]# kubectl rollout history daemonset fluentd-elasticsearch -n kube-system daemonset.apps/fluentd-elasticsearch REVISION CHANGE-CAUSE 2 kubectl set image ds/fluentd-elasticsearch fluentd-elasticsearch=k8s.gcr.io/fluentd-elasticsearch:v2.2.0 --record=true --namespace=kube-system 3 <none>
总结
DaemonSet的调度策略其实是在创建Daemon pod时给这个Pod加上一个nodeAffinity，从而保证这个Pod能够在指定节点上启动。通过给这个Pod加上一个 Toleration，从而保证pod能在有Taints限制的节点上创建。
DaemonSet的升级和回滚策略跟Deployment非常相似，不同的是，它管理版本用的是ControllerRevision对象。
一般情况下，Daemon pod跟普通的pod功能一样，但是如果给守护进程做程序配置、监控和日志收集，使用DaemonSet更合适一些。有时候我们要指定一些节点创建pod，也可以使用DaemonSet。
