前言Deployment管理的Pod允许在一个节点上运行多个副本。当需要在节点上运行收集日志或执行监控任务的容器时，启动多个Pod副本显然是不合适的。在这种情况下，我们可以启用DaemonSet控制器来管理Pod。更新历史20200620-初稿-左成礼原文地址-https://blog.zuolinux.com/2020/06/20/about-controller-daemonset.htmlDaemonPod的特点Pod运行在集群的全部或部分节点上一个节点上只能有一个这样的Pod。当一个新节点加入集群时，Pod会自动在新节点上创建。当节点从集群中移除时，该节点上的Pod会自动回收。DaemonPod适用场景网络插件的代理存放插件的代理。监控任务的代理收集日志。代理DaemonSet创建一个DScatdaemonset.yamlapiVersion:apps/v1kind:DaemonSetmetadata:name:fluentd-elasticsearchnamespace:kube-systemlabels:k8s-app:fluentd-loggingspec:selector:matchLabels:name:fluentd-elasticsearchtemplate:metadata:labels:name:fluentd-elasticsearchspec:tolerations:#这个容忍度是让daemonset在主节点上运行#如果你的主节点不能运行pods就移除它-key:node-role.kubernetes.io/mastereffect:NoSchedulecontainers:-名称：fluentd-elasticsearch图片：quay.io/fluentd_elasticsearch/fluentd:v2.5.2资源：限制：内存：200Mi请求：cpu：100m内存：200MivolumeMounts：-名称：varlogmountPath：/var/log-名称：varlibdockercontainersmountPath：/var/lib/docker/containersreadOnly：trueterminationGracePeriodSeconds：30卷：-名称：varloghostPath：路径：/var/log-名称：varlibdockercontainers主机路径：路径：/var/lib/docker/containers#kubectlapply-fdaemonset.yamldaemonset.apps/fluentd-elasticsearchcreatedView[root@master01~]#kubectlgetds--namespacekube-systemNAMEDESIREDCURRENTREADYUP-TO-DATEAVAILABLENODESELECTORAGEfluentd-elasticsearch6666611m集群中目前有3个master和3个worker，一共6个节点。可以看到6个节点都是RunthenodeworkflowDaemonSetController，从Etcd中获取所有的Node列表，然后遍历所有的Node然后查看当前Node上是否运行着标签为name=fluentd-elasticsearch的Pod。检查的结果，大概有三种情况：如果Node上没有这个Pod，说明必须在这个Node上创建Pod；如果Node上有这样一个Pod，但是数量大于1，则表示从这个Node上删除了该节点多余的Pod；只有一个这样的Pod，说明这个节点是正常的。重要参数spec.affinity.nodeAffinity通过命令#kubectleditpodfluentd-elasticsearch-22g5r--namespace=kube-system可以看到DaemonSet自动添加参数spec:affinity:nodeAffinity:requiredDuringSchedulingIgnoredDuringExecution:nodeSelectorTerms:-matchFields:-key:metadata.nameoperator:Invalues:-master03限制Pod只在master03的节点上运行。通过上面的命令也可以看到容忍度。有参数公差：-效果：NoSchedule键：node-role.kubernetes.io/master-效果：NoExecute键：node.kubernetes.io/not-readyoperator：存在-效果：NoExecute键：node.kubernetes.io/unreachableoperator:Exists-effect:NoSchedulekey:node.kubernetes.io/disk-pressure表示可以容忍所有标有以下“污点”的Node，master/not-ready/unreachable/disk-pressure可以运行这些节点。一般情况下，如果Node上标记了这些“污点”，Pod就被禁止在这样的Node上运行，但是DaemonSet给Pod增加了tolerations，使得Pod可以忽略这些污点，从而使Pod可以成功调度到“受污染”的节点。如果节点故障导致Pod启动失败，DaemonSet会一直尝试直到Pod启动成功可以在YAML中手动指定.spec.template.spec.affinity，这样Pod就会运行在指定的Node上如果不指定此参数，则Pod将在所有节点上运行。DaemonSet的好处是我们也可以写一个守护进程来完成类似的工作。使用DaemonSetPod有什么好处？DaemonSetPod自带了监控功能，省去了我们为daemon进程编写监控程序的工作。DaemonSetPod无论运行什么任务，都有统一的语言和管理方式。DaemonSetPod自带资源限制功能，避免守护进程长时间运行。过多的资源对主机有影响。结论DaemonSet倾向于精确控制Pod运行在哪些机器上，确保Pod运行在所有这些机器上。Deployment更适合管理离用户更近的无状态Pod，比如web服务。他们的共同点是，他们不希望他们管理的Pod终止，并且Pod可以在出现问题后自行修复。联系我微信公众号：zuolinux_com
