在默认情况下，pod在哪个节点运行，是由Scheduler组件采用相应的算法计算得出的，这个过程是不受人工控制的，但是因为很多情况下我们想控制谋一个pod到某一个节点上就需要k8s对pod的调度规则了。k8s的调度规则提供了四大类。
- 自动调度：运行在哪个节点上完全有Scheduler组件通过算法得出
- 定向调度：NodeName、NodeSelector
- 亲和性调度：NodeAffinity、PodAffinity、PodAntiAffinity
- 污点（容忍）调度：Taints、Toleration
定向调度
定向调度，指的是利用在pod上声明nodeName或者nodeSelector，以此将Pod调度到期望的node节点上。注意，这里的调度是强制的，这就意味着即使要调度的目标Node不存在，也会向上面进行调度，只不过pod运行失败而已。
我们来搞他一下
nodename
vi pod-nodename.yaml
apiVersion: v1
kind: Pod
metadata:
name: pod-nodename
namespace: dev
spec:
containers:
- name: nginx
image: nginx:1.17.1
nodeName: minikube # 指定调度到node1节点上,注意改自己的node名[qq@k8snode1 ~]$ kubectl apply -f pod-nodename.yaml
pod/pod-nodename created
[qq@k8snode1 ~]$ kubectl get -f pod-nodename.yaml
NAME READY STATUS RESTARTS AGE
pod-nodename 1/1 Running 0 11s
成功运行，因为我给的就是我有的节点
我给他改个我没有的node1，他就会创建失败了
我们看一下
[qq@k8snode1 ~]$ kubectl delete -f pod-nodename.yaml
pod "pod-nodename" deleted
vi pod-nodename.yaml
nodeName: node1 我改的这里
[qq@k8snode1 ~]$ kubectl apply -f pod-nodename.yaml
pod/pod-nodename created
[qq@k8snode1 ~]$ kubectl get pod -n dev
NAME READY STATUS RESTARTS AGE
pod-base 1/2 CrashLoopBackOff 9 (3m52s ago) 24m
pod-nodename 0/1 Pending 0 4s
已经是挂起状态了nodeselecror
NodeSelector用于将pod调度到添加了指定标签的node节点上。它是通过kubernetes的label-selector机制实现的，也就是说，在pod创建之前，会由scheduler使用MatchNodeSelector调度策略进行label匹配，找出目标node，然后将pod调度到目标节点，该匹配规则是强制约束。
我们为node添加个标签
[qq@k8snode1 ~]$ kubectl label nodes minikube nodeenv=pro
node/minikube labeled
为node添加labels
[qq@k8snode1 ~]$ kubectl get nodes -A
NAME STATUS ROLES AGE VERSION
minikube Ready control-plane,master 48m v1.23.1
[qq@k8snode1 ~]$ kubectl get nodes --show-labels
查一下node的labels
NAME STATUS ROLES AGE VERSION LABELS
minikube Ready control-plane,master 51m v1.23.1 beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/arch=amd64,kubernetes.io/hostname=minikube,kubernetes.io/os=linux,minikube.k8s.io/commit=3e64b11ed75e56e4898ea85f96b2e4af0301f43d,minikube.k8s.io/name=minikube,minikube.k8s.io/updated_at=2022_03_08T15_29_10_0700,minikube.k8s.io/version=v1.25.1,node-role.kubernetes.io/control-plane=,node-role.kubernetes.io/master=,node.kubernetes.io/exclude-from-external-load-balancers=,nodeenv=pro
vi pod-nodeselector.yaml
apiVersion: v1
kind: Pod
metadata:
name: pod-nodeselector
namespace: dev
spec:
containers:
- name: nginx
image: nginx:1.17.1
nodeSelector:
nodeenv: pro # 指定调度到具有nodeenv=pro标签的节点上
[qq@k8snode1 ~]$ vi pod-nodeselector.yaml
[qq@k8snode1 ~]$ kubectl apply -f pod-nodeselector.yaml
pod/pod-nodeselector created
[qq@k8snode1 ~]$ kubectl get -f pod-nodeselector.yaml
NAME READY STATUS RESTARTS AGE
pod-nodeselector 1/1 Running 0 11s
只会到有nodeenv=pro这个标签的节点上去
[qq@k8snode1 ~]$ kubectl delete -f pod-nodeselector.yaml
pod "pod-nodeselector" deleted
[qq@k8snode1 ~]$ vi pod-nodeselector.yaml
随便改一个标签
nodeenv: prdfffd 这个肯定没有
[qq@k8snode1 ~]$ kubectl apply -f pod-nodeselector.yaml
pod/pod-nodeselector created
[qq@k8snode1 ~]$ kubectl get -f pod-nodeselector.yaml
NAME READY STATUS RESTARTS AGE
pod-nodeselector 0/1 Pending 0 9s
[qq@k8snode1 ~]$ kubectl describe pod pod-nodeselector -n dev
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Warning FailedScheduling 15s (x8 over 7m34s) default-scheduler 0/1 nodes are available: 1 node(s) didn't match Pod's node affinity/selector.
亲和度调度
上一节，介绍了两种定向调度的方式，使用起来非常方便，但是也有一定的问题，那就是如果没有满足条件的Node，那么Pod将不会被运行，即使在集群中还有可用Node列表也不行，这就限制了它的使用场景。
基于上面的问题，kubernetes还提供了一种亲和性调度（Affinity）。它在NodeSelector的基础之上的进行了扩展，可以通过配置的形式，实现优先选择满足条件的Node进行调度，如果没有，也可以调度到不满足条件的节点上，使调度更加灵活。
跟node1亲和度高，如果node1可以被调度就到node1上，如果node1不行node2 也可以
Affinity主要分为三类：
- nodeAffinity(node亲和性）: 以node为目标，解决pod可以调度到哪些node的问题
- podAffinity(pod亲和性) : 以pod为目标，解决pod可以和哪些已存在的pod部署在同一个拓扑域中的问题
- podAntiAffinity(pod反亲和性) : 以pod为目标，解决pod不能和哪些已存在pod部署在同一个拓扑域中的问题
关于亲和性(反亲和性)使用场景的说明：亲和性：如果两个应用频繁交互，那就有必要利用亲和性让两个应用的尽可能的靠近，这样可以减少因网络通信而带来的性能损耗。反亲和性：当应用的采用多副本部署时，有必要采用反亲和性让各个应用实例打散分布在各个node上，这样可以提高服务的高可用性。
NodeAffinity
首先来看一下NodeAffinity的可配置项：
pod.spec.affinity.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: nodeenv # 匹配存在标签的key为nodeenv的节点
operator: Exists
- key: nodeenv # 匹配标签的key为nodeenv,且value是"xxx"或"yyy"的节点
operator: In
values: ["xxx","yyy"]
- key: nodeenv # 匹配标签的key为nodeenv,且value大于"xxx"的节点
operator: Gt
values: "xxx"我们先实验硬限制 requiredDuringSchedulingIgnoredDuringExecution（好长）
vi pod-nodeaffinity-required.yaml
apiVersion: v1
kind: Pod
metadata:
name: pod-nodeaffinity-required
namespace: dev
spec:
containers:
- name: nginx
image: nginx:1.17.1
affinity: #亲和性设置
nodeAffinity: #设置node亲和性
requiredDuringSchedulingIgnoredDuringExecution: # 硬限制
nodeSelectorTerms:
- matchExpressions: # 匹配env的值在["xxx","yyy"]中的标签
- key: nodeenv
operator: In
values: ["xxx","yyy"][qq@k8snode1 ~]$ kubectl apply -f pod-nodeaffinity-required.yaml
pod/pod-nodeaffinity-required created
[qq@k8snode1 ~]$ kubectl get -f pod-nodeaffinity-required.yaml
NAME READY STATUS RESTARTS AGE
pod-nodeaffinity-required 0/1 Pending 0 2m7s
无法启动挂起状态因为本机没有脚xxx，yyy的标签，把他改回去就可以了
[qq@k8snode1 ~]$
修改文件，将values: ["xxx","yyy"]------> ["pro","yyy"]
[qq@k8snode1 ~]$ vi pod-nodeaffinity-required.yaml
[qq@k8snode1 ~]$ kubectl apply -f pod-nodeaffinity-required.yaml
pod/pod-nodeaffinity-required created
[qq@k8snode1 ~]$ kubectl get -f pod-nodeaffinity-required.yaml
NAME READY STATUS RESTARTS AGE
pod-nodeaffinity-required 1/1 Running 0 6s
[qq@k8snode1 ~]$preferredDuringSchedulingIgnoredDuringExecution软限制
vi pod-nodeaffinity-preferred.yaml
apiVersion: v1
kind: Pod
metadata:
name: pod-nodeaffinity-preferred
namespace: dev
spec:
containers:
- name: nginx
image: nginx:1.17.1
affinity: #亲和性设置
nodeAffinity: #设置node亲和性
preferredDuringSchedulingIgnoredDuringExecution: # 软限制
- weight: 1
preference:
matchExpressions: # 匹配env的值在["xxx","yyy"]中的标签(当前环境没有)
- key: nodeenv
operator: In
values: ["xxx","yyy"]
[qq@k8snode1 ~]$ vi pod-nodeaffinity-preferred.yaml
[qq@k8snode1 ~]$ kubectl apply -f pod-nodeaffinity-preferred.yaml
pod/pod-nodeaffinity-preferred created
[qq@k8snode1 ~]$ kubectl get -f pod-nodeaffinity-preferred.yaml
NAME READY STATUS RESTARTS AGE
pod-nodeaffinity-preferred 1/1 Running 0 7sNodeAffinity规则设置的注意事项：
1 如果同时定义了nodeSelector和nodeAffinity，那么必须两个条件都得到满足，Pod才能运行在指定的Node上
2 如果nodeAffinity指定了多个nodeSelectorTerms，那么只需要其中一个能够匹配成功即可
3 如果一个nodeSelectorTerms中有多个matchExpressions ，则一个节点必须满足所有的才能匹配成功
4 如果一个pod所在的Node在Pod运行期间其标签发生了改变，不再符合该Pod的节点亲和性需求，则系统将忽略此变化
podAffinity
PodAffinity主要实现以运行的Pod为参照，实现让新创建的Pod跟参照pod在一个区域的功能。
还是看一下配置项，还是软硬两种限制
pod.spec.affinity.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-100topologyKey用于指定调度时作用域,例如:
如果指定为kubernetes.io/hostname，那就是以Node节点为区分范围
如果指定为beta.kubernetes.io/os,则以Node节点的操作系统类型来区分
还是先演示硬限制后演示软限制
首先用定向调度创建一个参照pod
vi pod-podaffinity-target.yaml
apiVersion: v1
kind: Pod
metadata:
name: pod-podaffinity-target
namespace: dev
labels:
podenv: pro #设置标签
spec:
containers:
- name: nginx
image: nginx:1.17.1
nodeName: minikube # 将目标pod名确指定到minikube上[qq@k8snode1 ~]$ kubectl apply -f pod-podaffinity-target.yaml
pod/pod-podaffinity-target created
[qq@k8snode1 ~]$ kubectl get -f pod-podaffinity-target.yaml
NAME READY STATUS RESTARTS AGE
pod-podaffinity-target 1/1 Running 0 3m9svi pod-podaffinity-required.yaml
apiVersion: v1
kind: Pod
metadata:
name: pod-podaffinity-required
namespace: dev
spec:
containers:
- name: nginx
image: nginx:1.17.1
affinity: #亲和性设置
podAffinity: #设置pod亲和性
requiredDuringSchedulingIgnoredDuringExecution: # 硬限制
- labelSelector:
matchExpressions: # 匹配env的值在["xxx","yyy"]中的标签
- key: podenv
operator: In
values: ["xxx","yyy"]
topologyKey: kubernetes.io/hostname上面的内容是硬限制，新的pod必须要喝拥有xxx或者yyy标签的pod在同一个node，当前环境下，别说没pod了，xxx，yyy这样的标签都没有，所以注定失败
[qq@k8snode1 ~]$ vi pod-podaffinity-required.yaml
[qq@k8snode1 ~]$ kubectl apply -f pod-podaffinity-required.yaml
pod/pod-podaffinity-required created
[qq@k8snode1 ~]$ kubectl get -f pod-podaffinity-required.yaml
NAME READY STATUS RESTARTS AGE
pod-podaffinity-required 0/1 Pending 0 6s
[qq@k8snode1 ~]$我们把
values: ["xxx","yyy"]
改成
values: ["pro","yyy"][qq@k8snode1 ~]$ kubectl delete -f pod-podaffinity-required.yaml
pod "pod-podaffinity-required" deleted
[qq@k8snode1 ~]$ kubectl apply -f pod-podaffinity-required.yaml
pod/pod-podaffinity-required created
[qq@k8snode1 ~]$ kubectl get -f pod-podaffinity-required.yaml
NAME READY STATUS RESTARTS AGE
pod-podaffinity-required 1/1 Running 0 5s
[qq@k8snode1 ~]$
软连接就没什么实验的必要了，就是说没有拥有xxx和yyy标签的pod也可以创建
PodAntiAffinity
PodAntiAffinity是反亲和，以现在已运行的pod为参照不跟参照的pod在同一个区域
vi pod-podantiaffinity-required.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反亲和性
requiredDuringSchedulingIgnoredDuringExecution: # 硬限制
- labelSelector:
matchExpressions:
- key: nodenv
operator: In
values:
- "pro"
topologyKey: kubernetes.io/hostname以上yaml表达的是不跟，拥有nodeenv=pro这个标签的pod在一个node上
# 创建pod
[root@k8s-master01 ~]# kubectl create -f pod-podantiaffinity-required.yaml
pod/pod-podantiaffinity-required created
# 查看pod
# 发现调度到了node2上
[root@k8s-master01 ~]# kubectl get pods pod-podantiaffinity-required -n dev -o wide
NAME READY STATUS RESTARTS AGE IP NODE ..
pod-podantiaffinity-required 1/1 Running 0 30s 10.244.1.96 node2 ..
我本地只有一台机，所以这个实验做不成，不过我大致知道是个什么情况了，拥有指定标签的参照pod在节点一，新的pod不跟拥有指定标签的pod在一台机，所以被分配到了节点二上
本文暂时没有评论，来添加一个吧(●'◡'●)