k8s调度过程中的资源分配问题

想要明白调度过程中的资源分配问题，首先要明白一件事，k8s中的资源分配，是以Pod为单位的。而Pod本质上而言，其实就是一个进程。就像操作系统一样，进程是资源分配的最小单位。

k8s解决的一个比较大的问题，就是资源分配。

作为这么受欢迎调度服务编排的一员，k8s自然有出色的资源调度能力。

其实主要问题就两个，一个是通过yaml进行资源的申请，一个是k8s，满足资源的申请。

为了讲明白，我用了很多个小故事！希望能帮到大家

罗列一下资源分配都有哪问题

先从资源申请者：pod来讲

Pod如何才能具有弹性。弹性包括单个Pod，如果在不是很需要资源的情况下，k8s回收一些资源用于执行重要的任务。弹性还包括，如何在执行紧急任务的时候，先停一些不重要的Pod、
如果Pod与pod具有关联性，需要分配在相同的机器怎么办？
如果Pod与Pod不能部署在同一台机器上怎么办。
如果Pod需要部署在指定类型的机器上怎么办，比方说，一个Pod需要的所计算密集型的主机，或者需要的是IO密集型的主机，或者需要特殊的GPU。

从机器的角度来讲：

如果机器只允许一些Pod调度上去，怎么做。
如果机器故障了，不想再让新的Pod调度上来怎么做。
机器如何选择Pod

以Pod为单位的资源分配

先看看资源是如何申请的。

其中资源无非分为这几种， cpu，内存，gpu，这些。

Pod想要申请的资源，就是通过 yaml配置来的，案例如下：注意红框，要申请两个cpu，1G的内存。limits，代表的是最低限度，最少2个CPU，最少1G内存。

上边提到了三类问题下边逐一解决：

第一个问题，关于弹性问题

先了解一个概念，就是关于Pod的QoS类型

什么是 Qos呢？Qos 全称是 Quality of Service，它其实是 Kubernetes 用来表达一个 pod 在资源能力上的服务质量的标准，Kubernetes 提供了三类的 Qos Class:

第一类是 Guaranteed，它是一类高的 Qos Class，一般用 Guaranteed 来为一些需要资源保障能力的 pod 进行配置；这个具体的特征就是上边的Pod资源申请的图里边的红框内容，requests和limits相同的。其实这个用自己的话理解就是，我想要两个女朋友，也必须要两个女朋友。
第二类是 Burstable，它其实是中等的一个 Qos label，一般会为一些希望有弹性能力的 pod 来配置 Burstable；这个其实就是必须两个不相等。感觉有点多余。比方说：我想要两个女朋友，最少有一个女朋友，就是这个概念。还不能是我有一个女朋友，正好有一个女朋友。因为这就符合第一种模式了。
第三类是 BestEffort，通过名字我们也知道，它是一种尽力而为式的服务质量。第三种是必须都不配置。第三种是我是成年人了，我其实可以有个女朋友，但是我比较佛系，有没有都行。

其实经过我上边的栗子的讲解，就大概知道一个需求的强烈程度了。第一种最强烈，第二种适中，第三种有没有都行。

k8s也是根据这三种模式来分配资源的。对于第一种，就一定要分配资源给它，而且是要多少给多少。第二种也差不多，但是不是要多少给多少。第三种就是，如果富裕了就给它点，如果不富裕就不给了。同样对于弹性而言，如果资源不够了，那就优先停第三种，或者把第二种原先多分了收回来一点。但是对于第一种，如果不是认为敢于，是没办法把资源收回来的。

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

第二个问题，Pod的亲和性

也是如何把一些关联性的Pod部署在同一台机器

先举个栗子吧，其实比较简单，一个服务，它需要定制化的监控。所以它们被设计成了两个Pod，但是为了方便数据采集，又需要将它们部署在一起。

这里问题再用生活的栗子讲一下，其实k8s就是老师，我是学生，李小妹也是学生，李小妹是村东头的村花儿。新学期排座位的时候，我把老师叫到办公室，并且告诉老师，我要和李小妹坐同桌，其一我长的帅，小妹长的漂亮。其二我们是一个村的，比较熟，方便相互照应学习。老师排座位的时候就把我们排在了一起！

那k8s是如何把两个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的反亲和性

有了上边的栗子，其实还有一种情况，就是不想和谁当同桌。比方说，我不想和李小妹当同桌，因她的妹，可能会影响我的学习。我告诉了老师，不要把我排到李小妹附近。我是一个Pod，李小妹是一个Pod，这个栗子就是Pod与Pod的反亲和性。

再看看k8s是如何做的：

第四个问题，Pod对node的选择

还用新学期排座位的栗子，这次不是我和李小妹的关系了。而是我具体坐在第几排的问题，我告诉老师，我太高了，最好不要把我排到前边，可能会挡住后边李小妹看黑板。必须把我排到后三排。

看看k8s，是如何把Pod分配到想去的node上的：第一种，pod选择node，通过标签选择器。

第五个问题，还是Pod选择Node

上边有个问题，就是假如后三排人坐满了，我不就没座位了吗？我这么爱学习，怎么能没作为。同样的道理，比方说Pod想要调度到一个机器上去，但是这台机器资源已经被分配完了，所以就不能被分配资源了。

所以有了下边的策略，后三排做人坐满了，倒数第四排也行。下边这个栗子其实就是，可以调度到带有v1标签的node上，不行就调度到v2标签的node上。其实利用这个特性，我们就可以把我们的Pod分配到具体特性的机器上去执行。

第六个问题，node 拒绝 Pod

经常有这样的情况，某台机器发生了异常，不希望再有Pod调度上来。或者这台机器资源吃紧了，希望预留一点空间出来。反正就是不想再让Pod分配上来了。这个时候可以给node打上一个污点。

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

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

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

NoSchedule 禁止新的 Pod 调度上来；
PreferNoSchedul 尽量不调度到这台；
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 的效果。