当前位置： 首页 > news >正文

Kubernetes的Taint污点和Toleration容忍

news 来源：原创 2024/9/20 19:37:51

 一、Taint 和Toleration

在生产环境中，经常会有这样的需求:

  • master 节点只部署系统组件容器，比如Calico、Metrics Server、Dashboard 等，不应该部署业务应用。
  • 新添加节点不应该立即就允许部署业务容器，也就是新节点需要经过完整性及稳定性测试才可以被允许调度。
  • 某些节点可能需要进行系统升级或者其他维护，可能会引起节点上的容器不可用，此时需要将该节点上的 Pod 漂移至其他节点，再进行维护。
  • 有一些 GPU 服务器或其他专用节点服务器,除了指定的 Pod 之外,并不想让他们部署其他的 Pod。

        面对这样的需求，Kubernetes 抽象了污点(Taint)和容忍(Toleration)的概念，可以非常方便的实现这些需求。

1.污点和容忍的基本概念

        Taint(污点)作用在节点上，能够使节点排斥一类特定的 Pod.
        Toleration(容忍)作用在 Pod 上，也就是可以兼容某类污点。

        比如有一批 GPU 服务器只能部署要使用 GPU的 Pod。每个节点上都可以应用一个或多个 Taint，这表示对于那些不能容忍这些 Taint 的 Pod 是不能部署在该服务器上的。如果 Pod 配置了 Toleration,则表示这些 Pod 可以被调度到设置了 Taint 的节点上，当然没有设置 Taint 的节点也是可以部署的。
        Taint(污点)和 Toleration(容忍)可以作用于 node 和 pod 上，其目的是优化 pod 在集群间的调度，这跟节点亲和性类似，只不过它们作用的方式相反，具有 taint 的 node 和 pod 是互斥关系，而具有节点亲和性关系的 node 和 pod 是相吸的。另外还有可以给 node 节点设置 label，通过给 pod 设置nodeselector 将 pod 调度到具有匹配标签的节点上:
        Taint 和 Toleration 相互配合,可以用来避免 Pod 被分配到不合适的节点上。每个节点上都可以应用一个或多个 taint ，这表示对于那些不能容忍这些 taint 的 Pod，是不会被该节点接受的。如果将 toleration 应用于 Pod 上，则表示这些 Pod 可以(但不一定)被调度到具有匹配 taint 的节点上。

 2.污点的使用

        如果一个节点被标记为有污点，那么意味着不允许 pod 调度到该节点，除非 pod 也被标记为可以容忍污点节点。
        在使用 kubeadm 部署的 k8s 集群的时候应该会发现,通常情况下,应用是不会调度到 master 节点的。因为 kubeadm 部署的 k8s 集群默认给 master 节点加了 Taints(污点)。
        给节点 node01 增加一个污点，它的键名是 key1，键值是 value1，效果是 NoSchedule。 这表示只有拥有和这个污点相匹配的容忍度的 Pod 才能够被分配到 node1 这个节点。

[root@master ~]# ku taint nodes node1 key1=value1:NoSchedule

查看节点是否为污点:

[root@master ~]# ku describe node node1 | grep Taint
Taints:             key1=value1:NoSchedule

若要移除上述命令所添加的污点，在后面加一个横杠即可，可以执行:

[root@master ~]# ku taint nodes node1 key1=value1:NoSchedule-
node/node1 untainted

        每个污点有一个 key 和 value 作为污点的标签，其中 value 可以为空，effect 描述污点的作用
key=value:effect

当前 taint effect 支持如下三个选项:

  • NoSchedule :表示 k8s 将不会将 Pod 调度到具有该污点的 Node 上 ，不会驱逐已存在该节点上的 Pod。
  • PreferNoSchedule : 表示 k8s 将尽量避免将 Pod 调度到具有该污点的 Node 上 ，不会驱逐已存在该节点上的 Pod.
  • NoExecute :表示 k8s 将不会将 Pod 调度到具有该污点的 Node 上，同时会将 Node 上已经存在的 Pod 驱逐出去，若节点上设置了污点并用的是 NoExecute 策略，node 节点上的 pod 会被全部驱逐，但是如果是 Deployment 或者 statefulset 资源类型，为了维持副本数量则会在别的Node 上再创建新的 Pod。

