最近在kubernetes部署一个springcloud微服务项目，到了最后一步部署边缘路由：使用nginx-ingress和traefik都可以，必须使用DaemonSet部署，但是发现三个节点，却总共只有两个pod。
换句话说， DaemonSet没法调度到master节点上。
要理解这种情况，就必须理解kubernets中pod的污点和容忍度的问题
什么是污点（taint）和容忍度（toleration）
"污点"是Kubernetes节点的一个属性，字段名为taint，它的含义说的直白点，就是表明这个节点"不干净"
和"污点"相对应的，就是Pod的"容忍度"，顾名思义，就是Pod能否"容忍"污点。
打个形象的比喻：集群里的节点各式各样，有的节点"纯洁无瑕"，没有"污点"；而有的节点因为某种原因粘上了"泥巴"，也就有了"污点"。Pod也脾气各异，有的"洁癖"很严重，不能容忍"污点"，只能挑选"干净"的节点；而有的Pod则比较"大大咧咧"，要求不那么高，可以适当地容忍一些小"污点"。
这么看来，"污点"和"容忍度"倒是有点像是一个"相亲"的过程。Pod就是一个挑剔的"甲方"，而"乙方"就是集群里的各个节点，Pod会根据自己对"污点"的"容忍程度"来选择合适的目标，比如要求"不抽烟不喝酒"，但可以"无车无房"，最终决定在哪个节点上"落户"。
Kubernetes在创建集群的时候会自动给节点Node加上一些"污点"，方便Pod的调度和部署。
如下面Master和Node节点的状态：
root@k8s-node2 vhost# kubectl get nodes
NAME STATUS ROLES AGE VERSION
k8s-master Ready master 3y292d v1.17.2
k8s-node1 Ready <none> 4d5h v1.17.2
k8s-node2 Ready <none> 3y292d v1.17.2
root@k8s-node2 vhost# kubectl describe node k8s-master|grep Taints
Taints: node-role.kubernetes.io/master:NoSchedule
root@k8s-node2 vhost# kubectl describe node k8s-node1|grep Taints
Taints: <none>
root@k8s-node2 vhost# kubectl describe node k8s-node2|grep Taints
Taints: <none>
可以看到，Master节点默认有一个**taint污点** ，名字是 node-role.kubernetes.io/master，它的效果是 NoSchedule，也就是说这个污点会拒绝Pod调度到本节点上运行，而node节点的 taint 字段则是空的。
这正是Master和node在Pod调度策略上的区别所在，通常来说Pod都不能容忍任何"污点"，所以加上了 taint 属性的Master节点被认为是有污点，pod默认不会调度到该节点。
这个也很好理解： 由于master节点具有一定的特殊性，出于安全及角色的原因，一般不建议在Master节点部署应用的Pod实例， 因为Master 节点主要运行集群管理组件和控制面等关键组件。
那么怎么解决这个问题，让pod能调度到master节点： 引入toleration，允许容忍这个污点
具体来说，就是在pod定义yml文件中跟container容器的同级字段加入下面的配置：
tolerations:
effect: NoSchedule
operator: Exists
它的定义位置或者可以说在这里：daemonSet定义的spec.template.spec下
解释一下它们的含义：
key: node-role.kubernetes.io/master： key表示tolerations能容忍的节点标记,这里就是指能容忍的节点类型是master节点
effect: NoSchedule： effect表示taint污点标记产生的效果，**NoSchedule是指**告诉调度器，不允许调度到带有这个 taint 污点标识的节点上，除非 Pod 显式容忍（tolerate）这个 taint，
operator: Exists： 表示只容忍key指定类型的节点。在这个例子中，Pod 只要运行在带有node-role.kubernetes.io/mastertaint 的节点上，就能够被容忍。
配置在yml文件中的具体情形：
定义了容忍污点以后，pod果然可以调度到master节点了：
