从零开始入门 K8s | Kubernetes 调度和资源管理

做者 | 子誉  蚂蚁金服高级技术专家

关注“阿里巴巴云原生”公众号，回复关键词“入门”，便可下载从零入门 K8s 系列文章 PPT。

Kubernetes 调度过程

首先来看第一部分 - Kubernetes 的调度过程。以下图所示，画了一个很简单的 Kubernetes 集群架构，它包括了一个 kube-ApiServer，一组 Web-hook Controllers，以及一个默认的调度器 kube-Scheduler，还有两台物理机节点 Node1 和 Node2，分别在上面部署了两个 kubelet。

咱们来看一下，假如要向这个 Kubernetes 集群提交一个 pod，它的调度过程是什么样的一个流程？

假设咱们已经写好了一个 yaml 文件，就是下图中的橙色圆圈 pod1，而后往 kube-ApiServer 里提交这个 yaml 文件。

此时 ApiServer 会先把这个待建立的请求路由给咱们的 webhook Controllers 进行校验。

经过校验以后，ApiServer 会在集群里面生成一个 pod，此时生成的 pod，它的 nodeName 是空的，而且它的 phase 是 Pending 状态。在生成了这个 pod 以后，kube-Scheduler 以及 kubelet 都能 watch 到这个 pod 的生成事件，kube-Scheduler 发现这个 pod 的 nodeName 是空的以后，会认为这个 pod 是处于未调度状态。

接下来，它会把这个 pod 拿到本身里面进行调度，经过一系列的调度算法，包括一系列的过滤和打分的算法后，Schedule 会选出一台最合适的节点，而且把这一台节点的名称绑定在这个 pod 的 spec 上，完成一次调度的过程。

此时咱们发现，pod 的 spec 上，nodeName 已经更新成了 Node1 这个 node，更新完 nodeName 以后，在 Node1 上的这台 kubelet 会 watch 到这个 pod 是属于本身节点上的一个 pod。

而后它会把这个 pod 拿到节点上进行操做，包括建立一些容器 storage 以及 network，最后等全部的资源都准备完成，kubelet 会把状态更新为 Running，这样一个完整的调度过程就结束了。

经过刚刚一个调度过程的演示，咱们用一句话来归纳一下调度过程：它其实就是在作一件事情，即把 pod 放到合适的 node 上。

这里有个关键字“合适”，什么是合适呢？下面给出几点合适定义的特色：

• 首先要知足 pod 的资源要求；
• 其次要知足 pod 的一些特殊关系的要求；
• 再次要知足 node 的一些限制条件的要求；
• 最后还要作到整个集群资源的合理利用。

作到以上的要求后，能够认为咱们把 pod 放到了一个合适的节点上了。

接下来我会为你们介绍 Kubernetes 是怎么作到知足这些 pod 和 node 的要求的。

Kubernetes 基础调度力

下面为你们介绍一下 Kubernetes 的基础调度能力，Kubernetes 的基础调度能力会以两部分来展开介绍：

1. 第一部分是资源调度——介绍一下 Kubernetes 基本的一些 Resources 的配置方式，还有 Qos 的概念，以及 Resource Quota 的概念和使用方式；

2. 第二部分是关系调度——在关系调度上，介绍两种关系场景：

   1. pod 和 pod 之间的关系场景，包括怎么去亲和一个 pod，怎么去互斥一个 pod？
   2. pod 和 node 之间的关系场景，包括怎么去亲和一个 node，以及有一些 node 怎么去限制 pod 调度上来。

如何知足 Pod 资源要求

pod 的资源配置方法

上图是 pod spec 的一个 demo，咱们的资源实际上是填在 pod spec 中，具体在 containers 的 resources 里。

resources 包含两个部分：

• 第一部分是 requests；
• 第二部分是 limits。

这两部分里面的内容是如出一辙的，可是它表明的含义有所不一样：request 表明的是对这个 pod 基本保底的一些资源要求；limit 表明的是对这个 pod 可用能力上限的一种限制。request、limit 的实现是一个 map 结构，它里面能够填不一样的资源的 key/value。

咱们能够大概分红四大类的基础资源：

• 第一类是 CPU 资源；
• 第二类是 memory；
• 第三类是 ephemeral-storage，是一种临时存储；
• 第四类是通用的扩展资源，好比说像 GPU。