3.容忍的定义

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

4.示例

(1)设置污点
[root@master ~]# ku taint node node1 check=mycheck:NoExecute
node/node1 tainted
[root@master ~]# ku taint node node2 check=mycheck:NoExecute
node/node2 tainted
(2)创建测试模版 
[root@master ~]# vim pod1.yaml apiVersion: v1
kind: Pod
metadata:name: myapp01labels:app: myapp01
spec:containers:- name: with-node-affinityimage: nginx:1.7.9
 (3)运行
[root@master ~]# ku create -f pod1.yaml 
pod/myapp01 created
 (4)在两个Node上都设置了污点后，此时Pod将无法创建成功
[root@master ~]# ku get pod
NAME      READY   STATUS    RESTARTS   AGE
myapp01   0/1     Pending   0          4s
[root@master ~]# ku get pod -o wide
NAME      READY   STATUS    RESTARTS   AGE   IP       NODE     NOMINATED NODE   READINESS GATES
myapp01   0/1     Pending   0          10s   <none>   <none>   <none>           <none>
[root@master ~]# ku delete -f pod1.yaml 
pod "myapp01" deleted
(5)修改测试模版

在pod1.yaml的基础上增加容忍度参数

[root@master ~]# vim pod2.yaml apiVersion: v1
kind: Pod
metadata:name: myapp01labels:app: myapp01
spec:containers:- name: with-node-affinityimage: nginx:1.7.9tolerations:- key: checkoperator: Equalvalue: mycheckeffect: NoExecutetolerationSeconds: 60

备注:
tolerationSeconds 用于描述当 Pod 需要被驱逐时可以在 Node 上继续保留运行的时间,即 60 秒后该pod 会被驱逐掉，默认的是一天。

 (6)在 pod 中定义容忍度的说明

        可以在 Podspec 中定义 Pod 的容忍度。 下面两个容忍度均与上面例子中使用 kubectl taint 命令创建的污点相匹配， 因此如果一个 Pod 拥有其中的任何一个容忍度都能够被分配到 k8s-node01:

tolerations:
- key: checkoperator:Equalvalue: mycheckeffect:NoExecutetolerationSeconds:60
tolerations:
- key: checkoperator:"Existseffect: NoExecute

 #其中的 key、vaule、effect 都要与 Node 上设置的 taint 保持一致

#operator 的值为 xists 将会忽略 value 值，即存在即可，为 Equal 时需要指定污点的 value。

#value:mycheck污点的 check 名称，指明需要容忍的污点

#effect: NoExecute驱逐行为，设置了 tolerationseconds，就按照其设定的时间后驱逐 Pod

#tolerationseconds 用于描述当 Pod 需要被驱逐时可以在 Node 上继续保留运行的时间，即 68 秒后该 pod 会被驱逐掉，默认的是一天。

(7)运行新的 pod
[root@master ~]# ku apply -f pod2.yaml 
pod/myapp01 created
 (8)在设置了容忍之后，Pod创建成功
root@master ~]# ku get pods -o wide
NAME      READY   STATUS    RESTARTS   AGE     IP              NODE    NOMINATED NODE   READINESS GATES
myapp01   1/1     Running   0          3m10s   10.244.104.12   node2   <none>           <none>

注意：

完成此实验后，将污点取消

[root@master ~]# ku taint node node1 check=check:NoExecute-
node/node1 untainted
[root@master ~]# ku taint node node2 check=check:NoExecute-
node/node2 untainted

5.容忍的基本用法

(1)容忍污点的条件

pod 的 Toleration 声明中的 key 和 effect 需要与 Taint 的设置保持一致,并且满足以下条件之一:#不完全匹配，operator 的值为 Exists，这时无需指定 value

tolerations:
- key:checkoperator:"Exists'effect: NoExecute

# 完全匹配，operator 的值为 Equal 并且 value 相等(可以设置多个 tolerations)

tolerations:
- key: checkoperator:Equalvalue: mycheckeffect:NoExecute

