当前位置:   article > 正文

云原生之Kubernetes:24、污点和容忍度详解_prefernoschedule

prefernoschedule

前言

Taint(污点)和Toleration(容忍度)可以作用于node和pod上,其目的是优化pod在集群间的调度,这跟节点亲和性类似;

只不过它们作用的方式相反,其用作确保pod不会被调度在指定的节点上。

1、概念引入

在这里插入图片描述
如图所示,node节点上分别有云、五角星、十字架这三个不同组合的污点;Pod-A上有云和五角星的污点容忍度,Pod—B上则没有容忍度。

最终调度结果为:

1、Pod-A:调度至node-1和node-3
2、Pod-B:只会调度至node-3

注意:Taints(污点)存在于node,Tolerations(容忍度)存在于pod

2、污点和容忍度配置

污点的容忍度配置主要有三个字段:key、value和effect,其中:

1、key:表示字段名,如图形
2、value:表示字段值,如云、五角星、十字架
3、effect:表示调度规则,其又细分:Noschedule、PreferNoSchedule和NoExecute三种

具体描述可参考下面的表格:

参数描述
keystring类型,最大长度253个字符,必须小写或数字开头
valuestring类型,最大长度63个字符,必须小写或数字开头
effect:Noschedule1.不允许非法pod调度上来。2.taints变更后,不会驱离非法的pod
effect:PreferNoSchedule1.最好不要把非法pod调度上来。2.taints变更后,不会驱离非法的pod
effect:NoExecute1.不允许非法pod调度上来。2.taints变更后,会驱离非法的pod,驱离时间为tolerationSeconds

3、该如何配置?

就如我上面所说,无论是Taints还是Tolerations(污点和容忍度),都有三个字段:key、value和effect,那么他们是如何匹配工作的呢?

此时会用到一个判断控制器operator,具体匹配规则如下:

operator描述
Equal(默认) key、value和effect必须都相同
Existskey和effect必须相同

需要注意operator没指定的话,默认是Equal。

另外,这里还有两个特殊用法:

tolerations:
- operator: "Exists"
  • 1
  • 2

1、Exists:空字段key,会匹配所有的keys, values and effects,意味着容忍所有

tolerations:
- key: "key"
  operator: "Exists"
  • 1
  • 2
  • 3

2、Exists:空effect,会匹配所有的键为"key"的effect

4、内置污点

从K8S1.6开始支持了很多封装好的驱离式effect,node controller会根据实际情况,自动给node节点打上对应污点,保证了Pod调度的合理性和安全性,从而对生产环境保驾护航。

具体如下所示:

taint effect描述
node.kubernetes.io/not-ready节点未就绪
node.kubernetes.io/unreachable节点不可达
node.kubernetes.io/out-of-disk节点地盘耗尽
node.kubernetes.io/memory-pressure内存存在压力
node.kubernetes.io/disk-pressure磁盘存在压力
node.kubernetes.io/network-unavailable网络不可用
node.kubernetes.io/unschedulable节点不可调度
node.cloudprovider.kubernetes.io/uninitialized节点未初始化,不可用

试想一下,如果没有这些内置的effect帮助会怎么样呢?

如果节点还未就绪,就有pod调度上来,又比如节点的硬盘资源已经满了,pod再调度上来?等等;
这是不是很不合理,也很可怕呢?

5、常用命令补充

命令说明
kubectl taint -htaint的帮助命令
kubectl taint nodes foo dedicated=special-user:NoSchedule给node打污点,修改时需要使用–overwrite=true进行覆盖
kubectl taint nodes foo dedicated:NoSchedule-移除taint污点

6、实战:Taints and Tolerations

1、首先给centos-3这个节点打上污点,其key=department,value=ops,effect=NoSchedule

kubectl taint nodes centos-3.shared department=ops:NoSchedule
  • 1

NoSchedule的策略:
1、不允许非法pod调度上来。
2、taints变更后,不会驱离非法的pod。

2、接着,我们编辑filebeat-ds,并apply