CPU 资源，好比说上面的例子填的是2，申请的是两个 CPU，也能够写成 2000m 这种十进制的转换方式，来表达有些时候可能对 CPU 多是一个小数的需求，好比说像 0.2 个CPU，能够填 200m。而这种方式在 memory 和 storage 之上，它是一个二进制的表达方式，如上图右侧所示，申请的是 1GB 的 memory，一样也能够填成一个 1024mi 的表达方式，这样能够更清楚地表达咱们对 memory 的需求。

在扩展资源上，Kubernetes 有一个要求，即扩展资源必须是整数的，因此咱们无法申请到 0.5 的 GPU 这样的资源，只能申请 1 个 GPU 或者 2 个 GPU。

这里为你们介绍完了基础资源的申请方式。

接下来，我会详细给你们介绍一下 request 和 limit 到底有什么区别，以及如何经过 request/limit 来表示 QoS。

Pod QoS 类型

K8S 在 pod resources 里面提供了两种填写方式：第一种是 request，第二种是 limit。

它实际上是为用户提供了对 Pod 一种弹性能力的定义。好比说咱们能够对 request 填 2 个 CPU，对 limit 填 4 个 CPU，这样表明了我但愿是有 2 个 CPU 的保底能力，但其实在闲置的时候，可使用 4 个 GPU。

说到这个弹性能力，咱们不得不提到一个概念：QoS 的概念。什么是 QoS呢？QoS 全称是 Quality of Service，它是 Kubernetes 用来表达一个 pod 在资源能力上的服务质量的标准，Kubernetes 提供了三类 QoS Class:

1. 第一类是 Guaranteed，它是一类高 QoS Class，通常拿 Guaranteed 配置给一些须要资源保障能力的 pods；
2. 第二类是 Burstable，它是中等的一个 QoS label，通常会为一些但愿有弹性能力的 pod 来配置 Burstable；
3. 第三类是 BestEffort，它是低QoS Class，经过名字咱们也知道，它是一种尽力而为式的服务质量，K8S不承诺保障这类Pods服务质量。

K8s 其实有一个不太好的地方，就是用户无法直接指定本身的 pod 是属于哪一类 QoS，而是经过 request 和 limit 的组合来自动地映射上 QoS Class。

经过上图的例子，你们能够看到：假如我提交的是上面的一个 spec，在 spec 提交成功以后，Kubernetes 会自动给补上一个 status，里面是 qosClass: Guaranteed，用户本身提交的时候，是无法定义本身的 QoS 等级。因此将这种方式称之为隐性的 QoS class 用法。

Pod QoS 配置

接下来介绍一下，咱们怎么经过 request 和 limit 的组合来肯定咱们想要的 QoS level。

Guaranteed Pod

首先咱们如何建立出来一个 Guaranteed Pod？

Kubernetes 里面有一个要求：若是你要建立出一个 Guaranteed Pod，那么你的基础资源（包括 CPU 和 memory），必须它的 request==limit，其余的资源能够不相等。只有在这种条件下，它建立出来的 pod 才是一种 Guaranteed Pod，不然它会属于 Burstable，或者是 BestEffort Pod。

Burstable Pod

而后看一下，咱们怎么建立出来一个 Burstable Pod，Burstable Pod 的范围比较宽泛，它只要知足 CPU/Memory  的 request 和 limit 不相等，它就是一种 Burstable Pod。

好比说上面的例子，能够不用填写 memory 的资源，只要填写 CPU 的资源，它就是一种 Burstable Pod。

BestEffort Pod

第三类 BestEffort Pod，它也是条件比较死的一种使用方式。它必须是全部资源的 request/limit 都不填，才是一种 BestEffort Pod。

因此这里能够看到，经过 request 和 limit 不一样的用法，能够组合出不一样的 Pod QoS。

不一样的 QoS 表现

接下来，为你们介绍一下：不一样的 QoS 在调度和底层表现有什么样的不一样？不一样的 QoS，它其实在调度和底层表现上都有一些不同。好比说调度表现，调度器只会使用 request 进行调度，也就是说无论你配了多大的 limit，它都不会进行调度使用。

在底层上，不一样的 Qos 表现更不相同。好比说 CPU，它是按 request 来划分权重的，不一样的 QoS，它的 request 是彻底不同的，好比说像 Burstable 和 BestEffort，它可能 request 能够填很小的数字或者不填，这样的话，它的时间片权重实际上是很是低的。像 BestEffort，它的权重可能只有 2，而 Burstable 或 Guaranteed，它的权重能够多到几千。

