解决DaemonSet没法调度到master节点的问题

最近在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:

- key: node-role.kubernetes.io/master

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/master taint 的节点上，就能够被容忍。