# 如果不指定 operator，则默认值为 Equal

tolerations:
- key:checkvalue: mycheckeffect: NoExecute
 (2)另外还有如下两个特例:

# 空的 key 、value、effect 配合 Exists 操作符能够匹配所有的键和值，即能容忍所有污点。

tolerations:operator:"Exists"

#空的 effect 匹配所有的 effect，即能容忍任何 key 名为 check 的污点。

tolerations:
- key: checkoperator:"Exists'
 (3)effect 的取值说明:
  • NoSchedule:如果一个 pod 没有声明容忍这个 Taint，则系统不会把该 Pod 调度到有这个Taint 的 node 上
  • PreferNoschedule:Noschedule 的软限制版本，如果一个 Pod 没有声明容忍这个 Taint,则系统会尽量避免把这个 pod 调度到这一节点上去，但不是强制的
  • NoExecute:定义 pod 的驱逐行为，以应对节点故障
(4)NoExecute 这个 Taint 效果对节点上正在运行的 pod 有以下影响:
  • 没有设置 Toleration 的 Pod 会被立刻驱逐
  • 配置了对应 Toleration 的 pod，如果没有为 tolerationseconds 赋值，则会一直留在这一节点中
  • 配置了对应 Toleration 的 pod 且指定了 tolerationseconds 值，则会在指定时间后驱逐
(5)一些特殊的设置

#有多个 Master 存在时，为了防止资源浪费，可以将 master 节点设置为 PreferNoschedule 污点，让Pod 可在 Master 上临时创建:
kubectl taint node k8s-master node-role.kubernetes.io/master=:PreferNoschedule


#如果某个 Node 更新升级系统组件，为了防止业务长时间中断，可以先在该 Node 设置 NoExecute 污点，把该 Node 上的 Pod 都驱逐出去
kubectl taint node k8s-node01 check=mycheck:NoExecute


#此时如果别的 Node 资源不够用，可临时给 Master 设置 PreferNoschedule 污点，让 Pod 可在Master 上临时创建
kubectl taint node k8s-master node-role,kubernetes,io/master=:PreferNoschedule

#待所有 Node 的更新操作都完成后，再去除污点
kubectl taint node node01 check=mycheck:NoExecute-

6.多污点与多容忍配置

        系统允许在同一个 node 上设置多个 taint，也可以在 pod 上设置多个 Toleration

        Kubernetes 调度器处理多个 Taint 和 Toleration 能够匹配的部分，剩下的没有忽略掉的Taint 就是对 Pod 的效果了。下面是几种特殊情况

  • 如果剩余的 Taint 中存在 effect=NoSchedule，则调度器不会把该 pod 调度到这一节点上。
  • 如果剩余的 Taint 中没有 NoSchedule 的效果，但是有 PreferNoschedule 效果，则调度器会尝试不会将 pod 指派给这个节点。
  • 如果剩余 Taint 的效果有 NoExecute 的，并且这个 pod 已经在该节点运行，则会被驱逐;如果没有在该节点运行，也不会再被调度到该节点上。
kubectl taint nodes k8s-node01 key1=value1:NoSchedule
kubectl taint nodes k8s-node01 key1=value1:NoExecute
kubectl taint nodes k8s-node01 key2=value2:NoSchedule

去除污点：

kubectl taint nodes k8s-node01 key1=value1:NoSchedule-
kubectl taint nodes k8s-node01 key1=value1:NoExecute-
kubectl taint nodes k8s-node01 key2=value2:Noschedule-

7.警戒(cordon)和 转移(drain)

(1)设置警戒

警戒是指将 Node 标记为不可调度的状态
这样就不会让新创建的 Pod 在此 Node 上运行，命令如下

[root@master ~]# ku cordon node1
node/node1 cordoned

该 node 将会变为SchedulingDisabled 状态

[root@master ~]# ku get node
NAME     STATUS                     ROLES                  AGE   VERSION
master   Ready                      control-plane,master   8d    v1.23.0
node1    Ready,SchedulingDisabled   <none>                 8d    v1.23.0
node2    Ready                      <none>                 8d    v1.23.0
 (2)kubectl uncordon将Node标记为可调度的状态