注意:这时候的ds应该不会调度至我们打了污点的centos-3.shared节点上。
  • 1
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: filebeat-ds
  labels:
    app: filebeat
spec:
  selector:
    matchLabels:
      app: filebeat
  template:
    metadata:
      labels:
        app: filebeat
    spec:
      containers:
      - name: filebeat
        image:  prima/filebeat:6.4.2
        env:
        - name: REDIS_HOST
          value: db.ikubernetes.is:6379
        - name: LOG_LEVEL
          value: info
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23

3、发现ds并没有部署到centos-3节点,污点配置生效,且和预期一致

[root@centos-1]# kubectl get pod -o wide
NAME                     READY   STATUS              RESTARTS   AGE    IP           NODE              NOMINATED NODE   READINESS GATES
filebeat-ds-tg7gf        0/1     ContainerCreating   0          3m2s   <none>       centos-2.shared   <none>           <none>
  • 1
  • 2
  • 3

4、接着,我们delete之前的yaml,重新编辑file-ds-tolerations.yaml(增加相关容忍度,希望能容忍centos-3.shared节点的污点),并apply

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: filebeat-ds
  labels:
    app: filebeat
spec:
  selector:
    matchLabels:
      app: filebeat
  template:
    metadata:
      labels:
        app: filebeat
    spec:
      containers:
      - name: filebeat
        image:  prima/filebeat:6.4.2
        env:
        - name: REDIS_HOST
          value: test.db:6379
        - name: LOG_LEVEL
          value: info
      tolerations:
      - key: "department"
        operator: "Equal"
        value: "ops"
        effect: "NoSchedule"
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28

5、观察pod,发现centos-3.shared已经运行pod,新增的容忍度功能成功

[root@centos-1]# kubectl get pod -o wide
NAME                     READY   STATUS              RESTARTS   AGE     IP           NODE              NOMINATED NODE   READINESS GATES
filebeat-ds-l2png        0/1     ContainerCreating   0          2m43s   <none>       centos-2.shared   <none>           <none>
filebeat-ds-qq2nc        0/1     ContainerCreating   0          2m43s   <none>       centos-3.shared   <none>           <none>
  • 1
  • 2
  • 3
  • 4

6、接下来我们修改node3污点,测试Noschedule策略是否如期一致,是否会在taints变更后,不会驱离非法的pod?

kubectl taint nodes centos-3.shared department=test:NoSchedule --overwrite=true
  • 1

7、我们发现pod还是在运行,并不会驱离,和预期一致

[root@centos-1]# kubectl get pod -o wide
NAME                     READY   STATUS              RESTARTS   AGE     IP           NODE              NOMINATED NODE   READINESS GATES
filebeat-ds-l2png        0/1     ContainerCreating   0          5m18s   <none>       centos-2.shared   <none>           <none>
filebeat-ds-qq2nc        0/1     ContainerCreating   0          5m18s   <none>       centos-3.shared   <none>           <none>
  • 1
  • 2
  • 3
  • 4

8、最后,我们将node3的污点effect修改为NoExecute,观察pod是否被驱离

如果没指定tolerationSeconds,就会马上驱离
  • 1
kubectl taint nodes centos-3.shared department=test:NoExecute --overwrite=true
  • 1

9、发现centos-3.shared上已经没有pod了,和预期一致

[root@centos-1]# kubectl get pod -o wide
NAME                     READY   STATUS             RESTARTS   AGE     IP           NODE              NOMINATED NODE   READINESS GATES
filebeat-ds-l2png        0/1     ImagePullBackOff   0          7m37s   10.244.1.7   centos-2.shared   <none>           <none>
  • 1
  • 2
  • 3
声明:本文内容由网友自发贡献,不代表【wpsshop博客】立场,版权归原作者所有,本站不承担相应法律责任。如您发现有侵权的内容,请联系我们。转载请注明出处:https://www.wpsshop.cn/w/笔触狂放9/article/detail/563708
推荐阅读
相关标签
  

闽ICP备14008679号