kubernete编排技术五：DaemonSet

yaml文件

调度策略

创建、升级和回滚

总结

这篇文章我们来介绍kubernete的一个编排对象，叫DaemonSet，从名字上就能看出，这是一个守护进程。它的作用是在kubernete集群的每个节点上都会创建一个Daemon Pod，而且仅有一个。

作为容器的守护进程，这个Daemon Pod的典型应用是运行网络插件、存储插件、监控和日志组件等。

yaml文件

DaemonSet在yaml中的声明很简单，只要声明api对象的kind是DaemonSet即可。我们写一个文件daemonset.yaml，内容如下：

apiVersion: apps/v1
kind: DaemonSet
metadata:name: fluentd-elasticsearchnamespace: kube-systemlabels:k8s-app: fluentd-logging
spec:selector:matchLabels:name: fluentd-elasticsearchtemplate:metadata:labels:name: fluentd-elasticsearchspec: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/mastereffect: NoSchedulecontainers:- name: fluentd-elasticsearchimage: quay.io/fluentd_elasticsearch/fluentd:v2.5.2resources:limits:memory: 200Mirequests:cpu: 100mmemory: 200MivolumeMounts:- name: varlogmountPath: /var/log- name: varlibdockercontainersmountPath: /var/lib/docker/containersreadOnly: trueterminationGracePeriodSeconds: 30volumes:- name: varloghostPath:path: /var/log- name: varlibdockercontainershostPath: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.nameoperator: Invalues:- 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/unschedulableoperator: Existseffect: 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-agentspec:tolerations:- key: node.kubernetes.io/network-unavailableoperator: Existseffect: 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

这时我们再查看版本更新的历史，如下：

kubectl rollout history daemonset fluentd-elasticsearch -n kube-system
daemonset.apps/fluentd-elasticsearch
REVISION  CHANGE-CAUSE
1         <none>
2         kubectl set image ds/fluentd-elasticsearch fluentd-elasticsearch=k8s.gcr.io/fluentd-elasticsearch:v2.2.0 --record=true --namespace=kube-system

这时我们再回滚回版本1，命令如下：

kubectl rollout undo daemonset fluentd-elasticsearch --to-revision=1 -n kube-system

这时我们再查看滚动更新的历史，已经有3这个版本了。

[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。

微信公众号，欢迎关注，共同学习进步