另外，当咱们开启了 kubelet 的一个特性，叫 cpu-manager-policy=static 的时候，咱们 Guaranteed Qos，若是它的 request 是一个整数的话，好比说配了 2，它会对 Guaranteed Pod 进行绑核。具体的像下面这个例子，它分配 CPU0 和 CPU1 给 Guaranteed Pod。

非整数的 Guaranteed/Burstable/BestEffort，它们的 CPU 会放在一块，组成一个 CPU share pool，好比说像上面这个例子，这台节点假如说有 8 个核，已经分配了 2 个核给整数的 Guaranteed 绑核，那么剩下的 6 个核 CPU2~CPU7，它会被非整数的 Guaranteed/Burstable/BestEffort 共享，而后它们会根据不一样的权重划分时间片来使用 6 个核的 CPU。

另外在 memory 上也会按照不一样的 QoS 进行划分 OOMScore。好比说 Guaranteed Pod，会固定配置默认的 -998 的 OOMScore；而 Burstable Pod 会根据 Pod 内存设计的大小和节点内存的比例来分配 2-999 的 OOMScore；BestEffort Pod 会固定分配 1000 的 OOMScore，OOMScore 得分越高的话，在物理机出现 OOM 的时候会优先被 kill 掉。

另外在节点上的 eviction 动做上，不一样的 QoS 行为也是不同的，好比说发生 eviction 的时候，会优先考虑驱逐 BestEffort 的 pod。因此不一样的 QoS 在底层的表现是大相径庭的。这反过来也要求咱们在生产过程当中，根据不一样业务的要求和属性来配置资源的 Limits 和 Requests，作到合理的规划 QoS Class。

资源 Quota

在生产中咱们还会遇到一个场景：假如集群是由多我的同时提交的，或者是多个业务同时在使用，咱们确定要限制某个业务或某我的提交的总量，防止整个集群的资源都会被一个业务使用掉，致使另外一个业务没有资源使用。

Kubernetes 给咱们提供了一个能力叫 ResourceQuota。它能够作到限制 namespace 资源用量。

具体的作法如上图右侧的 yaml 所示，能够看到它的 spec 包括了一个 hard 和 scopeSelector。hard 内容其实和 Resource 很像，这里能够填一些基础的资源。可是它比 Resource list 更丰富一点，还能够填写一些 Pod，这样能够限制 Pod 数量。另外，scopeSelector 还为这个 ResourceQuota 提供了更丰富的索引能力。

好比上面的例子中，索引出非 BestEffort 的 pod，限制的 cpu 是 1000 个，memory 是 200G，Pod 是 10 个。

ScopeName 除了提供 NotBestEffort，它还提供了更丰富的索引范围，包括 Terminating/Not Terminating，BestEffort/NotBestEffort，PriorityClass。

当咱们建立了这样的 ResourceQuota 做用于集群，若是用户真的用超了资源，表现的行为是：它在提交 Pod spec 时，会收到一个 forbidden 的 403 错误，提示 exceeded quota。这样用户就没法再提交对应用超的资源了。

而若是再提交一个没有包含在这个 ResourceQuota 里的资源，仍是能成功的。

这就是 Kubernetes 里 ResourceQuota 的基本用法。 咱们能够用 ResourceQuota 方法来作到限制每个 namespace 的资源用量，从而保证其余用户的资源使用。

小结：如何知足 Pod 资源要求？

上面介绍完了基础资源的使用方式，也就是咱们作到了如何知足 Pod 资源要求。下面作一个小结：

• Pod 要配置合理的资源要求

  • CPU/Memory/EphemeralStorage/GPU

• 经过 Request 和 Limit 来为不一样业务特色的 Pod 选择不一样的 QoS

  • Guaranteed：敏感型，须要业务保障
  • Burstable：次敏感型，须要弹性业务
  • BestEffort：可容忍性业务
• 为每一个 NS 配置 ResourceQuota 来防止过量使用，保障其余人的资源可用

如何知足 Pod 与 Pod 关系要求？

接下来给你们介绍一下 Pod 的关系调度，首先是 Pod 和 Pod 的关系调度。咱们在平时使用中可能会遇到一些场景：好比说一个 Pod 必需要和另一个 Pod 放在一块儿，或者不能和另一个 Pod 放在一块儿。

在这种要求下， Kubernetes 提供了两类能力：

