介绍

优先级调度其实没有那么常用，但是既然K8s提供出来了，我们还是了解一下，在1.8版本之前，当集群资源不足时又有新的Pod创建请求，那么这个Pod会一直处于Pending状态，就算是这个Pod非常的重要，非部署不可，那也没办法，你只能删除一些Pod释放一些资源才能被调度成功。

为了解决该问题，在1.8版本就引入了优先级抢占调度策略，如果新调度的优先级非常高，那么集群会尝试释放优先级低的Pod以保证新的Pod可以正常调度，这种方式称为抢占式调度，1.11版本升级为Beta版本，1.14版本之后成为正式版本

调度策略

调度策略有两种一种是驱逐（ Eviction ）一种是抢占（ Preemtion ），两种方式的场景不同，效果也不同

Eviction 是kubelet进程的行为，当该Node上的资源不足时，kubelet就会执行驱逐动作，配合优先级，将优先级低的Pod驱逐，如果优先级都一样，那么实际使用的资源量超过申请量最大倍数的高耗能 Pod 会被首先驱逐

Preemption 是 Scheduler 执行调度的行为，当有新的Pod创建，但是因为资源不够无法正常调度，调度器便会驱逐部分优先级较低的Pod来满足新Pod的需求

创建权重

权重是区分优先级的关键因素

yaml定义

通过yaml方式定义一个PriorityClass，它不属于任何命名空间

app-priority.yaml

apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: app-priority
value: 100 # 优先级为100，数字越大，优先级越高
globalDefault: false
description: " app test priority."

属性分析

PriorityClass不受命名空间约束

value越大优先级越高，但是不要超过10亿，超过10亿的通常是不该被驱逐的Pod，一般K8s内部使用

查看系统自带的优先级

[root@master ~]# kubectl get PriorityClass
NAME                      VALUE        GLOBAL-DEFAULT   AGE
system-cluster-critical   2000000000   false            52d
system-node-critical      2000001000   false            52d

查看kube-apiserver-master使用的优先级

[root@master ~]# kubectl describe -pod kube-apiserver-master -n kube-system
Priority:             2000001000
Priority Class Name:  system-node-critical

没有设置优先级的Pod默认优先级为0

globalDefault 给没有设置优先级的Pod使用，整个系统只能设置一个globalDefault=true的PriorityClass

description 描述什么时候应该使用该优先级

创建

创建优先级app-priority

# 创建优先级
[root@master priority]# kubectl create -f app-priority.yaml 
priorityclass.scheduling.k8s.io/app-priority created

# 查看创建是否成功
[root@master priority]# kubectl get PriorityClass
NAME                      VALUE        GLOBAL-DEFAULT   AGE
app-priority              100          false            8s
system-cluster-critical   2000000000   false            52d
system-node-critical      2000001000   false            52d

使用优先级

这里不模拟资源不足的场景，我们结合前面讲到的亲和性调度与污点来模拟效果

给node02设置上一个污点，使得Pod不能调度进来，给node01运行一个带有标签env=pro的Pod，再创建一个新的Pod使用了优先级app-priority，并且通过反亲和性设置不能调度到带有标签env=pro的Pod所在Node，那么新Pod将没有节点可调度，但是由于它的优先级高，那么会不会丢车保帅，将node01上的Pod驱逐呢？

下面来验证一下

创建带有标签env=pro的Pod，yaml配置如下

target-pod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: target-pod
  labels:
    env: pro
spec:
  containers:
  - name: nginx
    image: nginx
    imagePullPolicy: IfNotPresent # 本地有不拉取镜像
  nodeName: node01 # 将target放到node01

创建带有优先级的Pod，yaml如下

priority-pod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: priority-pod
  labels:
    env: pro
spec:
  containers:
  - name: nginx
    image: nginx
    imagePullPolicy: IfNotPresent # 本地有不拉取镜像
  affinity:
    podAntiAffinity: # 使用Pod反亲和性
      requiredDuringSchedulingIgnoredDuringExecution:  # 硬限制
      - labelSelector:
          matchExpressions:
          - key: env
            operator: In
            values: ["pro"]
        topologyKey: kubernetes.io/hostname
  priorityClassName: app-priority

给node02创建污点，模拟不可用

创建target-pod，观察是否运行正常

启动priority-pod，此时立刻查看Pod详情，看target-pod是否正在被驱逐

# 给node02创建污点，模拟不可用
[root@master priority]# kubectl taint node node02 app=true:NoExecute
node/node02 tainted

# 启动traget-pod
[root@master priority]# kubectl create -f target-pod.yaml
pod/target-pod created
[root@master priority]# kubectl get pod -o wide
NAME         READY   STATUS    RESTARTS   AGE   IP            NODE     NOMINATED NODE   READINESS GATES
target-pod   1/1     Running   0          11s   10.244.1.97   node01   <none>           <none>

# 启动priority-pod并且立刻查看Pod详情，target-pod正在被驱逐
[root@master priority]# kubectl create -f priority-pod.yaml && kubectl get pod -o wide
pod/priority-pod created
NAME           READY   STATUS        RESTARTS   AGE   IP            NODE     NOMINATED NODE   READINESS GATES
priority-pod   0/1     Pending       0          0s    <none>        <none>   node01           <none>
target-pod     1/1     Terminating   0          15s   10.244.1.99   node01   <none>           <none>

# 再次查看Pod详情，priority-pod运行成功，target-pod被驱逐
[root@master priority]# kubectl get pod -o wide
NAME           READY   STATUS    RESTARTS   AGE   IP             NODE     NOMINATED NODE   READINESS GATES
priority-pod   1/1     Running   0          8s    10.244.1.100   node01   <none>           <none>

需要注意的是，新的Pod并不会立刻就被调度到Node节点， 调度器只会将抢占者的 spec.nominatedNodeName 字段，设置为被抢占的 Node 的名字 ，等待下一轮周期才决定要不要调度到抢占的Node节点，原因是被驱逐的Pod是通过 DELETE API 来删除被抢占的 Pod，一般的应用都有优雅停机时长，在这段时间里可调度性可能会发生变化，也许都不需要抢占了，所以这样设置还是比较合理，但是如果这段时间有更高级别的Pod来抢， 那么调度器就会清空原抢占者的 spec.nominatedNodeName 字段，保证优先级更高的Pod进行调度，当K8s有多个调度器，这种方式可能会陷入死循环，所以优先级调度其实不太常用。

---

优先级调度就介绍到这里，后面介绍Pod控制器

欢迎关注，学习不迷路！