K8s pod 调度策略
一.通过node标签调度
1.给node节点打上标签
dockerfile
# 添加标签
kubectl label nodes node01 zone=sh
# 删除标签
kubectl label nodes node01 zone=sh-
#查看标签
kubectl label nodes --show-labels
2.通过nodeSelectro 调度pod
- nodeSelectro为硬限制,必须要满足的条件有:指定标签和值。
dockerfile
apiVersion: v1
kind :Pod
metadata:
name: nginx
labels:
env: test
spec:
containers:
- name: nginx
image: nginx
imagePullPolicy: IfNotPresent
nodeSelector: # 硬限制
disktype: ssd # 只会把pod调度到node标签为disktype=ssd的节点上
二.Node 间亲和性(Affinity)调度
- Affinity [əˈfɪnəti]/anti-affinity node 相对于nodeSelector机制更加的灵活和丰富
- 表达的语法:支持In,NotIn,Exists,DoesNotExist,Gt,Lt.匹配标签的方式
- 支持soft(preference)和hard(requirement),
- hard表示pod sheduler到某个node上时必须满足的亲和性设置.
- soft表示scheduler的时候,当无法满足节点的时候,会选择非 nodeSelector 匹配的节点.
- requiredDuringSchedulingIgnoredDuringExecution 硬亲和性 必须满足亲和性
- preferredDuringSchedulingIgnoredDuringExecution 软亲和性 能满足最好,不满足也没关系。
- nodeAffinity 的基础上添加多个 nodeSelectorTerms 字段,调度的时候 Node 只需要 nodeSelectorTerms 中的某一个符合条件就符合 nodeAffinity 的规则.在nodeSelectorTerms 中添加 matchExpressions,需要可以调度的Node是满足 matchExpressions 中表示的所有规则.
- 需要注意的是preferredDuringSchedulingIgnoredDuringExecution和requiredDuringSchedulingIgnoredDuringExecution名字中后半段字符串IgnoredDuringExecution表示的是,在Pod资源基于节点亲和性规则调度到某个节点之后,如果节点的标签发生了改变,调度器不会将Pod对象从该节点上移除,因为该规则仅对新建的Pod对象有效。
1.硬亲和性
- 硬亲和性是强制性的规则,Pod调度时必须满足的规则。
- 如果存在满足硬亲和性规则的节点,Pod将被调度至该节点;否则,Pod将无法正常调度,处于Pending状态。
dockerfile
apiVersion: v1
kind: Pod
metadata:
name:pod-node
labels:
app: myapp
tier: frontend
spec:
containers:
- name: myapp
image: ikubernetes/myapp:v1
affinity: # 亲和性
nodeAffinity: # 节点亲和性设置
requiredDuringSchedulingIgnoredDuringExecution: # 硬亲和条件
nodeSelectorTerms: # 使用node硬限制条件标签
- matchExpressions: # 一个或多个匹配规则 用于筛选节点。
- key: zone # 匹配的lable键
operator: In # 匹配逻辑
values: # 匹配标签的值
- foo
- bar
# 在启动这个pod时需要给node加上指定的标签
[root@master01 ~]# kubectl label node node01 zone=foo
2.软亲和性
- 软亲和性允许Pod对象定义针对一组可以调度于其上的节点的偏好,调度器会尽量满足此需求,但在无法满足调度需求时,它会退而求其次地选择一个不匹配规则的节点。
- 优化Pod的调度,以便将Pod调度到满足特定条件的节点上,从而实现更高效的资源利用、提高容错性和性能等方面的需求。
dockerfile
apiVersion: v1
kind: Pod
metadata:
name: pod-node2
labels:
app: myapp
tier: frontend
spec:
containers:
- name: myapp
image: ikubernetes/myapp:v1
affinity: # 亲和性
nodeAffinity: # 节点亲和性设置
preferredDuringSchedulingIgnoredDuringExecution: # 软亲和条件
- preference: # 每个偏好项
matchExpressions: # 一个或多个匹配规则 用于筛选节点
- key: zone
operator: In
values:
- foo
- bar
weight: 60 # 权重值 范围1-100 数字越高优先级越高
- preference:
matchExpressions:
- key: zone1
operator: In
values:
- foo1
- bar1
weight: 10
3.软硬亲和性同时存在
- 当软硬亲和性同时存在时,硬亲和性具有更高的优先级。调度器会首先检查硬亲和性规则,如果找到满足条件的节点,则将该Pod调度到该节点上。
- 如果找不到满足硬亲和性规则的节点,Pod将处于Pending状态,直到找到满足条件的节点或超时。
dockerfile
apiVersion: v1
kind: Pod
metadata:
name: with-node
spec:
containers:
- name: with-node-affinity
image: nginx
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: zone
operator: In
values:
- dev
preferredDuringSchedulingIgnoredDuringExecution:
- weight: 1
preference:
matchExpressions:
- key: disktype
operator: In
values:
- ssd
三.Pod 间的亲和性和反亲和性(Affinity/AntiAffinity)调度
基于已经运行在 Node 上 pod 的 labels 来决定需要新创建的Pods是否可以调度到node节点上,配置的时候可以指定那个namespace中的pod需要满足pod的亲和性.可以通过 topologyKey 来指定 topology domain, 可以指定为 node/cloud provider zone 的范围.
-
表达的语法:支持In, NotIn, Exists, DoesNotExist
-
Pod的亲和性和反亲和性可以分成
- requiredDuringSchedulingIgnoredDuringExecution # 硬要求
- preferredDuringSchedulingIgnoredDuringExecution #软要求
-
labelSelector : 选择跟那组Pod亲和
-
namespaces : 选择哪个命名空间
-
topologyKey : 指定节点上的哪个键,可以设置成如下几种类型(节点标签) 1、标签是不是存在(硬性),2、节点key的值相同的情况下只启动一个 , 应用场景 ,高可用 上海,北京, 广州 zone=beijing 多个node1-10 zone=shanghai 多个node11-20 zone=guangzhou 多个node21-30 rediis 3个节点 夸区高可用部署
- kubernetes.io/hostname #Node
- failure-domain.beta.kubernetes.io/zone #Zone
- 可以设置node上的label的值来表示node的name,zone,region等信息,pod的规则中指定topologykey的值表示指定topology 范围内的 node 上运行的 pod 满足指定规则
1.pod亲和性
- Pod反亲和性场景,当应用服务A和数据库服务B要求尽量不要在同一台节点上的时候。
dockerfile
apiVersion: v1
kind: Pod
metadata:
name: pod-first
labels:
app: myapp
tier: frontend
spec:
containers:
- name: myapp
image: ikubernetes/myapp:v1
---
apiVersion: v1
kind: Pod
metadata:
name: pod-second
labels:
app: db
tier: db
spec:
containers:
- name: busybox
image: busybox
imagePullPolicy: IfNotPresent
command: ["sh","-c","sleep 3600"]
affinity:
podAffinity: # 亲和性调度策略
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchExpressions:
- {key: app, operator: In, values: ["myapp","app"]}
topologyKey: kubernetes.io/hostname
# 运行会发现这两个pod在同一个节点上。
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
pod-first 1/1 Running 0 11s 10.233.113.44 node02 <none> <none>
pod-second 1/1 Running 0 6s 10.233.113.45 node02 <none> <none>
2.pod反亲和性
- Pod反亲和性场景,当应用服务A和数据库服务B要求尽量不要在同一台节点上的时候。
dockerfile
apiVersion: v1
kind: Pod
metadata:
name: pod-first-web
labels:
app: web
spec:
containers:
- name: myapp
image: ikubernetes/myapp:v1
---
apiVersion: v1
kind: Pod
metadata:
name: pod-second
labels:
app: backend
tier: db
spec:
containers:
- name: busybox
image: busybox:latest
imagePullPolicy: IfNotPresent
command: ["sh","-c","sleep 3600"]
affinity:
podAntiAffinity: # 反亲和性调度策略
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchExpressions:
- {key: app, operator: In, values: ["myapp", "web", "mysql"]}
topologyKey: kubernetes.io/hostname
# 运行会发现这两个pod不在同一个节点上
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
pod-first-web 1/1 Running 0 31s 10.233.82.52 node01 <none> <none>
pod-second 1/1 Running 0 8s 10.233.113.48 node02 <none> <none>
3.pod亲和性和反亲和性
dockerfile
# 给node01 和node02 打上标签
[root@master01 ~]# kubectl label node node01 zone=test1
node/node01 labeled
[root@master01 ~]# kubectl label node node02 zone=test
node/node02 labeled
apiVersion: v1
kind: Pod
metadata:
name: pod-test1
labels:
security: S1
spec:
containers:
- name: myapp
image: ikubernetes/myapp:v1
nodeSelector:
zone: test1
---
apiVersion: v1
kind: Pod
metadata:
name: pod-test2
labels:
security: S1
spec:
containers:
- name: myapp
image: ikubernetes/myapp:v1
nodeSelector:
zone: test
---
apiVersion: v1
kind: Pod
metadata:
name: pod-test3
labels:
security: S2
spec:
containers:
- name: myapp
image: ikubernetes/myapp:v1
nodeSelector:
zone: test
---
apiVersion: v1
kind: Pod
metadata:
name: pod-first
labels:
security: S2
tier: frontend2
spec:
containers:
- name: myapp
image: ikubernetes/myapp:v1
nodeSelector:
zone: test1
---
apiVersion: v1
kind: Pod
metadata:
name: with-pod-affinity
spec:
affinity:
podAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchExpressions:
- key: security
operator: In
values:
- S1
topologyKey: kubernetes.io/hostname
podAntiAffinity:
preferredDuringSchedulingIgnoredDuringExecution:
- weight: 100
podAffinityTerm:
labelSelector:
matchExpressions:
- key: security
operator: In
values:
- S2
topologyKey: kubernetes.io/hostname # 在反亲和性的条件下做判断,区分不同拓扑域,每个拓扑域做反亲和
containers:
- name: with-pod-affinity
image: nginx
# 例子中指定了pod的亲和性和反亲和性,指定的规则是pod将会调度到的node尽量会满足如下条件:
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
pod-first 1/1 Running 0 7s 10.233.82.58 node01 <none> <none>
pod-test1 1/1 Running 0 7s 10.233.82.57 node01 <none> <none>
pod-test2 1/1 Running 0 7s 10.233.113.53 node02 <none> <none>
pod-test3 1/1 Running 0 7s 10.233.113.54 node02 <none> <none>
with-pod-affinity 1/1 Running 0 7s 10.233.113.55 node02 <none> <none>
1)、podAffinity 亲和性要求满足
- node上具有 kubernetes.io/hostname区域,并且 node 上运行有一个pod 包含标签 label为securtity=S1.
2)、podAntiAffinity 反亲和性要求满足
- 不会调度 pod 到运行包含有 security=S2 的 pod 的 node上.
- 如果这里将topologyKey= kubernetes.io/hostname,那么 pod 将不会调度到 node
- 满足的条件是:node上具有 kubernetes.io/hostname 相同的 value,并且这些相同 zone下的 node 上运行有 security=S2 的 pod
3)、对于topologyKey字段具有如下约束 第一步 要配置有key (节点标签名), 第二步这个标签相同值的节点只能启动一个pod zone=cd
- topologyKey 定义pod亲和性调度和反亲和性调度中需要各个相关的pod对象是否运行于"同一位置",指定"同一位置" 是通过 topologyKey 来定义的,topologyKey 对应的值是 node 上的一个标签名称
- 如果topologyKey指定区域已经在运行一个或多个满足LabelSelector规则的Pod,则该Pod应该(或者在非亲和性的情况下不应该)在 topologyKey 中运行
- 对于亲和性和 反亲和性 requiredDuringSchedulingIgnoredDuringExecution (硬亲和),topologyKey 不能为空。
- 对于 反亲和 性 requiredDuringSchedulingIgnoredDuringExecution(硬亲和) ,引入 LimitPodHardAntiAffinityTopology 准入控制器来限制 topologyKey 只能是 kubernetes.io/hostname。如果要使用自定义拓扑域,则需要修改准入控制器,或者直接禁用它。
- 对于反亲和性 preferredDuringSchedulingIgnoredDuringExecution (软亲和),空的 topologyKey 表示所有拓扑域,没有限制。
- topologyKey 除上述情况外,可以是 node 任何合法的标签 key。规则中可以指定匹配pod所在namespace,如果定义了但是为空,它表示所有namespace范围内的pod.
- 所有关联requiredDuringSchedulingIgnoredDuringExecution(硬亲和)的matchExpressions全都满足之后,系统才能将pod调度到某个node上。
4.topologKey 调度
需求:当前有两个机房( beijing,shanghai),需要部署一个nginx产品,副本为两个,为了保证机房容灾高可用场景,需要在两个机房分别部署一个服务器
dockerfile
# 给node分别打上beijing 和shanghai的标签
[root@master01 ~]# kubectl label node node01 zone=beijing
node/node01 labeled
[root@master01 ~]# kubectl label node node02 zone=shanghai
node/node02 labeled
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-affinity-test
spec:
replicas: 2
selector:
matchLabels:
service: nginx
template:
metadata:
name: nginx
labels:
service: nginx
spec:
affinity:
podAntiAffinity: # 反亲和
requiredDuringSchedulingIgnoredDuringExecution: # 硬亲和标签
- labelSelector:
matchExpressions:
- key: service
operator: In
values:
- nginx
topologyKey: zone # 在反亲和性的条件定义为zone键下做判断,区分不同拓扑域,每个拓扑域做反亲和
containers:
- name: nginx
image: busybox:latest
command: ["sh","-c","sleep 3600"]
# 两个node上分别有zone标签,来标注自己属于哪个机房,topologyKey定义为zone,pod所以在调度的时候,会根据node上zone标签来区分拓扑域,当前用的上 反亲和性调度 根据拓扑纬度调度,beijing机房调度完一个pod后,然后控制器判断beijing 拓扑域已经有server=nginx标签的pod,就在下一个拓扑域的node上调度了
# 可以看到俩个pod通过toplogyKey匹配到了不同的node下
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
nginx-affinity-test-6d68d588cd-27xnj 1/1 Running 0 8s 10.233.82.59 node01 <none> <none>
nginx-affinity-test-6d68d588cd-qkfj4 1/1 Running 0 8s 10.233.113.56 node02 <none> <none>
四.Pod亲和性调度常用场景
1.pod反亲和性调度
创建了一个Deployment,副本数为3,指定了反亲和规则如上所示,pod的label为app:store,那么pod调度的时候将不会调度到node上已经运行了label为app:store的pod了,这样就会使得Deployment的三副本分别部署在不同的host的node上
dockerfile
apiVersion: apps/v1
kind: Deployment
metadata:
name: redis-cache
spec:
replicas: 3 # 必须有对应的节点数(master不能创建pod)
selector:
matchLabels:
app: store
template:
metadata:
labels:
app: store
spec:
affinity:
podAntiAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchExpressions:
- key: app
operator: In
values:
- store
topologyKey: "kubernetes.io/hostname"
containers:
- name: redis-server
image: redis:3.2-alpine
# 每个节点保证有一个pod 必须满足这个 pod 有 app = store 这样的标签,如果存在这样的 pod 就不满足要求
2.pod亲和性调度
在一个例子中基础之上,要求pod的亲和性满足 requiredDuringSchedulingIgnoredDuringExecution 中topologyKey="kubernetes.io/hostname",并且 node上需要运行有 app=store 的label.
dockerfile
apiVersion: apps/v1
kind: Deployment
metadata:
name: web-server
spec:
replicas: 4 #必须有对应的节点数(master不能创建pod)
selector:
matchLabels:
app: web-store
template:
metadata:
labels:
app: web-store
spec:
affinity:
podAntiAffinity: # 反亲和性
requiredDuringSchedulingIgnoredDuringExecution: # 硬亲和
- labelSelector:
matchExpressions:
- key: app
operator: In
values:
- web-store
topologyKey: "kubernetes.io/hostname"
podAffinity: # 亲和性
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchExpressions:
- key: app
operator: In
values:
- store
topologyKey: "kubernetes.io/hostname"
containers:
- name: web-app
image: nginx:1.12-alpine
3.pod亲和性调度
在一些应用中,pod副本之间需要共享cache,需要将pod运行在一个节点之上
dockerfile
apiVersion: apps/v1
kind: Deployment
metadata:
name: web-server
spec:
replicas: 3
template:
metadata:
labels:
app: web-store
spec:
affinity:
podAffinity: # 亲和性
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchExpressions:
- key: app
operator: In
values:
- web-store
topologyKey: "kubernetes.io/hostname"
containers:
- name: web-app
image: nginx
五.污点容忍调度(Taint和Toleration)
污点(Taints)和污点容忍(Tolerations)是 Kubernetes(k8s)中用于节点调度的另一种重要机制。以下是对污点容忍调度的详细解释:
1、污点(Taints)
污点是定义在节点上的键值型属性数据,用于让节点拒绝将 Pod 调度运行于其上,除非 Pod 有接纳节点污点的容忍度。污点可以使节点能够排斥一类特定的 Pod,避免 Pod 调度到特定节点上。
污点的格式:
dockerfile
key=value:effect
key 和 value 是污点的标签。
effect 描述污点的作用,支持以下三个选项:
NoSchedule:Pod 将不会被调度到具有该污点的节点上,但已经正在运行中的 Pod 不受影响。
PreferNoSchedule:Pod 将尽量避免调度到具有该污点的节点上,已经正在运行中的 Pod 不受影响。
NoExecute:Pod 将不会被调度到具有该污点的节点上,同时将节点上已经存在的 Pod 进行驱逐。如果因节点污点变动或 Pod 容忍度变动而不再满足匹配规则,Pod 对象将被驱逐。
# 添加污点:
kubectl taint nodes <node-name> key=value:effect
# 删除污点:
kubectl taint nodes <node-name> key[:effect]-(effect 可以省略)
2、污点容忍(Tolerations)
污点容忍是定义在 Pod 上的键值型属性数据,用于配置 Pod 可容忍的污点。调度器只能将 Pod 调度到该 Pod 能够容忍的污点的节点上。
dockerfile
# 污点容忍的格式:
在 Pod 的 spec 字段中定义 tolerations 列表,每个 toleration 都包含 key、operator、value 和 effect 字段。
key:污点的键。
operator:操作符,可以是 Equal(等于)或 Exists(存在)。Equal 表示污点的键和值都必须匹配,Exists 表示只需匹配键即可。
value:污点的值(当 operator 为 Equal 时需要)。
effect:污点的作用效果,必须与节点上的污点效果匹配。
# 使用污点容忍:
如果 Pod 想被调度到具有特定污点的节点上,必须在该 Pod 的定义中添加与该污点匹配的容忍度。
容忍度允许调度但并不保证调度,即使 Pod 具有容忍度,调度器仍然会根据其他调度策略(如亲和性、资源限制等)来决定是否将 Pod 调度到该节点上。
# 应用场景
1. 维护节点:当需要对某个节点进行维护时,可以给该节点添加一个污点,以阻止新的 Pod 被调度到该节点上。同时,可以给需要继续在该节点上运行的 Pod 添加相应的容忍度。
2. 隔离特定工作负载:可以使用污点和容忍度来隔离特定的工作负载,确保它们不会与其他工作负载混合在一起运行。
3. 利用专用硬件:如果集群中有一些节点配备了专用硬件(如 GPU),可以使用污点和容忍度来确保只有特定的 Pod 能够被调度到这些节点上。
3.污点与容忍度匹配规则
- 当Pod的容忍度与节点的污点在键、值(当操作符为Equal时)和效应上完全匹配时,Pod可以被调度到该节点上。
- 如果Pod的容忍度使用Exists操作符,则只需匹配键和效应,无需匹配值。
- Pod可以具有多个容忍度,以匹配节点上的多个污点。
4.操作实例
dockerfile
# 为节点添加污点
[root@master01 ~]# kubectl taint nodes node01 special=gpu:NoSchedule
node/node01 tainted
[root@master01 ~]# kubectl taint nodes node02 node-type=dev:NoSchedule
node/node02 tainted
# 查看节点污点命令
[root@master01 ~]# kubectl describe nodes |grep Taint -A 2
Taints: node-role.kubernetes.io/control-plane:NoSchedule
Unschedulable: false
Lease:
--
Taints: special=gpu:NoSchedule
Unschedulable: false
Lease:
--
Taints: node-type=dev:NoSchedule
Unschedulable: false
Lease:
apiVersion: v1
kind: Pod
metadata:
name: mypod
spec:
containers:
- name: nginx
image: nginx
tolerations:
- key: "special"
operator: "Equal"
value: "gpu"
effect: "NoSchedule"
# 可以看到pod匹配到了可以容忍的污点上
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
mypod 1/1 Running 0 5s 10.233.113.58 node01 <none> <none>
5.设置容忍时间
- 污点容忍时间,主要涉及的是当节点被设置了NoExecute类型的污点时,Pod如果没有相应的容忍度,则会被驱逐出该节点。然而,如果Pod具有对应的容忍度,并且容忍度中设置了tolerationSeconds字段,那么Pod在被驱逐前还可以在节点上继续运行一段时间。tolerationSeconds字段指定了Pod在节点上可以继续运行的时间(单位为秒),这相当于给Pod一个宽限期,让其有时间完成必要的清理工作或等待其他操作完成。
dockerfile
# 假如有一个节点被设置成NoExecute
kubectl taint nodes node-1 key=value:NoExecute
# 此时,如果一个Pod想要被调度到该节点上,并且希望在被驱逐前有3600秒的宽限期,那么它需要在容忍度中设置如下内容:
tolerations:
- key: "key"
operator: "Equal"
value: "value"
effect: "NoExecute"
tolerationSeconds: 3600
# 这样,当Pod被调度到该节点上时,如果节点出现了NoExecute类型的污点,Pod仍然可以在节点上继续运行3600秒,然后才会被驱逐。
# 污点容忍时间在Kubernetes中主要用于控制Pod在被驱逐前的运行时间,以确保Pod有足够的时间完成必要的操作。通过合理设置tolerationSeconds字段的值,可以满足不同的业务需求。
6.污点驱逐
边我们提到了污点的effect可以设置为 NoExecute,它会影响节点上已经运行的pod,如下所示:
- 立即将没有配置容忍的pod逐出。
- 设置容忍但是没有指定 tolerationSeconds 参数的,那么该容忍永久生效。
- 设置容忍但是有指定 tolerationSeconds 参数的,那么在指定的时间内,容忍有效,超出指定时间后将被剔除。
此外,当某些条件为true时,节点控制器会自动污染节点。也就是k8s的内置污点:
- node.kubernetes.io/not-ready: 节点尚未准备好。这对应于NodeCondition Ready为false。
- node.kubernetes.io/unreachable: 无法从节点控制器访问节点。这对应于NodeCondition Ready 为Unknown。
- 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: 当kubelet从 "外部" 云提供程序开始时,此污点在节点上设置为将其标记为不可用。来自cloud-controller-manager的控制器初始化此节点后,kubelet删除此污点。