• 第一类能力称之为 Pod 亲和调度：PodAffinity；
• 第二类就是 Pod 反亲和调度：PodAntAffinity。

Pod 亲和调度

首先咱们来看 Pod 亲和调度，假如我想把一个 Pod 和另外一个 Pod 放在一块儿，这时咱们能够看上图中的实例写法，填写上 podAffinity，而后填上 required 要求。

在这个例子中，必需要调度到带了 key: k1 的 Pod 所在的节点，而且打散粒度是按照节点粒度去打散索引的。这种状况下，假如能找到带 key: k1 的 Pod 所在节点，就会调度成功。假如这个集群不存在这样的 Pod 节点，或者是资源不够的时候，那就会调度失败。这是一个严格的亲和调度，咱们叫作强制亲和调度。

有些时候咱们并不须要这么严格的调度策略。这时候能够把 required 改为 preferred，变成一个优先亲和调度。也就是优先能够调度带 key: k2 的 Pod 所在节点。而且这个 preferred 里面能够是一个 list 选择，能够填上多个条件，好比权重等于 100 的是 key: k2，权重等于 10 的是 key: k1。那调度器在调度的时候会优先把这个 Pod 分配到权重分更高的调度条件节点上去。

Pod 反亲和调度

上面介绍了亲和调度，反亲和调度与亲和调度比较类似，功能上是取反的，但语法上基本上是同样的。仅是 podAffinity 换成了 podAntiAffinity，也是包括 required 强制反亲和，以及一个 preferred 优先反亲和。

这里举了两个例子：一个是禁止调度到带了 key: k1 标签的 Pod 所在节点；另外一个是优先反亲和调度到带了 key: k2 标签的 Pod 所在节点。

Kubernetes 除了 In 这个 Operator 语法以外，还提供了更多丰富的语法组合来给你们使用。好比说 In/NotIn/Exists/DoesNotExist 这些组合方式。上图的例子用的是 In，好比说第一个强制反亲和例子里面，至关于咱们必需要禁止调度到带了 key: k1 标签的 Pod 所在节点。

一样的功能也可使用 Exists，Exists 范围可能会比 In 范围更大，当 Operator 填了 Exists，就不须要再填写 values。它作到的效果就是禁止调度到带了 key: k1 标签的 Pod 所在节点，无论 values 是什么值，只要带了 k1 这个 key 标签的 Pod 所在节点，都不能调度过去。

以上就是 Pod 与 Pod 之间的关系调度。

如何知足 Pod 与 Node 关系调度

Pod 与 Node 的关系调度又称之为 Node 亲和调度，主要给你们介绍两类使用方法。

NodeSelector

第一类是 NodeSelector，这是一类相对比较简单的用法。好比说有个场景：必需要调度 Pod 到带了 k1: v1 标签的 Node 上，这时能够在 Pod 的 spec 中填写一个 nodeSelector 要求。nodeSelector 本质是一个 map 结构，里面能够直接写上对 node 标签的要求，好比 k1: v1。这样个人 Pod 就会强制调度到带了 k1: v1 标签的 Node 上。

NodeAffinity

NodeSelector 是一个很是简单的用法，但这个用法有个问题：它只能强制亲和调度，假如我想优先调度，就无法用 nodeSelector 来作。因而 Kubernetes 社区又新加了一个用法，叫作 NodeAffinity。

它和 PodAffinity 有点相似，也提供了两类调度的策略：

• 第一类是 required，必须调度到某一类 Node 上；
• 第二类是 preferred，就是优先调度到某一类 Node 上。

它的基本语法和上文中的 PodAffinity 以及 PodAntiAffinity 也是相似的。在 Operator 上，NodeAffinity 提供了比 PodAffinity 更丰富的 Operator 内容。增长了 Gt 和 Lt，数值比较的用法。当使用 Gt 的时候，values 只能填写数字。

Node 标记/容忍

还有第三类调度，能够经过给 Node 打一些标记，来限制 Pod 调度到某些 Node 上。Kubernetes 把这些标记称之为 Taints，它的字面意思是污染。

那咱们如何限制 Pod 调度到某些 Node 上呢？好比说如今有个 node 叫 demo-node，这个节点有问题，我想限制一些 Pod 调度上来。这时能够给这个节点打一个 taints，taints 内容包括 key、value、effect：

• key 就是配置的键值
• value 就是内容
• effect 是标记了这个 taints 行为是什么

