Kubernetes之Pod调度策略
- Pod的4种调度策略
- 定向调度
- nodeName
- nodeSelector
- 亲和性调度
- node亲和性
- 硬限制
- 软限制
- 关系运算符
- pod亲和性
- pod反亲和性
- 污点和容忍
- 污点(taints)
- 容忍(tolerations)
默认情况下,Scheduler计算出一个Pod运行在哪个Node节点上,我们也可以直接指定该Pod运行在哪个Node节点上。
Pod的4种调度策略
- 自动调度:Pod运行在哪个节点完全由Scheduler经过一系列算法计算得出;
- 定向调度:采用nodeName、nodeSelector来实现Pod定向调度
- 亲和性调度:NodeAffinityinity、PodAffinity、PodAntiAffinity
- 污点、容忍调度:Taints、Toleration
定向调度
通过在定义Pod时,设置nodeName、nodeSelector等字段来实现Pod定向调度到指定的节点上。
nodeName
nodeName用于将Pod调度到指定(强制约束)的Node节点上,跳过Scheduler的调度逻辑,直接将Pod调度到指定的Node节点上,如果指定的Node不存在,也会继续往上调度,只不过Pod将会运行失败。
cat /etc/hosts
apiVersion: v1
kind: Pod
metadata:
name: pod-scheduler
namespace: bubble-dev
spec:
containers:
- name: nginx-container
image: nginx:1.17.9
nodeName: node2 # 指定该pod运行在node2节点
kubectl create ns bubble-dev
vi pod-scheduler.yaml
cat pod-scheduler.yaml
kubectl create -f pod-scheduler.yaml
kubectl describe pods -n bubble-dev
nodeSelector
nodeSelector用于将Pod调度到指定标签上的Node节点,它通过k8s的标签选择器实现,也就是说,Scheduler使用MathNodeSelector调度策略进行Label匹配,找出目标Node,然后将Pod调度到目标节点,该匹配规则也是强制约束,即如果没有匹配到满足条件的Node节点,也会继续往上调度,只不过Pod将会运行失败。
kubectl get nodes --show-labels
给Node节点创建标签
kubectl label nodes node1 nodev=v1
kubectl label nodes node2 nodev=v2
apiVersion: v1
kind: Pod
metadata:
name: pod-scheduler
namespace: bubble-dev
spec:
containers:
- name: nginx
image: nginx:1.17.9
nodeSelector:
nodev: v2 # 指定该pod运行到标签为nodev=v2的node节点上
kubectl delete ns bubble-dev
kubectl create ns bubble-dev
vi pod-scheduler.yaml
cat pod-scheduler.yaml
kubectl create -f pod-scheduler.yaml
kubectl describe pods -n bubble-dev
亲和性调度
nodeName和nodeSelector都属于定向调度,都是强制性的,即如果没有Node匹配上,Pod就会运行失败,这显然太过于死板,不够圆滑,所以Kubernetes还提供了亲和性调度。
亲和性调度是在nodeSelector的基础上进行了扩展,通过配置的形式,实现优先选择满足条件的Node进行调度,如果没有,也可以调度到不满足条件的节点上,实现调度更加灵活。
nodeAffinity(node亲和性):以node为目标,解决pod可以调度到哪些node的问题;
podAffinity(pod亲和性):以某个pod为目标将pod调度到其附近,解决pod可以和哪些已存在的pod部署在同一个拓扑域中的问题;
podAntiAffinity(pod反亲和性):以pod为目标,解决pod不可以和哪些已存在的pod部署在同一个拓扑域中的问题;
node亲和性
硬限制
通过指定的规则,如果没有找到具体运行的Node节点,则会报错。
apiVersion: v1
kind: Pod
metadata:
name: pod-required
namespace: bubble-dev
spec:
containers:
- name: nginx
image: nginx:1.17.9
affinity: # 设置亲和性
nodeAffinity: # node亲和性
requiredDuringSchedulingIgnoredDuringExecution: # 硬限制
nodeSelectorTerms:
- matchExpressions: # 匹配标签中含有nodev=v3或nodev=v4的node节点
- key: nodev
operator: In
values: ["v3" , "v4"]
kubectl delete ns bubble-dev
kubectl create ns bubble-dev
vi pod-required.yaml
cat pod-required.yaml
kubectl create -f pod-required.yaml
kubectl describe pods -n bubble-dev
软限制
优先走指定的规则,如果没有找到具体运行的Node节点,则会采用随机分配的方式将Pod运行在Node节点上。
apiVersion: v1
kind: Pod
metadata:
name: pod-preferred
namespace: bubble-dev
spec:
containers:
- name: nginx
image: nginx:1.17.9
affinity: # 设置亲和性
nodeAffinity: # node亲和性
preferredDuringSchedulingIgnoredDuringExecution: # 软限制
- weight: 1
preference:
matchExpressions: # 匹配标签中含有nodev=v3或nodev=v4的node节点
- key: nodev
operator: In
values: ["v3" , "v4"]
kubectl delete ns bubble-dev
kubectl create ns bubble-dev
vi pod-preferred.yaml
cat pod-preferred.yaml
kubectl create -f pod-preferred.yaml
kubectl describe pods -n bubble-dev
关系运算符
1. In # 在,表示key的值在指定的列表其中一项即可匹配成功;
2. NotIn # 与In相反,表示key的值不在指定的列表,满足的话即表示匹配成功;
3. Exists # 存在,存在是对标签的key而言,表示存在指定的key则表示匹配成功,使用Exists的话不用写value,因为Exists是针对key而言;
4. Gt # greater than的简写,大于的意思,表示大于指定的值则匹配成功;
5. Lt # less than的简写,小于的意思,表示小于指定的值则匹配成功;
6. DoesNotExists # 不存在该标签的节点
pod亲和性
pod亲和性调度也可以分为硬亲和性调度和软亲和性调度,以下案例为硬亲和性调度
apiVersion: v1
kind: Pod
metadata:
name: pod-v1
namespace: bubble-dev
labels:
podv: v1 # 设置标签
spec:
containers:
- name: nginx
image: nginx:1.17.9
nodeName: node1
---
apiVersion: v1
kind: Pod
metadata:
name: pod-v2
namespace: bubble-dev
labels:
podv: v2 # 设置标签
spec:
containers:
- name: nginx
image: nginx:1.17.9
nodeName: node2
---
apiVersion: v1
kind: Pod
metadata:
name: pod-affinity
namespace: bubble-dev
spec:
containers:
- name: nginx
image: nginx:1.17.9
affinity: # 设置亲和性
podAffinity: # pod亲和性
requiredDuringSchedulingIgnoredDuringExecution: # 硬限制
- labelSelector:
matchExpressions: # 匹配标签中含有podv=v1的pod
- key: podv
operator: In
values: ["v1"]
topologyKey: kubernetes.io/hostname
kubectl delete ns bubble-dev
kubectl create ns bubble-dev
vi pod-affinity.yaml
cat pod-affinity.yaml
kubectl create -f pod-affinity.yaml
kubectl describe pods -n bubble-dev
pod-v1运行在node1节点上,pod-v2运行在node2节点上,而pod-affinity会以标签中包含podv=v1的pod为目标调度到其附近,最终pod-affinity也会运行在node1节点上。
pod反亲和性
pod反亲和性调度也可以分为硬反亲和性调度和软反亲和性调度,以下案例为硬反亲和性调度
apiVersion: v1
kind: Pod
metadata:
name: pod-antiaffinity
namespace: bubble-dev
spec:
containers:
- name: nginx
image: nginx:1.17.9
affinity: # 设置亲和性
podAntiAffinity: # pod反亲和性
requiredDuringSchedulingIgnoredDuringExecution: # 硬限制
- labelSelector:
matchExpressions: # 匹配标签中含有podv=v1的pod
- key: podv
operator: In
values: ["v1"]
topologyKey: kubernetes.io/hostname
vi pod-antiaffinity.yaml
cat pod-antiaffinity.yaml
kubectl create -f pod-antiaffinity.yaml
kubectl describe pods -n bubble-dev
pod-antiaffinity会远离标签中包含podv=v1的pod,最终运行在node2节点上。
污点和容忍
污点(taints)
污点,taints是定义在Node节点之上的键值型属性数据,用于让Node节点拒绝将Pod调度运行于其上,除非该Pod对象具有接纳节点污点的容忍度。污点也是我们Pod调度中的一种调度策略,污点作用在Node节点上,当为某个Node节点打上污点,则表示该Node是否允许Pod调度过来,而我们的Master节点上就有一个污点,所以你能看到Pod是不允许调度到Master节点上的。
污点的格式:key=value:effect,key和value是污点的标签,可以自行拟定,effect描述污点的作用,effect支持如下三个选项:
PreferNoSchedul: kubernetes将尽量避免把pod调度到具有该污点的node上,除非没有其他节点可调度;
NoSchedule: kubernetes将不会把pod调度到具有该污点的node上,但不会影响当前node已存在的pod;
NoExecute: kubernetes将不会把pod调度到具有该污点的node上,同时还会驱逐node上已存在的pod;
# 设置污点,指定标签为dedicated=special-user,策略为NoSchedule,如果该标签已存在则更新策略
kubectl taint nodes node1 dedicated=special-user:NoSchedule
# 移除key为dedicated的NoSchedule污点
kubectl taint nodes node1 dedicated:NoSchedule-
# 移除key为dedicated的所有污点
kubectl taint nodes node1 dedicated-
# 查看污点
kubectl describe nodes node1 | grep Taints
容忍(tolerations)
污点的作用是拒绝Pod调度,而容忍定义于Pod上,表示Pod允许Node节点上有污点,并且还会往含有对应污点的节点上调度。
apiVersion: v1
kind: Pod
metadata:
name: pod-tolerations
namespace: bubble-dev
spec:
containers:
- name: nginx
image: nginx:1.17.9
tolerations: # 设置容忍,与containers同级,容忍是针对pod而言的
- key: "dedicated" # 对应node上要容忍污点的键,空则表示匹配所有键
value: "special-user" # 对应要容忍污点的值
operator: "Equal" # 运行符,有两个参数Equal和Exists(默认),如果设置为Exists时,不需要写value
effect: "NoExecute" # 对应污点的effect,空也意味着匹配所有
# tolerationSeconds: 10 # 容忍时间,当且仅当effect为NoExecute时该参数生效,表示pod在node上的停留时间
kubectl taint nodes node1 dedicated=special-user:NoExecute
kubectl taint nodes node2 dedicated=special-user:NoSchedule
vi pod-tolerations.yaml
cat pod-tolerations.yaml
kubectl create -f pod-tolerations.yaml
kubectl describe pods -n bubble-dev
为了方便测试,我们在node1和node2节点上都加上了污点。由于设置的容忍与node1的污点相匹配,所以该pod最终调度到了node1节点上。
如果所有的node节点都不匹配的话,则pod会运行失败。
apiVersion: v1
kind: Pod
metadata:
name: pod-test
namespace: bubble-dev
spec:
containers:
- name: nginx
image: nginx:1.17.9
tolerations: # 设置容忍,与containers同级,容忍是针对pod而言的
- key: "dedicated" # 对应node上要容忍污点的键,空则表示匹配所有键
value: "special-root" # 对应要容忍污点的值
operator: "Equal" # 运行符,有两个参数Equal和Exists(默认),如果设置为Exists时,不需要写value
effect: "NoExecute" # 对应污点的effect,空也意味着匹配所有
# tolerationSeconds: 10 # 容忍时间,当且仅当effect为NoExecute时该参数生效,表示pod在node上的停留时间
vi pod-test.yaml
cat pod-test.yaml
kubectl create -f pod-test.yaml
kubectl describe pods -n bubble-dev