kubernetes使用 （七）Pod调度策略--污点和容忍

前面的nodeselector和nodeAffinity  都是pod调度到某个节点，pod属性，调度时实现

而污点是属于节点运行级的调度策略，用于限制节点上是否运行pod

一. 污点

#污点常用的值
1. NoSchedule      #这个节点一定不被调度
2. PreferNoSchedule  #尽量不被调度，类似软亲和
3. NoExecute       #不会调度，并且还会驱逐node已有的pod

 

案例一 NoSchedule （不可调度）

查看污点

[root@k8s-master01 ~]# kubectl describe node  192.168.1.20 | grep Taints:
Taints:             <none>

#我们这里使用二进制部署的集群，默认是没有污点存在的
#如果是kubeadm部署，则master节点自带污点

添加污点

kubectl taint node 192.168.1.20 env_role=yes:NoSchedule

查看

[root@k8s-master01 ~]# kubectl describe node  192.168.1.20 | grep Taints:
Taints:             env_role=yes:NoSchedule

#格式为
key=value:值
k/v都可以自定义

 添加NoSchedule污点后，节该节点不会调度pod运行

（如果该节点已经运行pod，也不会删除）

 

测试

#创建pod
kubectl create deployment web --image=nginx:1.15

#扩展副本数量为5个
kubectl scale deployment web --replicas=5


#查看pod状态
kubectl get pod -o wide

可以看到，pod就不会在192.168.1.20节点运行。

如果想要运行，删除污点后重新扩展pod即可

#删除就是在添加污点的后面加一个减号"-"
kubectl taint node 192.168.1.20 env_role=yes:NoSchedule-

#使得副本数量为0
kubectl scale deployment web --replicas=0
#重新扩展副本
kubectl scale deployment web --replicas=6

 

案例二 PreferNoSchedule（可能调度）

#清除刚才的控制器
kubectl delete deployment web

添加污点

kubectl taint node 192.168.1.20 env_role=yes:PreferNoSchedule

测试

#创建pod
kubectl create deployment web --image=nginx:1.15

#扩展副本数量为5个
kubectl scale deployment web --replicas=5


#查看pod状态
kubectl get pod -o wide

没有变化，是因为节点的pod压力太小

#继续扩展
kubectl scale deployment web --replicas=35

#这个没找到什么好的演示方法,笨办法，多加点副本数量

 

案例三 NoExecute （不可调度，并且驱除）

#删除deployment
kubectl delete deployment web

#清除节点污点
kubectl taint node 192.168.1.20 env_role=yes:PreferNoSchedule-

现在没有污点，是可以随便调度的

#创建pod
kubectl create deployment web --image=nginx:1.15

#扩展副本数量为5个
kubectl scale deployment web --replicas=5

#查看
kubectl get pod -o wide

可以看到有2个副本在20节点上运行

添加污点

kubectl taint node 192.168.1.20 env_role=yes:NoExecute

查看

pod被驱离到其他节点运行，以上就是污点的一个基本使用

但是我们有时候也会有需要让某个带了污点的节点运行，但又不方便删除再添加。

就有了这么一个东西，容忍。  我可以允许pod再污点的节点上跑一会凸(艹皿艹 )

 

 

二. 容忍

前面我们的污点还没有删除，这里直接拿过来用

#删除web控制器
kubectl delete deployment web

案例

先创建一个普通的控制器

cat > ss.yaml <<EOF
apiVersion: apps/v1
kind: Deployment
metadata:
  name: test-taint
spec:
  selector:
    matchLabels:
      app: test-taint
  replicas: 3
  template:
    metadata:
      labels:
        app: test-taint
    spec:
      containers:
      - name: nginx
        image: nginx:1.15
EOF

部署

kubectl create -f ss.yaml 

可以看到和打了污点的192.168.1.20一点关系都没有(oﾟvﾟ)ノ

添加容忍

cat > ss.yaml <<EOF
apiVersion: apps/v1
kind: Deployment
metadata:
  name: test-taint
spec:
  selector:
    matchLabels:
      app: test-taint
  replicas: 3
  template:
    metadata:
      labels:
        app: test-taint
    spec:
      containers:
      - name: nginx
        image: nginx:1.15
      tolerations:        #容忍
      - key: "env_role"       #这个是设置污点的key
        operator: "Equal"
        value: "yes"          #这个是设置污点的values
        effect: "NoExecute"  #这个是污点类型
EOF

更新yaml

kubectl apply -f ss.yaml

查看

他容忍了该类型k/v的污点的值，但是目前没有遇到过使用场景。 有碰到的朋友说明一下 谢谢~ヾ(≧▽≦*)o

 

下面摘抄一段写法

对于tolerations属性的写法：
     其中的key、value、effect 与Node的Taint设置需保持一致， 还有以下几点说明：
         1、如果operator的值是Exists，则value属性可省略。
         2、如果operator的值是Equal，则表示其key与value之间的关系是equal(等于)。
         3、如果不指定operator属性，则默认值为Equal。
    另外，还有两个特殊值：
         1、空的key 如果再配合Exists 就能匹配所有的key与value ，也是是能容忍所有node的所有Taints。
         2、空的effect 匹配所有的effect。