目前 Kubernetes 里面有三个 taints 行为：

1. NoSchedule 禁止新的 Pod 调度上来；
2. PreferNoSchedul 尽可能不调度到这台；
3. NoExecute 会 evict 没有对应 toleration 的 Pods，而且也不会调度新的上来。这个策略是很是严格的，你们在使用的时候要当心一点。

如上图绿色部分，给这个 demo-node 打了 k1=v1，而且 effect 等于 NoSchedule 以后。它的效果是：新建的 Pod  没有专门容忍这个 taint，那就无法调度到这个节点上去了。

假若有些 Pod 是能够调度到这个节点上的，应该怎么来作呢？这时能够在 Pod 上打一个 Pod Tolerations。从上图中蓝色部分能够看到：在 Pod 的 spec 中填写一个 Tolerations，它里面也包含了 key、value、effect，这三个值和 taint 的值是彻底对应的，taint 里面的 key，value，effect 是什么内容，Tolerations 里面也要填写相同的内容。

Tolerations 还多了一个选项 Operator，Operator 有两个 value：Exists/Equal。Equal 的概念是必需要填写 value，而 Exists 就跟上文说的 NodeAffinity 同样，不须要填写 value，只要 key 值对上了，就认为它跟 taints 是匹配的。

上图中的例子，给 Pod 打了一个 Tolerations，只有打了这个 Tolerations 的 Pod，才能调度到绿色部分打了 taints 的 Node 上去。这样的好处是 Node 能够有选择性的调度一些 Pod 上来，而不是全部的 Pod 均可以调度上来，这样就作到了限制某些 Pod 调度到某些 Node 的效果。

小结

咱们已经介绍完了 Pod/Node 的特殊关系和条件调度，来作一下小结。

首先假若有需求是处理 Pod 与 Pod 的时候，好比 Pod 和另外一个 Pod 有亲和的关系或者是互斥的关系，能够给它们配置下面的参数：

• PodAffinity
• PodAntiAffinity

假如存在 Pod 和 Node 有亲和关系，能够配置下面的参数：

• NodeSelector
• NodeAffinity

假若有些 Node 是限制某些 Pod 调度的，好比说一些故障的 Node，或者说是一些特殊业务的 Node，能够配置下面的参数：

• Node -- Taints
• Pod -- Tolerations

Kubernetes 高级调度能力

介绍完了基础调度能力以后，下面来了解一下高级调度能力。

优先级调度

优先级调度和抢占，主要概念有：

• Priority
• Preemption

首先来看一下调度过程提到的四个特色，咱们如何作到集群的合理利用？当集群资源足够的话，只须要经过基础调度能力就能组合出合理的使用方式。可是假如资源不够，咱们怎么作到集群的合理利用呢？一般的策略有两类：

• 先到先得策略 (FIFO) -简单、相对公平，上手快
• 优先级策略 (Priority) - 比较符合平常公司业务特色

在实际生产中，若是使用先到先得策略，反而是一种不公平的策略，由于公司业务里面确定是有高优先级的业务和低优先级的业务，因此优先级策略会比先到先得策略更可以符合平常公司业务特色。

接下来介绍一下优先级策略下的优先级调度是什么样的一个概念。好比说有一个 Node 已经被一个 Pod 占用了，这个 Node 只有 2 个 CPU。另外一个高优先级 Pod 来的时候，低优先级的 Pod 应该把这两个 CPU 让给高优先级的 Pod 去使用。低优先级的 Pod 须要回到等待队列，或者是业务从新提交。这样的流程就是优先级抢占调度的一个流程。

在 Kubernetes 里，PodPriority 和 Preemption，就是优先级和抢占的特色，在 v1.14 版本中变成了 stable。而且 PodPriority 和 Preemption 功能默认是开启的。

优先级调度配置

怎么使用？

如何使用优先级调度呢？须要建立一个 priorityClass，而后再为每一个 Pod 配置上不一样的 priorityClassName，这样就完成了优先级以及优先级调度的配置。

首先来看一下如何建立一个 priorityClass。上图右侧定义了两个 demo：

• 一个是建立了名为 high 的 priorityClass，它是高优先级，得分为 10000；
• 另外一个建立了名为 low 的 priorityClass，它的得分是 100。

同时在第三部分给 Pod1 配置上了 high，Pod2 上配置了 low priorityClassName，蓝色部分显示了 pod 的 spec 的配置位置，就是在 spec 里面填写一个 priorityClassName: high。这样 Pod 和 priorityClass 作完配置，就为集群开启了一个 priorityClass 调度。

