调度引擎：Kubernetes 如何高效调度 Pod？

老罗-Mason

于 2022-10-17 14:21:16 发布

阅读量191

点赞数

分类专栏： Architecture 文章标签： kubernetes 云原生 docker

本文链接：https://blog.csdn.net/lmaosheng/article/details/127361975

版权

Architecture 专栏收录该内容

21 篇文章 2 订阅

订阅专栏

Pod 创建好以后，Kubernetes 又如何调度这些 Pod 呢？如果我们希望把一个 Pod 跑在我们期望的节点上，该如何操作呢？如果我们希望把某些关联性强的 Pod 跑在特定的节点上，或者同一个节点上，又该怎么操作呢？

Kubernetes 调度器工作原理简介

kube-scheduler 作为 Kubernetes 的调度器，它的主要任务就是给新创建的 Pod 或者是未被调度的 Pod 挑选一个合适的节点供 Pod 运行，满足 Pod 对资源等的要求。这样对应节点上的 Kubelet 就可以监听到该 Pod，并将其创建、运行。

整个调度过程听起来很简单，但是要考虑到的问题其实有很多，比如优先级、资源高效利用、高性能等。

优先级。高优先级的 Pod 肯定要优先被调度。

资源高效利用。比如我们要避免 Pod 都被调度到一个或某几个节点上，造成节点负载太大；或是避免同一个工作负载（如 Deployment）的几个副本，跑在同一个节点上，以免这个节点宕机对整个业务造成影响。

高性能。我们需要支持快速地完成大规模 Pod 的调度工作，这样才能够支撑大规模的集群。

可扩展性强。方便用户自己增加调度逻辑，可以参考官方文档（https://kubernetes.io/zh/docs/concepts/scheduling-eviction/scheduling-framework/）中的内容。

……

总的来说，调度的过程主要分为两个大步骤。

过滤一些不满足条件的节点，这个过程也称为 Predict。

调度器会对这些合适的节点进行打分排序，从中选择一个最优的节点，这个过程也称为 Priority。

这里面其实包含了很多的调度策略，在此不一一说明，你可以阅读这份调度策略列表（https://kubernetes.io/zh/docs/reference/scheduling/policies/），了解各个策略对应的含义。

在实际使用的过程中，你可以直接使用调度器的默认配置，不需要对其做过多的定制化。当然，如果你有特殊的需求，也可以构建自己的调度器，具体可以参考这份文档（https://kubernetes.io/zh/docs/reference/scheduling/config/）来更改默认调度器的调度策略、调度插件以及调度行为。

下面我们主要来认识一下调度器都有哪些高级特性。

调度器的高级特性

调度器的高级特性有 NodeName 和 NodeSelector、亲和性和反亲性、污点和容忍，我们依次来了解一下。

NodeName 和 NodeSelector

首先是 NodeName 和 NodeSelector。

我们可以通过 spec.nodeName 强制约束在某个指定的 Node 上运行 Pod，如下所示：

apiVersion: v1

kind: Pod

metadata:

namespace: demo

spec:

nodeName: node1 #指定调度节点 node1 上

containers:

- name: nginx-demo

image: nginx:1.19.4

上面这个 Pod 就被约束在 node1 上。通过这种方式指定节点，会跳过 kube-scheduler 的调度逻辑，即不需要经过调度。

除了这种强制指定节点的方式，我们还可以通过 NodeSelector 的方式来选择节点。调度器的调度策略 MatchNodeSelector 会匹配 Node 的 label，从而达到节点筛选的目的。比如下面这个例子：

# 我们先对节点进行打标

$ kubectl label nodes node1 abc.com/role=dev

# 通过如下命令可以查看该节点目前的所有 label

$ kubectl get node node1 --show-labels

NAME STATUS ROLES AGE VERSION LABELS

node1 Ready master 75d v1.16.6-beta.0 abc.com/role=dev,beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/arch=amd64,kubernetes.io/hostname=docker-desktop,kubernetes.io/os=linux,node-role.kubernetes.io/master=

对节点打好标以后，就可以通过 spec.nodeSelector 来将 Pod 调度到带有指定 label 标记的节点上。

apiVersion: v1

kind: Pod

metadata:

namespace: demo

spec:

nodeSelector:

abc.com/role: dev #指定调度到带有 abc.com/role=dev 这种 label 标记的节点上

containers:

- name: nginx-demo

image: nginx:1.19.4

nodeSelector 提供了一种非常简单的方法，方便我们将 Pod 约束到带有特定 label 的节点上。

除此之外，kube-scheduler 还提供了更加动态的方式，即亲和性和反亲和性，可以帮助我们完成更高级的 Pod 调度，比如将某些 Pod 都调度到某个节点上。

下面我们就来认识一下亲和性和反亲和性。

亲和性和反亲和性

Kubernetes 提供了如下 3 种类型：

nodeAffinity（节点亲和性）；

podAffinity（Pod 亲和性）；

podAntiAffinity（Pod 反亲和性）。

