Pod的调度
在默认情况下,一个Pod在哪个Node节点上运行,是由Scheduler组件采用相应的算法计算出来的,这个过程是不受人工控制的。但是在实际使用中,这并不满足需求,因为很多情况下,我们想控制某些Pod到达某些节点上,那么应该怎么做?这就要求了解Kubernetes对Pod的调度规则,Kubernetes提供了四大类调度方式。
- 自动调度:运行在哪个Node节点上完全由Scheduler经过一系列的算法计算得出。
- 定向调度:NodeName、NodeSelector。
- 亲和性调度:NodeAffinity、PodAffinity、PodAntiAffinity。
- 污点(容忍)调度:Taints、Toleration。
一、定向调度
定向调度,指的是利用在Pod上声明的nodeName或nodeSelector,以此将Pod调度到期望的Node节点上。注意,这里的调度是强制的,这就意味着即使要调度的目标Node不存在,也会向上面进行调度,只不过Pod运行失败而已。
1、nodeName
nodeName用于强制约束将Pod调度到指定的name的Node节点上。这种方式,其实是直接跳过Scheduler的调度逻辑,直接将Pod调度到指定名称的节点。
首先创建一个pod-nodename.yaml文件,内容如下:
apiVersion: v1
kind: Pod
metadata:
name: pod-nodename
namespace: dev
labels:
user: Negan
spec:
containers:
- name: nginx # 容器名称
image: nginx:1.17.1 # 容器需要的镜像地址
imagePullPolicy: IfNotPresent # 设置镜像的拉取策略
ports:
- name: nginx-port # 端口名称,如果执行,必须保证name在Pod中是唯一的
containerPort: 80 # 容器要监听的端口
protocol: TCP # 端口协议
nodeName: node1 # 指定调度到node1上
创建和查看Pod的状态,我们会发现Pod所在的Node节点就是我们指定的node1节点。
# 创建pod
kubectl create -f pod_nodename.yaml
# 查看
kubectl get pod pod-nodename -n dev -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
pod-nodename 1/1 Running 0 27s 10.244.1.18 node1 <none> <none>
当然我们也可以将pod调度到不存在node上,pod肯定也是不能正常运行。
# 删除pod
kubectl delete -f pod_nodename.yaml
# 修改pod_nodename.yaml
# 将nodeName:node1 修改为node3 (node3不存在)
# 创建和查看状态
kubectl create -f pod_nodename.yaml
kubectl get pods pod-nodename -n dev -o wide
# 我们发现pod的状态时挂起状态
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
pod-nodename 0/1 Pending 0 6s <none> node3 <none> <none>
2、nodeSelector
nodeSelector用于将Pod调度到添加了指定标签的Node节点上,它是通过Kubernetes的label-selector机制实现的,换言之,在Pod创建之前,会由Scheduler使用MatchNodeSelector调度策略进行label匹配,找出目标node,然后将Pod调度到目标节点,该匹配规则是强制约束。
首先给node节点添加标签
kubectl label node node1 env=pro # 给node1添加标签为env=pro
kubectl label node node2 env=debug # 给node2添加标签为env=debug
# 可以看到我们已经添加上了相应的标签
kubectl get nodes --show-labels
NAME STATUS ROLES AGE VERSION LABELS
master Ready master 2d v1.18.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/master=
node1 Ready <none> 2d v1.18.0 beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,env=pro,kubernetes.io/arch=amd64,kubernetes.io/hostname=node1,kubernetes.io/os=linux
node2 Ready <none> 2d v1.18.0 beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,env=debug,kubernetes.io/arch=amd64,kubernetes.io/hostname=node2,kubernetes.io/os=linux
创建pod_nodeselector.yaml文件
apiVersion: v1
kind: Pod
metadata:
name: pod-nodeselector
namespace: dev
labels:
user: Negan
spec:
containers:
- name: nginx # 容器名称
image: nginx:1.17.1 # 容器需要的镜像地址
imagePullPolicy: IfNotPresent # 设置镜像的拉取策略
ports:
- name: nginx-port # 端口名称,如果执行,必须保证name在Pod中是唯一的
containerPort: 80 # 容器要监听的端口
protocol: TCP # 端口协议
nodeSelector:
env: debug
查看Pod的状态:
kubectl get pod pod-nodeselector -n dev -o wide
# 发现成功调度到node2上
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
pod-nodeselector 1/1 Running 0 21s 10.244.2.20 node2 <none> <none>
同样,我们如要调度要不存在的标签上,会发生什么情况:
# 删除pod
kubectl delete -f pod_nodeselector.yaml
# 修改pod_nodeselector.yaml文件
# 将debug改为debug1
# 创建和查看
kubectl get pod pod-nodeselector -n dev -o wide
# pod的状态为挂起状态
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
pod-nodeselector 0/1 Pending 0 24s <none> <none> <none> <none>
二、亲和性调度
虽然定向调度的两种方式,使用起来非常方便,但是也有一定的问题,那就是如果没有满足条件的Node,那么Pod将不会被运行,即使在集群中还有可用的Node列表也不行,这就限制了它的使用场景。
基于上面的问题,Kubernetes还提供了一种亲和性调度(Affinity)。它在nodeSelector
的基础之上进行了扩展,可以通过配置的形式,实现优先选择满足条件的Node进行调度,如果没有,也可以调度到不满足条件的节点上,使得调度更加灵活。
Affinity主要分为三类:
- nodeAffinity(node亲和性):以Node为目标,解决Pod可以调度到那些Node的问题。
- podAffinity(pod亲和性):以Pod为目标,解决Pod可以和那些已存在的Pod部署在同一个拓扑域中的问题。
- podAntiAffinity(pod反亲和性):以Pod为目标,解决Pod不能和那些已经存在的Pod部署在同一拓扑域中的问题。
亲和性:如果两个应用频繁交互,那么就有必要利用亲和性让两个应用尽可能的靠近,这样可以较少因网络通信而带来的性能损耗。
反亲和性:当应用采用多副本部署的时候,那么就有必要利用反亲和性让各个应用实例打散分布在各个Node上,这样可以提高服务的高可用性。
1、nodeAffinity
查看nodeAffinity的可选配置项:
requiredDuringSchedulingIgnoredDuringExecution #Node节点必须满足指定的所有规则才可以,相当于硬限制
nodeSelectorTerms #节点选择列表
matchFields # 按节点字段列出的节点选择器要求列表
matchExpressions #按节点标签列出的节点选择器要求列表(推荐)
key #键
values #值
operator #关系符 支持Exists, DoesNotExist, In, NotIn, Gt, Lt
preferredDuringSchedulingIgnoredDuringExecution #优先调度到满足指定的规则的Node,相当于软限制 (倾向)
preference #一个节点选择器项,与相应的权重相关联
matchFields #按节点字段列出的节点选择器要求列表
matchExpressions #按节点标签列出的节点选择器要求列表(推荐)
key #键
values #值
operator #关系符 支持In, NotIn, Exists, DoesNotExist, Gt, Lt
weight # 倾向权重,在范围1-100。
关系符的使用说明:
- matchExpressions:
- key: env # 匹配存在标签的key为env的节点
operator: Exists
- key: env # 匹配标签的key为env,且value是"xxx"或"yyy"的节点
operator: In
values: ["xxx","yyy"]
- key: env # 匹配标签的key为env,且value大于"xxx"的节点
operator: Gt
values: "xxx"
1.1、requiredDuringSchedulingIgnoredDuringExecution
硬限制
创建pod_nodeaffinity_required.yaml文件
apiVersion: v1
kind: Pod
metadata:
name: pod-nodeaffinity-required
namespace: dev
labels:
user: Negan
spec:
containers:
- name: nginx # 容器名称
image: nginx:1.17.1 # 容器需要的镜像地址
imagePullPolicy: IfNotPresent # 设置镜像的拉取策略
ports:
- name: nginx-port # 端口名称,如果执行,必须保证name在Pod中是唯一的
containerPort: 80 # 容器要监听的端口
protocol: TCP # 端口协议
affinity: # 亲和性设置
nodeAffinity: # node亲和性
requiredDuringSchedulingIgnoredDuringExecution: # node节点必须满足所有规则
nodeSelectorTerms: # 节点选择列表
- matchExpressions:
- key: env
operator: In
values: ["xxx","yyy"] # 需要满足其中一个
查看状态
kubectl get pods pod-nodeaffinity-required -n dev -o wide
# 我们发现STATUS为Pending,这也不难解释,我们的标签env对应的值没有xxx和yyy
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
pod-nodeaffinity-required 0/1 Pending 0 24s <none> <none> <none> <none>
使其正常调度
# 删除pod
kuebctl delete -f pod_nodeaffinity_required.yaml
# 修改yaml文件,将“pro”或“debug”添加到values列表中,这里我添加了"pro"
# 创建
kubectl create -f pod_nodeaffinity_required.yaml
# 查看
kubectl get pods pod-nodeaffinity-required -n dev -o wide
# 发现Pod成功被调度到node1节点上了
kubectl get pods pod-nodeaffinity-required -n dev -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
pod-nodeaffinity-required 1/1 Running 0 3s 192.168.166.131 node1 <none> <none>
1.2、preferredDuringSchedulingIgnoredDuringExecution
软限制
创建pod_nodeaffinity_preferred.yaml文件
apiVersion: v1
kind: Pod
metadata:
name: pod-nodeaffinity-preferred
namespace: dev
spec:
containers: # 容器配置
- name: nginx
image: nginx:1.17.1
imagePullPolicy: IfNotPresent
ports:
- name: nginx-port
containerPort: 80
protocol: TCP
affinity: # 亲和性配置
nodeAffinity: # node亲和性配置
preferredDuringSchedulingIgnoredDuringExecution: # 优先调度到满足指定的规则的Node,相当于软限制 (倾向)
- preference: # 一个节点选择器项,与相应的权重相关联
matchExpressions:
- key: nodeenv
operator: In
values:
- "xxx"
- "yyy"
weight: 1
查看Pod状态:
kubectl get pods pod-nodeaffinity-preferred -n dev -o wide
# 发现即使没有满足条件,pod也被正常调度了。
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
pod-nodeaffinity-preferred 1/1 Running 0 16s 192.168.104.2 node2 <none> <none>
注意:
如果同时定义了
nodeSelector
和nodeAffinity
,那么必须两个条件都满足,Pod才能运行在指定的Node上。如果
nodeAffinity
指定了多个nodeSelectorTerms
,那么只需要其中一个能够匹配成功即可。如果一个
nodeSelectorTerms
中有多个matchExpressions
,则一个节点必须满足所有的才能匹配成功。如果一个Pod所在的Node在Pod运行期间其标签发生了改变,不再符合该Pod的
nodeAffinity
的要求,则系统将忽略此变化。
2、podAffinity
podAffinity主要实现以运行的Pod为参照,实现让新创建的Pod和参照的Pod在一个区域的功能。
查看PodAffinity的可选配置项
requiredDuringSchedulingIgnoredDuringExecution # 硬限制
namespaces # 指定参照pod的namespace
topologyKey # 指定调度作用域
labelSelector # 标签选择器
matchExpressions # 按节点标签列出的节点选择器要求列表(推荐)
key # 键
values # 值
operator # 关系符 支持In, NotIn, Exists, DoesNotExist.
matchLabels # 指多个matchExpressions映射的内容
preferredDuringSchedulingIgnoredDuringExecution # 软限制
podAffinityTerm # 选项
namespaces
topologyKey
labelSelector
matchExpressions
key # 键
values # 值
operator
matchLabels
weight 倾向权重,在范围1-100
topologyKey用于指定调度的作用域,例如:
如果指定为kubernetes.io/hostname,那就是以Node节点为区分范围。
如果指定为beta.kubernetes.io/os,则以Node节点的操作系统类型来区分。
案例
创建参照的pod,编写pod-podaffinity-target.yaml文件
apiVersion: v1
kind: Pod
metadata:
name: pod-podaffinity-target
namespace: dev
labels:
user: Negan
spec:
containers:
- name: nginx # 容器名称
image: nginx:1.17.1 # 容器需要的镜像地址
imagePullPolicy: IfNotPresent # 设置镜像的拉取策略
ports:
- name: nginx-port # 端口名称,如果执行,必须保证name在Pod中是唯一的
containerPort: 80 # 容器要监听的端口
protocol: TCP # 端口协议
nodeName: node1 # 将pod定向调度到node1节点上
查看目标pod的运行状态:
kubectl get pods pod-podaffinity-target -n dev -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
pod-podaffinity-target 1/1 Running 0 37s 192.168.166.134 node1 <none> <none>
发现如我们预期那样,参照pod运行在node节点上。
2.1、requiredDuringSchedulingIgnoredDuringExecution
创建目标pod,将其调度到参照pod所在的节点上,编写pod-podaffinity-requred.yaml文件 :
apiVersion: v1
kind: Pod
metadata:
name: pod-podaffinity-requred
namespace: dev
spec:
containers: # 容器配置
- name: nginx
image: nginx:1.17.1
imagePullPolicy: IfNotPresent
ports:
- name: nginx-port
containerPort: 80
protocol: TCP
affinity: # 亲和性配置
podAffinity: # Pod亲和性
requiredDuringSchedulingIgnoredDuringExecution: # 硬限制
- labelSelector:
matchExpressions: # 该Pod必须和拥有标签user=Negan或者user=yyy的Pod在同一个Node上
- key: user
operator: In
values:
- "Negan"
- "yyy"
topologyKey: kubernetes.io/hostname
查看目标pod运行状态:
kubectl get pods pod-podaffinity-requred -n dev -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
pod-podaffinity-requred 1/1 Running 0 25s 192.168.166.135 node1 <none> <none>
发现目标pod和参考pod运行在同一个Node节点上。
2.2、preferredDuringSchedulingIgnoredDuringExecution
软限制
编写pod-podaffinity-requred.yaml文件,我们将pod调度到不满足调度条件的node上,看是否能成功 :
apiVersion: v1
kind: Pod
metadata:
name: pod-podaffinity-prefer
namespace: dev
spec:
containers: # 容器配置
- name: nginx
image: nginx:1.17.1
imagePullPolicy: IfNotPresent
ports:
- name: nginx-port
containerPort: 80
protocol: TCP
affinity: # 亲和性配置
podAffinity: # Pod亲和性
preferredDuringSchedulingIgnoredDuringExecution: #软限制
- podAffinityTerm:
labelSelector:
matchExpressions:
- key: user
operator: In
values:
- "xxx"
- "yyy"
topologyKey: kubernetes.io/hostname
weight: 1
查看pod的状态:
kubectl get pod -n dev pod-podaffinity-prefer -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
pod-podaffinity-prefer 1/1 Running 0 21s 192.168.104.4 node2 <none> <none>
发现pod在不满足给定调度条件情况下,任然可以调度,pod被调度到了node2上。
3、podAntiAffinity
podAntiAffinity主要实现以运行的Pod为参照,让新创建的Pod和参照的Pod不在一个区域的功能。
其配置方式和podAffinity一样,此处不做详细解释。
这里我们继续使用上面的参照pod做演示。
创建pod-podantiaffinity-requred.yaml文件,内容如下:
apiVersion: v1
kind: Pod
metadata:
name: pod-podantiaffinity-requred
namespace: dev
spec:
containers: # 容器配置
- name: nginx
image: nginx:1.17.1
imagePullPolicy: IfNotPresent
ports:
- name: nginx-port
containerPort: 80
protocol: TCP
affinity: # 亲和性配置
podAntiAffinity: # Pod反亲和性
requiredDuringScheduAlingIgnoredDuringExecution: # 硬限制
- labelSelector:
matchExpressions: # 该Pod必须和拥有标签user=Negan或者user=yyy的Pod在不在同一个Node上
- key: user
operator: In
values:
- "Negan"
- "yyy"
topologyKey: kubernetes.io/hostname
查看pod状态:
kubectl get pods pod-podantiaffinity-requred -n dev -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
pod-podantiaffinity-requred 1/1 Running 0 27s 192.168.104.5 node2 <none> <none>
发现,目标pod被调度到node2节点上,我们的参照pod被调度在node1上,说明和我们预期的效果一致。
三、污点和容忍
1、污点
前面的调度方式都是站在Pod的角度上,通过在Pod上添加属性,来确定Pod是否要调度到指定的Node上,其实我们也可以站在Node的角度上,通过在Node上添加污点属性
,来决定是否运行Pod调度过来。
Node被设置了污点之后就和Pod之间存在了一种相斥的关系,进而拒绝Pod调度进来,甚至可以将已经存在的Pod驱逐出去。
污点的格式为:key=value:effect
,key和value是污点的标签,effect描述污点的作用,支持如下三个选项:
1、PreferNoSchedule
:Kubernetes将尽量避免把Pod调度到具有该污点的Node上,除非没有其他节点可以调度。
2、NoSchedule
:Kubernetes将不会把Pod调度到具有该污点的Node上,但是不会影响当前Node上已经存在的Pod。
3、NoExecute
:Kubernetes将不会把Pod调度到具有该污点的Node上,同时也会将Node上已经存在的Pod驱逐。
污点相关语法:
-
设置污点
kubectl taint node xxx key=value:effect
-
去除污点
kubectl taint node xxx key:effect-
-
去除所有污点
kubectl taint node xxx key-
-
查看指定节点上的污点
kubectl describe node 节点名称
下面通过案例来进行演示污点。
为了方便操作,先暂时停掉node2节点。
在node2上执行下面命令,停掉node2:
kubeadm reset
在master节点上进行查看节点状态:
kubectl get node
NAME STATUS ROLES AGE VERSION
master Ready master 147m v1.18.0
node1 Ready <none> 146m v1.18.0
node2 NotReady <none> 146m v1.18.0
发现node2节点已经停掉了,接着我们为node1添加PreferNoSchedule
污点:
kubectl taint node node1 tag=Negan:PreferNoSchedule
创建一个pod1,并查看pod的状态:
kubectl get pod pod1 -n dev -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
pod1 1/1 Running 0 16s 192.168.166.136 node1 <none> <none>
发现pod1正常运行,并且被调度到node1节点上。
给node1更换NoSchedule
污点
# 去掉node1上原有的污点
kubectl taint node node1 tag:PreferNoSchedule-
# 添加新污点
kubectl taint node node1 tag=Negan:NoSchedule
创建pod2,正常情况下,新创建的pod不能被调度到node1上,原有的pod不受影响。
# 创建pod2
kubectl run pod2 --image=nginx:1.17.1 -n dev
# 查看状态,与我们预期的结果一致
kubectl get pod -n dev -o wide
NAME READY STATUS RESTARTS AGE IP NODE
...... 省略部分内容
pod1 1/1 Running 0 6m5s 192.168.166.136 node1 <none> <none>
pod2 0/1 Pending 0 14s <none> <none> <none> <none>
给node1更换NoExecute
污点:
# 给node1更换污点NoExecute
kubectl taint node node1 tag:NoSchedule-
kubectl taint node node1 tag=Negan:NoExecute
查看namespace=dev
下所有pod的状态:
kubectl get pod -n dev
NAME READY STATUS RESTARTS AGE
pod-nodeaffinity-preferred 1/1 Terminating 1 128m
pod-nodeaffinity-required 0/1 Terminating 1 132m
pod-podaffinity-prefer 1/1 Terminating 0 36m
pod-podaffinity-requred 0/1 Terminating 0 85m
pod-podaffinity-target 0/1 Terminating 0 90m
pod-podantiaffinity-requred 1/1 Terminating 0 26m
pod1 0/1 Terminating 0 12m
pod2 0/1 Terminating 0 6m13s
发现所有的Pod的状态都变为了Terminating
。
说明
使用kubeadm搭建的集群,默认就会给Master节点添加一个污点标记,所以Pod就不会调度到Master节点上
2、容忍
上面介绍了污点的作用,我们可以在Node上添加污点用来拒绝Pod调度上来,但是如果就是想让一个Pod调度到一个有污点的Node上去,这时候应该怎么做?这就需要使用到容忍。
污点就是拒绝,容忍就是忽略,Node通过污点拒绝Pod调度上去,Pod通过容忍忽略拒绝。
容忍详细配置:
kubectl explain pod.spec.tolerations
......
FIELDS:
key # 对应着要容忍的污点的键,空意味着匹配所有的键
value # 对应着要容忍的污点的值
operator # key-value的运算符,支持Equal和Exists(默认)
effect # 对应污点的effect,空意味着匹配所有影响
tolerationSeconds # 容忍时间, 当effect为NoExecute时生效,表示pod在Node上的停留时间
当operator为Equal的时候,如果Node节点有多个Taint,那么Pod每个Taint都需要容忍才能部署上去。
当operator为Exists的时候,有如下的三种写法:
-
容忍指定的污点,污点带有指定的effect:
tolerations: # 容忍 - key: "tag" # 要容忍的污点的key operator: Exists # 操作符 effect: NoExecute # 添加容忍的规则,这里必须和标记的污点规则相同
-
容忍指定的污点,不考虑具体的effect:
tolerations: # 容忍 - key: "tag" # 要容忍的污点的key operator: Exists # 操作符
-
容忍一切污点(慎用):
tolerations: # 容忍 - operator: Exists # 操作符
在上面的污点示例中,已经给node1打上了NoExecute的污点,此时任何Pod是调度不上去的,可以通过在Pod中添加容忍,将Pod调度上去。
创建pod-toleration.yaml文件,内容如下:
apiVersion: v1
kind: Pod
metadata:
name: pod-toleration
namespace: dev
spec:
containers: # 容器配置
- name: nginx
image: nginx:1.17.1
imagePullPolicy: IfNotPresent
ports:
- name: nginx-port
containerPort: 80
protocol: TCP
tolerations: # 容忍
- key: "tag" # 要容忍的污点的key
operator: Equal # 操作符
value: "Negan" # 要容忍的污点的value
effect: NoExecute # 添加容忍的规则,这里必须和标记的污点规则相同
查看pod状态:
kubectl get pods pod-toleration -n dev
NAME READY STATUS RESTARTS AGE
pod-toleration 1/1 Running 0 47s