测试:

查看污点这里以master为例：

kubectl describe node k8s-master

从这里可以看出为什么所有的pod都不会创建在master上，就是因为有这个污点来保证的。 

接下来我们来给k8s-node1设置污点，没有污点的状态:

设置污点后的状态：

 测试yaml：

#创建20个pod
apiVersion: apps/v1
kind: Deployment
metadata:
  name: affinity-deployment
spec:
  selector:
    matchLabels:
     app: mynginx
  replicas: 20
  template:
    metadata:
      labels:
        app: mynginx
    spec:
      containers:
      - name: with-node-affinity
        image: nginx:1.17.8

 对于无法容忍这些污点的pod来说它们只能选择去 k8s-node2节点：

 我们来修改一下 这个yaml文件来让pod可以容忍这些污点：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: affinity-deployment
spec:
  selector:
    matchLabels:
     app: mynginx
  replicas: 20
  template:
    metadata:
      labels:
        app: mynginx
    spec:
      tolerations:
      - key: "taintdemo"
        operator: "Equal"
        value: "demotaint"
        effect: "NoSchedule"
      containers:
      - name: with-node-affinity
        image: nginx:1.17.8

看起来这个pod已经适应了这个污点。。。。

 我们来给node添加一些更加恶劣的污点将pod赶出node1,这里需要注意pod在被node1驱逐后会被deployment重新创建，若kind为pod类型则无法重新创建:

kubectl taint nodes k8s-node1 taint1=demo1:NoExecute

删除污点：

kubectl taint nodes k8s-node1 taintdemo:NoSchedule-

kubectl taint nodes k8s-node1 taint1:NoExecute-

 

Pod.spec.nodeName将Pod直接调度到指定的Node节点上

yaml:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: affinity-deployment
spec:
  selector:
    matchLabels:
     app: mynginx
  replicas: 20
  template:
    metadata:
      labels:
        app: mynginx
    spec:
      nodeName: k8s-node1  #固定在node1节点
      containers:
      - name: with-node-affinity
        image: nginx:1.17.8

 Pod.spec.nodeSelector:通过kubernetes的label-selector机制选择节点

首先给node打上标签：

ubectl label nodes k8s-node2  checklabel=backEnd

yaml:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: affinity-deployment
spec:
  selector:
    matchLabels:
     app: mynginx
  replicas: 10
  template:
    metadata:
      labels:
        app: mynginx
    spec:
      nodeSelector:
        checklabel: backEnd
      containers:
      - name: with-node-affinity
        image: nginx:1.17.8

 

Taint和Toleration

节点亲和性，是pod的一种属性（偏好或硬性要求），它使pod被吸引到一类特定的节点。Taint则相反，它使节点能够排斥一类特定的pod。

Taint和toleration互相配合，可以用来避免pod被分配到不合适的节点上。每个节点上都可以应用一个或多个taint,这表示对于那些不能容忍这些taint的pod，是不会被该节点接受的。如果toleration应用于pod上，则表示这些pod可以被调度到具有匹配taint的节点上。

污点（Taint）

污点的组成

使用kuberctl taint 命令可以给某的Node节点设置污点，Node被设置上污点之后就和Pod之间存在了一种相斥的关系，可以让Node拒绝Pod的调度执行，甚至将Node已经存在的Pod驱逐出去。

每个污点的组成如下：

key=value:effect

每个污点有一个key和value作为污点的标签，其中value可以为空，effect描述污点的作用。当前taint effect支持如下三个选项：

• NoSchedult:表示k8s将不会将Pod调度到具有该污点的Node上
• PreferNoSchedult:表示k8s将尽量避免将Pod调度到具有该污点的Node上
• NoExecute:表示k8s将不会将Pod调度到具有该污点的Node上，同时会将Node上已经存在的Pod驱逐出去

污点的设置、查看和去除：

设置污点：

kubectl taint nodes node1 key1=value1:NoSchedult

节点说明，查找Taints字段：

kubectl describe pod pod-name

去除污点:

kubectl taint nodes node1 key1:NoSchedult-

容忍（Tolerations）

设置了污点的Node将根据taint的effect:NoSchedult、PreferNoSchedult、NoExecute和Pod之间产生互斥的关系，Pod将在一定程度上不会被调度到Node上。但我们可以在Pod上设置容忍（Toleration），意思是设置了容忍的Pod将可以容忍污点的存在，可以被调度到存在污点的Node上。

pod.spec.tolerations

tolerations:
- key:"key1"
  operator: "Equal"
  value: "value1"
  effect: "NoSchedule"
  tolerationSeconds: 3600
- key: "key1"
  operator: "Equal"
  value: "value1"
  effect: "NoExecute"
- key: "key2"
  operator: "Exists"
  effect: "NoSchedule"

• 其中key,value,effect要于Node上设置的taint保持一致
• operator的值为Exists将会忽略value值
• tolerationSeconds用于描述当Pod需要被驱逐时可以在Pod上继续保留运行的时间

一、当不指定key值时，表示容忍所有的污点key:

tolerations:
- operator: "Exists"

二、当不指定effect值时，表示容忍所有的污点作用

tolerations:
- key: "key"
  operator: "Exists"

三、有多个Master存在时，防止资源浪费，可以如下设置:

kubectl taint nodes Node-Name node-role.kubernetes.io/master=:PreferNoSchedule

指定调度节点

一、Pod.spec.nodeName将Pod直接调度到指定的Node节点上，会跳过Scheduler的调度策略，该匹配规范是强制匹配。

二、Pod.spec.nodeSelector:通过kubernetes的label-selector机制选择节点，由调度器调度策略匹配label，而后调度Pod到目标节点，该匹配规范属于强制约束。