1. NodeSelector

2. 亲和与反亲和 Affinity and Anti-affinity

节点Node 亲和性

pod 亲和性和反亲和性

3. 污点（Taints）与容忍（tolerations）

1、设置污点：

2、去除污点：

3、Pod 容忍污点示例：

4. effect的类型

5. 使用场景

1. NodeSelector

如果需要限制Pod到指定的Node上运行，则可以给Node打标签并给Pod配置NodeSelector。

给Node打标签

# get node的name
kubectl get nodes# 设置Label
kubectl label nodes <node-name> <label-key>=<label-value>
# 例如
kubectl label nodes node1 gputype=p4# 查看Node的Label
kubectl get nodes --show-labels

给Pod设置NodeSelector

apiVersion: v1
kind: Pod
metadata:name: nginxlabels:env: test
spec:containers:- name: nginximage: nginximagePullPolicy: IfNotPresentnodeSelector:gputype: p4    #对应Node的Label

这是一种强规则，没有妥协，必须遵守。
特点：简单，容易配置
缺点：强规则，没有妥协，若不存在符合条件的node，则无法部署。

nodeSelector 将会在后续的版本中废除，还是建议大家使用使用亲和性策略。

kubectl label nodes kube-node node=kube-node
kubectl get node -a -l "node=kube-node"

sepc.nodeSelector中指定：

Label selector

Label是附着到object上（例如Node, Pod）的键值对。可以在创建object的时候指定，也可以在object创建后随时指定。Labels的值对系统本身并没有什么含义，只是对用户才有意义。

"labels": {"key1" : "value1","key2" : "value2"
}

Label selector有两种类型：

equality-based ：可以使用=、==、!=操作符，可以使用逗号分隔多个表达式
set-based ：可以使用in、notin、! 操作符，另外还可以没有操作符，直接写出某个label的key，表示过滤有某个key的object而不管该key的value是何值，!表示没有该label的object

$ kubectl get pods -l environment=production,tier=frontend
$ kubectl get pods -l 'environment in (production),tier in (frontend)'
$ kubectl get pods -l 'environment in (production, qa)'
$ kubectl get pods -l 'environment,environment notin (frontend)'

在API object中设置label selector

在service、replicationcontroller等object中有对pod的label selector，使用方法只能使用等于操作，例如：

selector:component: redis

在Job、Deployment、ReplicaSet和DaemonSet这些object中，支持set-based的过滤，例如：

selector:matchLabels:component: redismatchExpressions:- {key: tier, operator: In, values: [cache]}- {key: environment, operator: NotIn, values: [dev]}

2. 亲和与反亲和 Affinity and Anti-affinity

nodeSelector的调度方式略显简单，通过亲和和反亲和配置，能够为调度提供更灵活的策略，主要有以下几点增强：

匹配有更多的逻辑组合，不只是字符的完全相等
调度分成软策略（soft）和硬策略（hard），在软策略的情况下，如果没有满足调度条件的节点，pod 会忽略这条规则，继续完成调度过程

软策略和硬策略的区分是有用处的，硬策略适用于 pod 必须运行在某种节点，否则会出现问题的情况，比如集群中节点的架构不同，而运行的服务必须依赖某种架构提供的功能；软策略不同，它适用于满不满足条件都能工作，但是满足条件更好的情况，比如服务最好运行在某个区域，减少网络传输等。这种区分是用户的具体需求决定的，并没有绝对的技术依赖。

节点Node 亲和性

类似于nodeSelector，允许我们指定一些Pod在Node间调度的约束
支持两种形式：

requiredDuringSchedulingIgnoredDuringExecution 必须满足，如果不满足则不进行调度
preferredDuringSchedulingIgnoredDuringExecution 倾向满足，不满足的情况下会调度的不符合条件的Node上

...IgnoreDuringExecution 表示如果在Pod运行期间Node的标签发生变化，导致亲和性策略不能满足，则继续运行当前的Pod。

requiredDuringSchedulingRequiredDuringExecution 必须满足，
requiredDuringSchedulingRequiredDuringExecution 倾向满足，

...RequiredDuringExecution，如果运行的 pod 所在节点不再满足条件，kubernetes 会把 pod 从节点中删除，重新选择符合要求的节点。这个属性暂时还不支持

