Mr. Cappuccino的第41杯咖啡——Kubernetes之Pod调度策略

默认情况下，Scheduler计算出一个Pod运行在哪个Node节点上，我们也可以直接指定该Pod运行在哪个Node节点上。

Pod的4种调度策略

1. 自动调度：Pod运行在哪个节点完全由Scheduler经过一系列算法计算得出；
2. 定向调度：采用nodeName、nodeSelector来实现Pod定向调度
3. 亲和性调度：NodeAffinityinity、PodAffinity、PodAntiAffinity
4. 污点、容忍调度：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-schedulernamespace: bubble-dev
spec:containers:- name: nginx-containerimage: nginx:1.17.9nodeName: 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-schedulernamespace: bubble-dev
spec:containers:- name: nginximage: nginx:1.17.9nodeSelector: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-requirednamespace: bubble-dev
spec:containers: - name: nginximage: nginx:1.17.9affinity: # 设置亲和性nodeAffinity: # node亲和性requiredDuringSchedulingIgnoredDuringExecution: # 硬限制nodeSelectorTerms:- matchExpressions: # 匹配标签中含有nodev=v3或nodev=v4的node节点- key: nodevoperator: Invalues: ["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-preferrednamespace: bubble-dev
spec:containers: - name: nginximage: nginx:1.17.9affinity: # 设置亲和性nodeAffinity: # node亲和性preferredDuringSchedulingIgnoredDuringExecution: # 软限制- weight: 1preference:matchExpressions: # 匹配标签中含有nodev=v3或nodev=v4的node节点- key: nodevoperator: Invalues: ["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-v1namespace: bubble-devlabels:podv: v1 # 设置标签
spec:containers:- name: nginximage: nginx:1.17.9nodeName: node1---
apiVersion: v1 
kind: Pod
metadata:name: pod-v2namespace: bubble-devlabels:podv: v2 # 设置标签
spec:containers:- name: nginximage: nginx:1.17.9nodeName: node2---apiVersion: v1
kind: Pod
metadata:name: pod-affinitynamespace: bubble-dev
spec:containers:- name: nginximage: nginx:1.17.9affinity: # 设置亲和性podAffinity: # pod亲和性requiredDuringSchedulingIgnoredDuringExecution: # 硬限制- labelSelector:matchExpressions: # 匹配标签中含有podv=v1的pod- key: podvoperator: Invalues: ["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-antiaffinitynamespace: bubble-dev
spec:containers:- name: nginximage: nginx:1.17.9affinity: # 设置亲和性podAntiAffinity: # pod反亲和性requiredDuringSchedulingIgnoredDuringExecution: # 硬限制- labelSelector:matchExpressions: # 匹配标签中含有podv=v1的pod- key: podvoperator: Invalues: ["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-tolerationsnamespace: bubble-dev
spec:containers:- name: nginximage: nginx:1.17.9tolerations:				# 设置容忍，与containers同级，容忍是针对pod而言的- key: "dedicated"		# 对应node上要容忍污点的键，空则表示匹配所有键value: "special-user"	# 对应要容忍污点的值operator: "Equal"		# 运行符，有两个参数Equal和Exists(默认)，如果设置为Exists时，不需要写valueeffect: "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-testnamespace: bubble-dev
spec:containers:- name: nginximage: nginx:1.17.9tolerations:				# 设置容忍，与containers同级，容忍是针对pod而言的- key: "dedicated"		# 对应node上要容忍污点的键，空则表示匹配所有键value: "special-root"	# 对应要容忍污点的值operator: "Equal"		# 运行符，有两个参数Equal和Exists(默认)，如果设置为Exists时，不需要写valueeffect: "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