[root@master ~]# ku uncordon node1
node/node1 uncordoned
[root@master ~]# ku get node
NAME     STATUS   ROLES                  AGE   VERSION
master   Ready    control-plane,master   8d    v1.23.0
node1    Ready    <none>                 8d    v1.23.0
node2    Ready    <none>                 8d    v1.23.0
 (3)驱逐（转移）pod

kubectl drain 可以让 Node 节点开始释放所有 pod，并且不接收新的 pod 进程。drain 本意排水,意思是将出问题的 Node 下的 Pod 转移到其它 Node 下运行

[root@master ~]# ku drain node1 --ignore-daemonsets --delete-local-data --force
Flag --delete-local-data has been deprecated, This option is deprecated and will be deleted. Use --delete-emptydir-data.
node/node1 cordoned
WARNING: ignoring DaemonSet-managed Pods: kube-system/calico-node-qf8r4, kube-system/kube-proxy-8lzdr
evicting pod kube-system/metrics-server-66bdc46d86-5xgwh
pod/metrics-server-66bdc46d86-5xgwh evicted
node/node1 drained

执行 drain 命令，会自动做了两件事情:

  • 设定此 node 为不可调度状态(cordon)
  • evict(驱逐)了 Pod 

备注:
-ignore-daemonsets:无视 Daemonset 管理下的Pod

-delete-local-data:如果有 mount local volume 的 pod，会强制杀掉该 pod

-force:强制释放不是控制器管理的 Pod，例如 kube-proxy

注意:
实验完成后，将节点设置为可调度
kubectl uncordon k8s-node01

五、K8s 亲和性和非亲和性

        关于 K8S 对 Pod 的调度，通常情况下 Pod 被分配到哪些 Node 是不需要我们操心的，这个过程会由scheduler 自动实现。但有时，我们需要让 Pod 按照我们的预想运行在 Node 上(例如某些应用“必须或者尽量”跑在具有 SSD 存储的节点上，有些彼此相关的 Pod 应用应该跑在同一个节点上)。为此，k8s为我们提供了这样的策略，我们可以通过使用“亲和性/非亲和性”制定一些规则来实现我们的需求。

1.亲和性调度可以分成软策略和硬策略两种方式

  • 硬策略:可以理解为必须，就是如果没有满足条件的节点的话，就不断重试直到满足条件为止。对应的配置规则为 requiredDuringSchedulingIgnoredDuringExecution。
  • 软策略:可以理解为尽量，就是如果现在没有满足调度要求的节点的话，pod 就会忽略这条规则继续完成调度的过程，说白了就是满足条件最好了，没有的话也无所谓。对应的配置规则为preferredDuringSchedulingIgnoredDuringExecution.

2.亲和性的配置规则

分为 Node 亲和性、Pod 亲和性、Pod 反亲和性

  • nodeAffinity :节点亲和性，用来控制 Pod 要部署在哪些节点上，以及不能部署在哪些节点上的，这个是 Pod 与 Node 之间匹配规则的。
  • podAffinity : pod 亲和性，这个是 Pod 与 Pod 之间匹配规则的。
  • podAntiAffinity :pod 反亲和性，与 podAffinity 相反，用来指定 Pod 不要部署到哪些节点上

 3.节点硬亲和性

        节点的亲和性可以通过 pod.spec.affinity.nodeAffinity 字段定义，nodeAffinity 字段中支持使用 matchExpressions 属性构建更为复杂的标签选择器。

(1)设置节点标签

首先对两个 node 加标签，设置两个 node 标签分别为 node1 和 node2 。加标签的语法如下。kubectl label nodes <node-name><label-key>=<label-value>

[root@master ~]# ku label nodes node1 type=node01
node/node1 labeled
[root@master ~]# ku label nodes node2 type=node02
node/node2 labeled

 备注:
如果需要重命名 node 标签，可以使用如下命令:

[root@k8s-master ~]# kubectl label nodes k8s-node01 type=node1 --overwrite

如果要删除 node 标签(标签名为“type”)，可以使用如下命令:

