命令记不住

登陆

k8s 调度过程总结

  |   0 浏览

13.Kubernetes调度过程总结

1.需求

把 pod 放到合适的 node 上:

1、首先要满足 pod 的资源要求

2、其次要满足 pod 的一些特殊关系的要求

3、再次要满足 node 的一些限制条件的要求

4、最后还要做到整个集群资源的合理利用

做到这些要求之后，可以认为我们把 pod 放到了一个合适的节点上了。

2.基础调度力

两种关系场景：

1.pod 和 pod 之间的关系场景，包括怎么去亲和一个 pod，怎么去互斥一个 pod？

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

3.资源配置方法

spec:
containers:
 requests:
   requests:
     cpu: 2
     memory: 1Gi
   limits:
     cpu: 2
     memory: 1Gi

资源其实是填在 pod spec 里面，Container 里面有一个 resources 里面的 key 里面。

resources 其实包含两个部分：第一部分是 request；第二部分是 limits。

这两部分里面的内容是一模一样的，但是它代表的含义有所不同：request 代表的是对这个 pod 基本保底的一些资源要求；limit 代表的是对这个 pod 可用能力上限的一种限制。具体的 request、limit 的理念，其实都是一个 resources 的一个 map 结构，它里面可以填不同的资源的 key。

我们可以大概分成四大类的基础资源：

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

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

在扩展资源上，Kubernetes 有一个要求，即扩展资源必须是整数的，所以我们没法申请到 0.5 的 GPU 这样的资源，只能申请 1 个 GPU 或者 2 个 GPU，这里为大家介绍一下基础资源的申请方式。

4.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:

  • 第一类是 Guaranteed，它是一类高的 Qos Class，一般用 Guaranteed 来为一些需要资源保障能力的 pod 进行配置；
  • 第二类是 Burstable，它其实是中等的一个 Qos label，一般会为一些希望有弹性能力的 pod 来配置 Burstable；
  • 第三类是 BestEffort，通过名字我们也知道，它是一种尽力而为式的服务质量。
不同的 QoS 表现

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

在底层上，不同的 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。

发生 eviction 的时候，会优先考虑驱逐 BestEffort 的 pod。所以不同的 Qos 其实在底层的表现是截然不同的。这也反过来要求我们在生产过程中，根据不同业务的要求和属性来配置资源的 Limits 和 Request，做到合理的规划 Qos Class。

5.Pod亲和调度

PodAffinity

假如我想把一个 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 分配到权重分更高的调度条件节点上去。

6.Pod反亲和调度

podAntiAffinity

做到的效果也是 required 强制反亲和，以及一个 preferred 优先反亲和。

7.Pod与Node关系调度

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

1.NodeSelector

第一类是 NodeSelector，这是一类相对比较简单的玩法。比如说有个场景：必须要调度 Pod 到带了 k1: v1 标签的 Node 上，这时可以在 Pod 的 spec 中填写一个 nodeSelector 要求。nodeSelector 其实是一个 map 结构，里面可以直接写上对 node 标签的要求，比如 k1: v1。这样我的 Pod 就会强制调度到带了 k1: v1 标签的 Node 上。

2.NodeAffinity

节点亲和性（nodeAffinity）主要是用来控制 Pod 要部署在哪些节点上，以及不能部署在哪些节点上的，它可以进行一些简单的逻辑组合了，不只是简单的相等匹配，它是一个常规性调度，假如我想优先调度，就没法用 nodeSelector 来做。

对于亲和性和反亲和性都有这两种规则可以设置： preferredDuringSchedulingIgnoredDuringExecution 和requiredDuringSchedulingIgnoredDuringExecution，前面的就是软策略，后面的就是硬策略

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

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

8.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 的效果。

9.Pod/Node 的特殊关系和条件调度

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

  • PodAffinity
  • PodAntiAffinity

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

  • NodeSelector
  • NodeAffinity

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

  • Node -- Taints
  • Pod -- Tolerations
推荐阅读