这 3 种亲和性和反亲和性策略支持更广泛的操作符，差异如下表所示：

对于上述的亲和性和反亲和性功能，每种都有 3 种规则可以设置。

RequiredDuringSchedulingRequiredDuringExecution：在 Pod 调度期间要求满足亲和性或者反亲和性的规则要求。如果不能满足这些指定的规则，那该 Pod 不能被调度到对应的主机上。而且在之后的运行过程中，如果因为某些原因（比如 label 被修改了）导致规则不再满足了，系统就会尝试把该 Pod 从主机上驱逐掉。

RequiredDuringSchedulingIgnoredDuringExecution：在 Pod 调度期间要求满足亲和性或者反亲和性规则。如果不能满足的话，那么该 Pod 不能被调度到对应的主机上。在之后的运行过程中，系统也不会再去检查这些规则是否还继续满足。

PreferredDuringSchedulingIgnoredDuringExecution：在 Pod 调度期间要尽量地指定的亲和性和反亲和性规则。即使不能满足，Pod 也有可能被调度到对应的主机上。在之后的运行过程中，系统也不会再去检查这些规则是否继续满足。

我们这里来说说具体的使用场景。

对于 nodeAffinity，主要有两个使用场景：

帮助我们将一个工作负载的所有 Pod 部署到指定的 label 的主机上，这点和 nodeSelector 是类似的；帮助我们将 Pod 部署到不带有特定 label 的主机上，即 Notin，比如不在 Master 节点上部署该 Pod。

下面是一个官方使用的 nodeAffinity 的例子：

apiVersion: v1

kind: Pod

metadata:

spec:

affinity:

nodeAffinity:

requiredDuringSchedulingIgnoredDuringExecution:

nodeSelectorTerms:

- matchExpressions:

- key: kubernetes.io/e2e-az-name

operator: In

values:

- e2e-az1

- e2e-az2

preferredDuringSchedulingIgnoredDuringExecution:

- weight: 1

preference:

matchExpressions:

- key: another-node-label-key

operator: In

values:

- another-node-label-value

containers:

- name: with-node-affinity

image: k8s.gcr.io/pause:2.0

这个 Pod 指定必须运行在 label 带有 kubernetes.io/e2e-az-name=e2e-az1 或 kubernetes.io/e2e-az-name=e2e-az2 的节点上。如果没有任何一个节点有这些 label，则该 Pod 不会被调度。同时这些节点上最好还带有 another-node-label-key=another-node-label-vale 的标签。

对于 podAffinity 和 podAntiAffinity，你可以基于已经在节点上运行的 Pod 的标签来约束新 Pod 可以调度到的节点，而不是基于节点上的标签。

如下是一个官方使用的 podAffinity 和 podAntiAffinity 的例子：

apiVersion: v1

kind: Pod

metadata:

spec:

affinity:

podAffinity:

requiredDuringSchedulingIgnoredDuringExecution:

- labelSelector:

matchExpressions:

- key: security

operator: In

values:

- S1

topologyKey: topology.kubernetes.io/zone

podAntiAffinity:

preferredDuringSchedulingIgnoredDuringExecution:

- weight: 100

podAffinityTerm:

labelSelector:

matchExpressions:

- key: security

operator: In

values:

- S2

topologyKey: topology.kubernetes.io/zone

containers:

- name: with-pod-affinity

image: k8s.gcr.io/pause:2.0

上述这个例子中使用了 podAffinity 和 podAntiAffinity。其中亲和性这块的规则表示该 Pod 必须部署在一个节点上，这个节点上至少有一个处于正在运行状态的带有 security=s1 标签的 Pod，并且要求部署的节点同正在运行的 Pod 所在节点都在相同的云服务区域中，也就是 topologyKey:topology.kubernetes.io/zone。

换言之，一旦某个区域出了问题，我们希望这些 Pod 能够再次迁移到同一个区域。当然， topologyKey 可以是任何合法的标签键，比如 kubernetes.io/hostname，你可以参考官方文档（https://kubernetes.io/zh/docs/concepts/scheduling-eviction/assign-pod-node/#pod-%E4%BD%BF%E7%94%A8-pod-%E4%BA%B2%E5%92%8C-%E7%9A%84%E7%A4%BA%E4%BE%8B），看看这个值在使用上的限制。

对于例子中 Pod 反亲和性规则，表示该 Pod 不希望部署在一个运行着带有 label 为 security=s2 的 Pod 的节点上。

除了在 Pod 层面进行限制外，我们还可以对 Node 进行操作，可以禁止某些 Pod 调度上来。

污点和容忍（Taints and Tolerations）

最后我们来看污点和容忍（Taints and Tolerations）。

我们可以给节点设置污点，通过这个污点就可以避免 Pod 调度上来，除非在 Pod 上设置了污点容忍。

每个污点的组成如下：

key=value:effect

每个污点规则都有一个 key 和 value，其中 value 可以为空，effect 描述污点的作用。当前 taint effect 支持如下 3 个选项：