[root@k8s-master ~l# kubectl label node k8s-node01 type-
 (2)查看节点标签
[root@master ~]# ku get node --show-labels
NAME     STATUS   ROLES                  AGE   VERSION   LABELS
master   Ready    control-plane,master   9d    v1.23.0   beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/arch=amd64,kubernetes.io/hostname=master,kubernetes.io/os=linux,node-role.kubernetes.io/control-plane=,node-role.kubernetes.io/master=,node.kubernetes.io/exclude-from-external-load-balancers=
node1    Ready    <none>                 9d    v1.23.0   beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/arch=amd64,kubernetes.io/hostname=node1,kubernetes.io/os=linux,type=node01
node2    Ready    <none>                 9d    v1.23.0   beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/arch=amd64,kubernetes.io/hostname=node2,kubernetes.io/os=linux,type=node02
 (3)设置 pod 亲和性为 type=node1
[root@master ~]# vim test01.yaml apiVersion: v1
kind: Pod
metadata:name: pod01
spec:affinity:nodeAffinity:requiredDuringSchedulingIgnoredDuringExecution:nodeSelectorTerms:- matchExpressions:- {key: type, operator: In, values: ["node01"]}containers:- name: pod01image: nginx:1.7.9

备注:
values:["node01"] node1 为节点的标签，该 pod 要调度到标签为 node1 的节点，即 k8s-node01。 

(4)部署 pod 并查看其信息
[root@k8s-master ~]# kubectl apply -f test01.yaml
[root@k8s-master ~]# kubectl get pod pod01 -o wide
NAME    READY   STATUS    RESTARTS   AGE   IP               NODE    NOMINATED NODE   READINESS GATES
pod01   1/1     Running   0          14s   10.244.166.135   node1   <none>           <none>
(5)设置 pod 亲和性为 type=node02
[root@master ~]# vim test02.yaml 
# 定义一个 pod 资源清单，将该 pod 调度至有标签为 type=node02 的节点上
apiVersion: v1
kind: Pod
metadata:name: pod02
spec:#亲和性调度affinity:#节点亲和性调度nodeAffinity:# 硬策略requiredDuringSchedulingIgnoredDuringExecution:#指定亲和性nodeSelectorTerms:- matchExpressions:- {key: type, operator: In, values: ["node02"]}containers:- name: pod02image: nginx:1.7.9

备注:
values:["node02"] node82 为节点的标签，该 pod 要调度到标签为 node02 的节点，即 k8s-node02。 

(6)部署 pod 并查看其信息
[root@k8s-master ~]# kubectl apply -f test02.yaml
[root@k8s-master ~]# kubectl get pod pod02 -o wide
[root@master ~]# ku get pod pod02 -o wide
NAME    READY   STATUS    RESTARTS   AGE   IP             NODE    NOMINATED NODE   READINESS GATES
pod02   1/1     Running   0          4s    10.244.104.7   node2   <none>           <none>

4. 节点软亲和性

        节点软亲和性为节点选择提供了一种柔性的控制器逻辑，当条件不满足时，也能够接受被编排在其他不符合条件的节点之上。同时他还为每种倾向性提供了 weight 属性以便用于自定义优先级，范围是1-100，越大越优先。

(1)为 pod 设置软亲和性
[root@master ~]# vim test03.yaml apiVersion: v1
kind: Pod
metadata:name: pod03
spec:#亲和性调度affinity:#节点亲和性调度nodeAffinity:# 软策略preferredDuringSchedulingIgnoredDuringExecution:#指定亲和性及权重- weight: 60preference:matchExpressions:- {key: type, operator: In, values: ["node02"]}- weight: 90preference:matchExpressions:- {key: tpye, operator: In, values: ["node01"]}containers:- name: pod03image: nginx:1.7.9
 (2)部署pod并查看其信息
[root@k8s-master ~]# kubectl apply -f test03.yaml
[root@k8s-master ~]# kubectl get pod pod03 -o wide
NAME    READY   STATUS    RESTARTS   AGE   IP             NODE    NOMINATED NODE   READINESS GATES
pod03   1/1     Running   0          5s    10.244.104.8   node2   <none>           <none>

 可以看到，由于 Pod 对 node01 的亲和性，被部署到了 node01 上。
注意:
node 软亲和中的权重值不影响 pod 的调度，谁在前面，就亲和谁。
pod 软亲和中的权重值是会影响调度到的节点的，pod 软亲和中谁的权重高就调度到谁那里。

5.Pod硬亲和度

        出于某些需求，将一些 Pod 对象组织在相近的位置(同一节点、机架、区域等)，此时这些 pod 对象间的关系为 pod 亲和性。
        Pod 的亲和性调度也存在硬亲和性和软亲和性的区别，他们表示的约束意义同节点亲和性相似。
        Pod 硬亲和性调度也使用 requiredDuringSchedulingIgnoreDuringExecution 属性进行定义。
        首先创建两个基础 Pod，并对它打标签，分别部署到 node01 和 node02 上。

(1)部署第一个基础 Pod
[root@master ~]# vim test04.yaml apiVersion: v1
kind: Pod
metadata:name: pod04labels:app: pod04
spec:affinity:nodeAffinity:requiredDuringSchedulingIgnoredDuringExecution:nodeSelectorTerms:- matchExpressions:- {key: type, operator: In, values: ["node01"]}containers:- name: pod04image: nginx:1.7.9

注意:
pod04 的标签是 pod04，所在的节点标签是 node01

(2)部署并查看其信息
[root@k8s-master ~]# kubectl apply -f test04.yaml
[root@k8s-master ~]# kubectl get pod pod04 -o wide
NAME    READY   STATUS    RESTARTS   AGE   IP               NODE    NOMINATED NODE   READINESS GATES
pod04   1/1     Running   0          5s    10.244.166.136   node1   <none>           <none>
 (3)部署第二个Pod
[root@master ~]# vim test05.yaml apiVersion: v1
kind: Pod
metadata:name: pod05labels:app: pod05
spec:affinity:nodeAffinity:requiredDuringSchedulingIgnoredDuringExecution:nodeSelectorTerms:- matchExpressions:- {key: type, operator: In, values: ["node02"]}containers:- name: pod05image: nginx:1.7.9

注意:
pod05 的标签是 poda5，所在的节点标签是 node02

 (4)部署并查看其信息
[root@k8s-master ~]# kubectl apply -f test05.yaml
[root@k8s-master ~]# kubectl get pod pod05 -o wide
NAME    READY   STATUS    RESTARTS   AGE   IP             NODE    NOMINATED NODE   READINESS GATES
pod05   1/1     Running   0          5s    10.244.104.9   node2   <none>           <none>

可以看到，一个位于 node01，一个位于 node02。 

(5)创建一个亲和 poda5 的 pod
[root@master ~]# vim test06.yaml apiVersion: v1
kind: Pod
metadata:name: pod06
spec:affinity:podAffinity:requiredDuringSchedulingIgnoredDuringExecution:- labelSelector:matchExpressions:- {key: app, operator: In, values: ["pod05"]}topologyKey: kubernetes.io/hostnamecontainers:- name: pod06image: nginx:1.7.9

 注意:
matchExpressions 的 values 值为 pod 的标签。是哪个 pod 的标签，就亲和到哪个 pod 所在的 node 节点
pod04 的标签是 pod85，所在的节点标签是 node01

pod05 的标签是 pod05，所在的节点标签是 node02

(6)部署此 pod
[root@k8s-master ~]# kubectl create -f test06.yaml
[root@k8s-master ~]# kubectl get pod -o wide
NAME    READY   STATUS    RESTARTS   AGE     IP               NODE    NOMINATED NODE   READINESS GATES
pod01   1/1     Running   0          5m22s   10.244.166.135   node1   <none>           <none>
pod02   1/1     Running   0          2m39s   10.244.104.7     node2   <none>           <none>
pod03   1/1     Running   0          2m16s   10.244.104.8     node2   <none>           <none>
pod04   1/1     Running   0          104s    10.244.166.136   node1   <none>           <none>
pod05   1/1     Running   0          80s     10.244.104.9     node2   <none>           <none>
pod06   1/1     Running   0          19s     10.244.104.10    node2   <none>           <none>

此时，pod85 和 pod86 两个 pod 位于同一个 node 节点。 

 7.Pod 软亲和度

Pod 软亲和调度使用方法与 Node 软亲和调度方法类似。

(1)编辑 pod87 的 pod
[root@master ~]# vim test07.yaml apiVersion: v1
kind: Pod
metadata:name: pod07
spec:affinity:podAffinity:preferredDuringSchedulingIgnoredDuringExecution:- weight: 20podAffinityTerm:labelSelector:matchExpressions:- {key: app, operator: In, values: ["pod05"]}topologyKey: kubernetes.io/hostname- weight: 80podAffinityTerm:labelSelector:matchExpressions:- {key: app, operator: In, values: ["pod04"]}topologyKey: kubernetes.io/hostnamecontainers:- name: pod07image: nginx:1.7.9

 注释:

        values:["pod05"]是 pod05 的 pod 的标签

        values:["pod04"]是 pod04 的 pod 的标签

正则匹配了 pod 的标签“pode5”，带有 pod85 标签的 pod 是 pod05，该 pod 在 node82 上，于是 pod87的 pod 也调度到了 node02 上。

注意:
node 软亲和中的权重值不影响 pod 的调度，谁在前面，就亲和谁。
pod 软亲和中的权重值是会影响调度到的节点的，pod 软亲和中谁的权重高就调度到谁那里。

[root@k8s-master ~l# kubectl create -f test07.yaml
[root@k8s-master ~]# kubectl get pod pod07 -o wide
NAME    READY   STATUS    RESTARTS   AGE   IP               NODE    NOMINATED NODE   READINESS GATES
pod07   1/1     Running   0          3s    10.244.166.137   node1   <none>           <none>

pod04 的标签是 webweb，所在的节点标签是 node1

pod05 的标签是 web，所在的节点标签是 node2

(2)编辑 pod08 的 pod

修改 yam1 文件中的权重，使其与 pod84 亲和性更高，因为 pod84 在 node01 上，pod08 也会被部署到node01 上

[root@master ~]# vim test08.yaml apiVersion: v1
kind: Pod
metadata:name: pod08
spec:affinity:podAffinity:preferredDuringSchedulingIgnoredDuringExecution:- weight: 20podAffinityTerm:labelSelector:matchExpressions:- {key: app, operator: In, values: ["pod05"]}topologyKey: kubernetes.io/hostname- weight: 80podAffinityTerm:labelSelector:matchExpressions:- {key: app, operator: In, values: ["pod04"]}topologyKey: kubernetes.io/hostnamecontainers:- name: pod08image: nginx:1.7.9

备注:
匹配了“pod84”标签的亲和度对应的权重值更高，按照此权重，pod08 会被调度到标签为“pod84”的pod 所在的 node 节点，即 node01

注意:
pod04 的标签是 pod04，所在的节点标签是 node01

pod05 的标签是 pod85，所在的节点标签是 node02

[root@k8s-master ~]# kubectl create -f test08.yaml
[root@k8s-master ~]# kubectl get pod pod08 -o wide
NAME    READY   STATUS    RESTARTS   AGE   IP               NODE    NOMINATED NODE   READINESS GATES
pod08   1/1     Running   0          4s    10.244.166.138   node1   <none>           <none>

 8.pod 反亲和

[root@master ~]# vim test09.yaml apiVersion: v1
kind: Pod
metadata:name: pod09
spec:affinity:podAntiAffinity:requiredDuringSchedulingIgnoredDuringExecution:- labelSelector:matchExpressions:- {key: app, operator: In, values: ["pod05"]}topologyKey: kubernetes.io/hostnamecontainers:- name: test09image: nginx:1.7.9
[root@k8s-master~]# kubectl create -f test09.yaml
[root@k8s-master ~# kubectl get pod -o wide
[root@master ~]# ku get pod -o wide
NAME    READY   STATUS    RESTARTS   AGE     IP               NODE    NOMINATED NODE   READINESS GATES
pod01   1/1     Running   0          7m20s   10.244.166.135   node1   <none>           <none>
pod02   1/1     Running   0          4m37s   10.244.104.7     node2   <none>           <none>
pod03   1/1     Running   0          4m14s   10.244.104.8     node2   <none>           <none>
pod04   1/1     Running   0          3m42s   10.244.166.136   node1   <none>           <none>
pod05   1/1     Running   0          3m18s   10.244.104.9     node2   <none>           <none>
pod06   1/1     Running   0          2m17s   10.244.104.10    node2   <none>           <none>
pod07   1/1     Running   0          67s     10.244.166.137   node1   <none>           <none>
pod08   1/1     Running   0          42s     10.244.166.138   node1   <none>           <none>
pod09   1/1     Running   0          22s     10.244.166.139   node1   <none>           <none>

査看 pod89 所在的节点,因为设置的反亲和 pod85,所以,pod85在 node82的话,pod89 就会在 node01

相关文章：

  • 北京网站建设多少钱？
  • 辽宁网页制作哪家好_网站建设
  • 高端品牌网站建设_汉中网站制作
  • Spring Boot如何压缩Json并写入redis？
  • Window Performance API
  • 苹果机器人计划：能否成为智能家居的破局者？
  • MyBatis查询 ▎修改 ▎删除
  • postman请求设置
  • 对接微信小程序授权登录
  • qt处理表格，Qtxlsx库文件的安装以及导入
  • Python 点云ISS关键点提取算法
  • 文本向量化的六种常见模式
  • Spark MLlib模型训练—分类算法Multinomial Logistic Regression
  • SAP 表格设置全部隐藏后的恢复问题
  • Centos服务器配置使用密钥登录
  • oracle 重做日志（Redo LogBuffer）
  • uni-app开发日志：schema2code生成的新增页和修改页因字段太多用分段器实现分段分类
  • 【iOS端】基于Uniapp跨平台接入即构RTC+相芯美颜
  • 【面试系列】之二：关于js原型
  • 【跃迁之路】【519天】程序员高效学习方法论探索系列（实验阶段276-2018.07.09）...
  • 3.7、@ResponseBody 和 @RestController
  • angular2开源库收集
  • CentOS 7 修改主机名
  • Docker入门（二） - Dockerfile
  • Git学习与使用心得（1）—— 初始化
  • go语言学习初探（一）
  • If…else
  • Java小白进阶笔记(3)-初级面向对象
  • maven工程打包jar以及java jar命令的classpath使用
  • MQ框架的比较
  • Puppeteer：浏览器控制器
  • Vue源码解析（二）Vue的双向绑定讲解及实现
  • 案例分享〡三拾众筹持续交付开发流程支撑创新业务
  • 诡异！React stopPropagation失灵
  • 利用jquery编写加法运算验证码
  • 世界上最简单的无等待算法(getAndIncrement)
  • 思维导图—你不知道的JavaScript中卷
  • 算法之不定期更新（一）（2018-04-12）
  • 微信小程序设置上一页数据
  • 智能合约Solidity教程-事件和日志（一）
  • ​LeetCode解法汇总2304. 网格中的最小路径代价
  • #define MODIFY_REG(REG, CLEARMASK, SETMASK)
  • #LLM入门|Prompt#1.8_聊天机器人_Chatbot
  • #Z0458. 树的中心2
  • （2）(2.10) LTM telemetry
  • （52）只出现一次的数字III
  • （附源码）springboot学生选课系统 毕业设计 612555
  • （附源码）基于SpringBoot和Vue的厨到家服务平台的设计与实现 毕业设计 063133
  • （每日一问）计算机网络：浏览器输入一个地址到跳出网页这个过程中发生了哪些事情？（废话少说版）
  • (四)js前端开发中设计模式之工厂方法模式
  • （一）C语言之入门：使用Visual Studio Community 2022运行hello world
  • （一）SpringBoot3---尚硅谷总结
  • （转）C#开发微信门户及应用(1)--开始使用微信接口
  • .net core Swagger 过滤部分Api
  • .net framework profiles /.net framework 配置
  • .net 调用php,php 调用.net com组件 --
  • .NET运行机制
  • @AliasFor 使用