AFFINITY SELECTOR	REQUIREMENTS MET	REQUIREMENTS NOT MET	REQUIREMENTS LOST
requiredDuringSchedulingIgnoredDuringExecution	Runs	Fails	Keeps Running
preferredDuringSchedulingIgnoredDuringExecution	Runs	Runs	Keeps Running
(un-implemented) requiredDuringSchedulingRequiredDuringExecution	Runs	Fails	Fails

apiVersion: v1
kind: Pod
metadata:name: with-node-affinity
spec:affinity:nodeAffinity:requiredDuringSchedulingIgnoredDuringExecution:nodeSelectorTerms:- matchExpressions:- key: kubernetes.io/e2e-az-nameoperator: Invalues:- e2e-az1- e2e-az2preferredDuringSchedulingIgnoredDuringExecution:- weight: 1preference:matchExpressions:- key: another-node-label-keyoperator: Invalues:- another-node-label-valuecontainers:- name: with-node-affinityimage: gcr.io/google_containers/pause:2.0

这个 pod 同时定义了 requiredDuringSchedulingIgnoredDuringExecution 和 preferredDuringSchedulingIgnoredDuringExecution 两种 nodeAffinity。第一个要求 pod 运行在特定 AZ 的节点上，第二个希望节点最好有对应的 another-node-label-key:another-node-label-value 标签。
这里的匹配逻辑是 label 的值在某个列表中，可选的操作符有：

In：label 的值在某个列表中
NotIn：label 的值不在某个列表中
Exists：某个 label 存在
DoesNotExist: 某个 label 不存在
Gt：label 的值大于某个值（字符串比较）
Lt：label 的值小于某个值（字符串比较）

如果nodeAffinity 中 nodeSelectorTerms 有多个选项，如果节点满足任何一个条件就可以；如果 matchExpressions 有多个选项，则只有同时满足这些逻辑选项的节点才能运行 pod。

pod 亲和性和反亲和性

podAffinity 主要解决POD可以和哪些POD部署在同一个拓扑域中的问题（拓扑域用主机标签实现，可以是单个主机，也可以是多个主机组成的cluster、zone等。），podAntiAffinity主要解决POD不能和哪些POD部署在同一个拓扑域中的问题。它们处理的是Kubernetes集群内部POD和POD之间的关系。
作用域： pod 于pod之间

apiVersion: v1
kind: Pod
metadata:name: with-pod-affinity
spec:affinity:podAffinity:requiredDuringSchedulingIgnoredDuringExecution:- labelSelector:matchExpressions:- key: securityoperator: Invalues:- S1topologyKey: failure-domain.beta.kubernetes.io/zonepodAntiAffinity:preferredDuringSchedulingIgnoredDuringExecution:- weight: 100podAffinityTerm:labelSelector:matchExpressions:- key: securityoperator: Invalues:- S2topologyKey: kubernetes.io/hostnamecontainers:- name: with-pod-affinityimage: gcr.io/google_containers/pause:2.0

3. 污点（Taints）与容忍（tolerations）

NodeAffinity节点亲和性，是Pod上定义的一种属性，使Pod能够按我们的要求调度到某个Node上，而Taints则恰恰相反，它可以让Node拒绝运行Pod，甚至驱逐Pod。

Taints(污点)是Node的一个属性，设置了Taints(污点)后，因为有了污点，所以Kubernetes是不会将Pod调度到这个Node上的，于是Kubernetes就给Pod设置了个属性Tolerations(容忍)，只要Pod能够容忍Node上的污点，那么Kubernetes就会忽略Node上的污点，就能够(不是必须)把Pod调度过去。

因此 Taints(污点)通常与Tolerations(容忍)配合使用。

1、设置污点：

kubectl taint node [node] key=value[effect]   示例：kubectl taint node 10.3.1.16 test=16:NoSchedule

其中[effect] 可取值： [ NoSchedule | PreferNoSchedule | NoExecute ]

NoSchedule：POD 不会被调度到标记为 taints 节点。
PreferNoSchedule：NoSchedule 的软策略版本。
NoExecute：该选项意味着一旦 Taint 生效，如该节点内正在运行的 POD 没有对应 Tolerate 设置，会直接被逐出。

