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-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中,如下图:
kubernete编排技术五(DaemonSet)
文章图片

创建、升级和回滚 执行下面命令,创建Daemon Pod
kubectl apply -f daemonset.yaml

过几分钟查看pods,如下:
[root@master k8s]# kubectl get pod -n kube-system -l name=fluentd-elasticsearch NAMEREADYSTATUSRESTARTSAGE fluentd-elasticsearch-5mgqr1/1Running0147m fluentd-elasticsearch-6nwlp1/1Running0147m

可以看到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 REVISIONCHANGE-CAUSE 1 2kubectl 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 REVISIONCHANGE-CAUSE 2kubectl set image ds/fluentd-elasticsearch fluentd-elasticsearch=k8s.gcr.io/fluentd-elasticsearch:v2.2.0 --record=true --namespace=kube-system 3

总结DaemonSet的调度策略其实是在创建Daemon pod时给这个Pod加上一个nodeAffinity,从而保证这个Pod能够在指定节点上启动。通过给这个Pod加上一个 Toleration,从而保证pod能在有Taints限制的节点上创建。
DaemonSet的升级和回滚策略跟Deployment非常相似,不同的是,它管理版本用的是ControllerRevision对象。
一般情况下,Daemon Pod跟普通的pod功能一样,但是如果给守护进程做程序配置、监控和日志收集,使用DaemonSet更合适一些。有时候我们要指定一些节点创建pod,也可以使用DaemonSet。
【kubernete编排技术五(DaemonSet)】
微信公众号,欢迎关注,共同学习进步
kubernete编排技术五(DaemonSet)
文章图片


    推荐阅读