该配置定义了： "high"优先级的pod只能在指定的namespaces下创建，该namespaces有作用于"high"优先级的resouceQuota，上面第四步中的resouceQuota即可满足要求。
scopeName定义了作用的对象为priorityClass, operator指定了作用的范围，可以是In操作符，指定某几个value, 也可以是Exits操作符，指定所有的PriorityClass必须有对应的quota存在, 否则该namespace就无法创建该优先级的pod，这些操作符与上面resouceQuota中定义的一一对应。通过这样就限制了一些优先级只能在有资源约束的namespace下创建。
如果没有显式指定优先级，则默认的优先级值为0，需要结合业务规划决定是否有必要调整默认优先级。
对于一些daemonset需要显式设置较高的优先级来防止被抢占，在部署一个新的daemonset的时候需要考虑是否会造成大规模pod的抢占。
等到所有的优先级设置完毕之后就可以开启抢占功能了，此时集群中所有pending 的高优先级pod就会瞬间抢占，还是需要额外小心，确保集群中高优先级的pod不会导致低优先级的pod大规模被kill，如果我们提前设置了对应的resource quota值，则会有一定的资源约束。
优先级和抢占对于资源的精细化运营考验很大，对于resource quota的设置需要十分精细，需要考虑两个维度来设置： namespace层面和priority层面，我们既希望限制namespace使用的资源，有希望某个priority使用的资源，防止低优先级的pod资源饥饿。 可以在初期只考虑namespace层面的限制，priority层面通过上层业务来保证，例如创建任务的时候保证集群中高优先级的资源使用量不超过50%等。
其他思考笔者的线上环境中， 有些再跑的模型训练任务业务对于自动failove实现不是很好，如果中途被抢占了只能从头开始计算，需要占用额外的GPU资源，这种工作类型不允许被抢占，但是如果把他设置为高优先级又不太合适，因为它确实不是最高的优先级，优先级最高的还是在线业务，不能让它抢占在线业务。 它属于中间优先级，可以抢占低优先级的pod。 经过探索发现目前kubernetes并不支持该中类型，当前支持的抢占策略为： Never, PreemptLowerPriority都无法满足需求。所以在此基础上开发了NonPreemptible类型的抢占策略，该优先级的pod是不允许被其他人抢占的，调度还是按照优先级在队列里排队，但是一旦调度上去就无法被抢占。
这种抢占策略略显"霸道"，所以需要谨慎使用，设置resouceQuota，并且只能由特定的任务使用。 并且为了不影响deamonset等优先级最高的任务，允许被某个指定Priority数值之上的pod抢占。并且随着业务的发展，这部分逻辑需要逐步去掉，之所有存在这部分逻辑是因为pod不能被中断，不能被抢占，所以还是需要使这些任务支持重启与挂起，具体来说就是： pod挂载远程磁盘并自动checkpoint，重启之后从以前的恢复点继续执行。等这些业务改造完成之后，逐步去掉这种工作抢占策略
Pod Priority and Preemption
Priority in ResourceQuota
Allow PriorityClasses To Be Non-Preempting