内置优先级配置

固然 Kubernetes 里面还内置了默认的优先级。如 DefaultpriorityWhenNoDefaultClassExistis，若是集群中没有配置 DefaultpriorityWhenNoDefaultClassExistis，那全部的 Pod 关于此项数值都会被设置成 0。

用户可配置的最大优先级限制为：HighestUserDefinablePriority = 10000000000(10 亿)，会小于系统级别优先级：SystemCriticalPriority = 20000000000(20 亿)

其中内置了两个系统级别优先级：

• system-cluster-critical
• system-node-critical

这就是K8S优先级调度里内置的优先级配置。

优先级调度过程

下面介绍简单的优先级调度过程：

首先介绍只触发优先级调度可是没有触发抢占调度的流程。

假若有一个 Pod1 和 Pod2，Pod1 配置了高优先级，Pod2 配置了低优先级。同时提交 Pod1 和 Pod2 到调度队列里。

调度器处理队列的时候会挑选一个高优先级的 Pod1 进行调度，通过调度过程把 Pod1 绑定到 Node1 上。

其次再挑选一个低优先的 Pod2 进行一样的过程，绑定到 Node1 上。

这样就完成了一个简单的优先级调度的流程。

优先级抢占过程

假如高优先级的 Pod 在调度的时候没有资源，那么会是一个怎么样的流程呢？

首先是跟上文一样的场景，可是提早在 Node1 上放置了 Pod0，占去了一部分资源。一样有 Pod1 和 Pod2 待调度，Pod1 的优先级大于 Pod2。

假如先把 Pod2 调度上去，它通过一系列的调度过程绑定到了 Node1 上。

紧接着再调度 Pod1，由于 Node1 上已经存在了两个 Pod，资源不足，因此会遇到调度失败。

在调度失败时 Pod1 会进入抢占流程，这时会进行整个集群的节点筛选，最后挑出要抢占的 Pod 是 Pod2，此时调度器会把 Pod2 从 Node1 上移除数据。

再把 Pod1 调度到 Node1 上。这样就完成了一次抢占调度的流程。

优先级抢占策略

接下来介绍具体的抢占策略和抢占流程

上图右侧是整个kube-scheduler优先级抢占的调度流程。首先一个 Pod 进入抢占的时候，会判断 Pod 是否拥有抢占的资格，有可能上次已经抢占过一次。若是符合抢占资格，它会先对全部的节点进行一次过滤，过滤出符合此次抢占要求的节点，若是不符合就过滤掉这批节点。

接着从过滤剩下的节点中，挑选出合适的节点进行抢占。此次抢占的过程会模拟一次调度，把上面优先级低的 Pod 先移除出去，再把待抢占的 Pod 尝试可否放置到此节点上。而后经过这个过程选出一批节点，进入下一个过程 ProcessPreemptionWithExtenders。这是一个扩展的钩子，用户能够在这里加一些本身抢占节点的策略，若是没有扩展钩子，这里面是不作任何动做的。

接下来的流程叫作 PickOneNodeForPreemption，就是从上面 selectNodeForPreemption list 里面挑选出最合适的一个节点，这是有必定的策略的。上图左侧简单介绍了一下策略：

• 优先选择打破 PDB 最少的节点；
• 其次选择待抢占 Pods 中最大优先级最小的节点；
• 再次选择待抢占 Pods 优先级加和最小的节点；
• 接下来选择待抢占 Pods 数目最小的节点；
• 最后选择拥有最晚启动 Pod 的节点；

经过这五步串行策略过滤以后，会选出一个最合适的节点。而后对这个节点上待抢占的 Pod 进行 delete，这样就完成了一次待抢占的过程。

小结

简单介绍了一下调度的高级策略，在集群资源紧张的时候也能合理调度资源。咱们回顾一下作了哪些事情：

• 建立自定义的一些优先级类别 (PriorityClass)；
• 给不一样类型 Pods 配置不一样的优先级 (PriorityClassName)；
• 经过组合不一样类型 Pods 运行和优先级抢占让集群资源和调度弹性起来。

“ 阿里巴巴云原生关注微服务、Serverless、容器、Service Mesh 等技术领域、聚焦云原生流行技术趋势、云原生大规模的落地实践，作最懂云原生开发者的技术圈。”