2、去除污点：

比如设置污点：kubectl taint node 10.3.1.16 test=16:NoSchedulekubectl taint node 10.3.1.16 test=16:NoExecute去除指定key及其effect：kubectl taint nodes node_name key:[effect]-    #(这里的key不用指定value)去除指定key所有的effect: kubectl taint nodes node_name key-示例：kubectl taint node 10.3.1.16 test:NoSchedule-kubectl taint node 10.3.1.16 test:NoExecute-kubectl taint node 10.3.1.16 test-

3、Pod 容忍污点示例：

对于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。

一个node上可以有多个污点：
比如 test=16:NoScheduler test2=16:NoSchedule
而在Pod容忍时只容忍了其中一个：

tolerations:- key: "test"operator: "Equal" value: "16"effect: "NoSchedule"

这样的结果是此Pod无法被调度到key为test的node( 10.3.1.16)上去，因为此Node上设置了两个污点，
而这个Pod只匹配到了一个污点，也就是只容忍了一个污点，所以可以再加一个容忍：

tolerations:- key: "test"operator: "Exists" effect: "NoSchedule"- key: "test2"operator: "Equal"value: "16"effect: "NoSchedule"

如果在设置node的Taints(污点)之前，就已经运行了一些Pod，那么这些Pod是否还能继续在此Node上运行？这就要看设置Taints污点时的effect(效果)了。

如果effect的值是NoSchedule或PreferNoSchedule，那么已运行的Pod仍然可以运行，只是新Pod(如果没有容忍)不会再往上调度。

而如果effect的值是NoExecute，那么此Node上正在运行的Pod，只要没有容忍的，立刻被驱逐。虽然是立刻被驱逐，但是K8S为了彰显人性化，又给具有NoExecute效果的污点，在容忍属性中有一个可选的tolerationSeconds字段，用来设置这些Pod还可以在这个Node之上运行多久，给它们一点宽限的时间，到时间才驱逐。
如果是以Pod来启动的，那么Pod被驱逐后，将不会再被运行，就等于把它删除了。
如果是deployment/rc，那么删除的pod会再其它节点运行。
如果是DaemonSet在此Node上启动的Pod，那么也不会再被运行，直到Node上的NoExecute污被去除或者Pod容忍。

#设置Pod的宽限时间
spec:tolerations: #设置容忍性- key: "test"operator: "Equal" #如果操作符为Exists，那么value属性可省略value: "16"effect: "NoExecute"tolerationSeconds: 180 #如果运行此Pod的Node，被设置了具有NoExecute效果的Taint(污点)，这个Pod将在存活180s后才被驱逐。#如果没有设置tolerationSeconds字段，将永久运行。

通过对Taints和Tolerations的了解，可以知道，通过它们可以让某些特定应用，独占一个Node：
给特定的Node设置一个Taint，只让某些特定的应用来容忍这些污点，容忍后就有可能会被调度到此特定Node，
但是也不一定会调度给此特定Node，设置容忍并不阻止调度器调度给其它Node，那么如何让特定应用的Node
只能被调度到此特定的Node呢，这就要结合NodeAffinity节点亲和性，给Node打个标签，然后在Pod属性里
设置NodeAffinity到Node。如此就能达到要求了。

4. effect的类型

NoSchedule：只有拥有和这个 taint 相匹配的 toleration 的 pod 才能够被分配到这个节点。
PreferNoSchedule：系统会尽量避免将 pod 调度到存在其不能容忍 taint 的节点上，但这不是强制的。
NoExecute ：任何不能忍受这个 taint 的 pod 都会马上被驱逐，任何可以忍受这个 taint 的 pod 都不会被驱逐。Pod可指定属性 tolerationSeconds 的值，表示pod 还能继续在节点上运行的时间。

5. 使用场景

5.1 专用节点
kubectl taint nodes <nodename> dedicated=<groupName>:NoSchedule
先给Node添加taint，然后给Pod添加相对应的 toleration，则该Pod可调度到taint的Node，也可调度到其他节点如果想让Pod只调度某些节点且某些节点只接受对应的Pod，则需要在Node上添加Label（例如：dedicated=groupName），同时给Pod的nodeSelector添加对应的Label。

5.2 特殊硬件节点
如果某些节点配置了特殊硬件（例如CPU），希望不使用这些特殊硬件的Pod不被调度该Node，以便保留必要资源。即可给Node设置taint和label，同时给Pod设置toleration和label来使得这些Node专门被指定Pod使用。

# kubectl taint
kubectl taint nodes nodename special=true:NoSchedule
# 或者
kubectl taint nodes nodename special=true:PreferNoSchedule

5.3 基于taint驱逐
effect 值 NoExecute ，它会影响已经在节点上运行的 pod，即根据策略对Pod进行驱逐。

如果 pod 不能忍受effect 值为 NoExecute 的 taint，那么 pod 将马上被驱逐
如果 pod 能够忍受effect 值为 NoExecute 的 taint，但是在 toleration 定义中没有指定 tolerationSeconds，则 pod 还会一直在这个节点上运行。
如果 pod 能够忍受effect 值为 NoExecute 的 taint，而且指定了 tolerationSeconds，则 pod 还能在这个节点上继续运行这个指定的时间长度。

参考：

https://kubernetes.io/docs/concepts/configuration/assign-pod-node/

https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/

[kubernetes] Schedule --- Node调度与隔离相关推荐

Kubernetes 是如何调度的？
作者 | 阿文,责编 | 郭芮头图 | CSDN 下载自东方IC 出品 | CSDN(ID:CSDNnews) 自互联网出现以来 ,云计算的概念已经提出了有 50 年.从1957 年,John Mc ...
Kubernetes之Pod调度
本文讲的是Kubernetes之Pod调度[编者的话]Kubernetes调度器根据特定的算法与策略将pod调度到工作节点上.在默认情况下,Kubernetes调度器可以满足绝大多数需求,例如调度po ...
kubernetes修改node的role标签
kubernetes修改node的role标签 [root@master ~]# kubectl get node NAME STATUS ROLES AGE VERSION master Ready ...
Kubernetes对Pod调度指定Node以及Node的Taint 和 Toleration
1.指定pod到指定的node上 #1.1查看节点的lebel kubectl get nodes --show-labels#1.2获取到该节点的label信息 ip-10-100-2-80 Rea ...
kubernetes 简介：调度器和调度算法((Affinity/Anti-Affinity, Taints and Tolerations, 自定义调度器 )
全栈工程师开发手册 (作者:栾鹏) 架构系列文章简介 scheduler 是 kubernetes 的调度器,主要的任务是把定义的 pod 分配到集群的节点上.听起来非常简单,但有很多要考虑的问题: ...
k8s指定node调度
概述在使用过程中,如果希望指定的pod放在自己希望的node节点上可以进行调度,选择对应的node节点. 可以看出可以使用节点的ip地址或者是在node节点添加标签,让pod调度器使用selecto ...
kubernetes之亲合性调度
目录文章目录目录实验环境实验软件本节实践调度创建一个Pod的工作流程 1.架构图 2.剖析过程 3.Pod中影响调度的主要属性 4.调度器需要充分考虑诸多的因素 5.Kubernetes ...
二十、Kubernetes中Pod调度第二篇NodeAffinity详解、实例
1.概述在默认情况下,一个Pod在哪个Node节点上运行,是由Scheduler组件采用相应的算法计算出来的,这个过程是不受人工控制的.但是在实际使用中,这并不满足的需求,因为很多情况下,我们想控制 ...
kubernetes之node 宕机，pod驱离问题解决
背景: 当node宕机时,希望该node节点上的pod能够快速疏散到其他节点,并提供服务.测试发现,要等待5分钟,上面的pod才会疏散. 网上介绍通过修改 /etc/kubernetes/manife ...

[kubernetes] Schedule --- Node调度与隔离

1. NodeSelector

2. 亲和与反亲和 Affinity and Anti-affinity

节点Node 亲和性

pod 亲和性和反亲和性

3. 污点（Taints）与容忍（tolerations）

1、设置污点：

2、去除污点：

3、Pod 容忍污点示例：

4. effect的类型

5. 使用场景

[kubernetes] Schedule --- Node调度与隔离相关推荐

最新文章

热门文章