Kubernetes Scheduler 是 Kubernetes 控制平面的核心组件之一。它在控制平面上运行,将 Pod 分配给节点,同时平衡节点之间的资源利用率。将 Pod 分配给新节点后,在该节点上运行的 kubelet 会在 Kubernetes API 中检索 Pod 定义,根据节点上的 Pod 规范创建资源和容器。换句话说,Scheduler 在控制平面内运行,并将工作负载分配给 Kubernetes 集群

本文将对 Kubernetes Scheduler 进行深入研究,首先概述一般的调度以及具有亲和力(affinity)和 taint 的驱逐调度,然后讨论调度程序的瓶颈以及生产中可能遇到的问题,最后研究如何微调调度程序的参数以适合集群。

调度简介

Kubernetes 调度是将 Pod 分配给集群中匹配节点的过程。Scheduler 监控新创建的 Pod,并为其分配最佳节点。它会根据 Kubernetes 的调度原则和我们的配置选项选择最佳节点。最简单的配置选项是直接在 PodSpec 设置 nodeName:

上面的 nginx pod 默认情况下将在 node-01 上运行,但是 nodeName 有许多限制导致无法正常运行 Pod,例如云中节点名称未知、资源节点不足以及节点网络间歇性问题等。因此,除了测试或开发期间,我们最好不使用 nodeName。如果要在一组特定的节点上运行 Pod,可以使用 nodeSelector。我们在 PodSpec 中将 nodeSelector 定义为一组键值对:

对于上面的 nginx pod,Kubernetes Scheduler 将找到一个磁盘类型为 ssd 的节点。当然,该节点可以具有其他标签。我们可以在 Kubernetes 参考文档中查看标签的完整列表。

地址:https://kubernetes.io/docs/reference/kubernetes-api/labels-annotations-taints/

使用 nodeSelector 有约束 Pod 可以在有特定标签的节点上运行。但它的使用仅受标签及其值限制。Kubernetes 中有两个更全面的功能来表达更复杂的调度需求:节点亲和力(node affinity),标记容器以将其吸引到一组节点上;taint 和 toleration,标记节点以排斥 Pod。这些功能将在下面讨论。

节点亲和力

节点亲和力(Node Affinity)是在 Pod 上定义的一组约束,用于确定哪些节点适合进行调度,即使用亲和性规则为 Pod 的节点分配定义硬性要求和软性要求。例如可以将 Pod 配置为仅运行带有 GPU 的节点,并且最好使用 NVIDIA_TESLA_V100 运行深度学习工作负载。Scheduler 会评估规则,并在定义的约束内找到合适的节点。与 nodeSelectors 相似,节点亲和性规则可与节点标签一起使用,但它比 nodeSelectors 更强大。

我们可以为 podspec 添加四个相似性规则:

  • requiredDuringSchedulingIgnoredDuringExecution
  • requiredDuringSchedulingRequiredDuringExecution
  • preferredDuringSchedulingIgnoredDuringExecution
  • preferredDuringSchedulingRequiredDuringExecution

这四个规则由两个条件组成:必需或首选条件,以及两个阶段:计划和执行。以 required 开头的规则描述了必须满足的严格要求。以 preferred 开头的规则是软性要求,将强制执行但不能保证。调度阶段是指将 Pod 首次分配给节点。执行阶段适用于在调度分配后节点标签发生更改的情况。

如果规则声明为 IgnoredDuringExecution,Scheduler 在第一次分配后不会检查其有效性。但如果使用 RequiredDuringExecution 指定了规则,Scheduler 会通过将容器移至合适的节点来确保规则的有效性。

以下是示例:

上面的 Nginx Pod 具有节点亲和性规则,该规则让 Kubernetes Scheduler 将 Pod 放置在 us-east 的节点上。第二条规则指示优先使用 us-east-1 或 us-east-2。

使用亲和性规则,我们可以让 Kubernetes 调度决策适用于自定义需求。

Taint 与 Toleration

集群中并非所有 Kubernetes 节点都相同。某些节点可能具有特殊的硬件,例如 GPU、磁盘或网络功能。同样,我们可能需要将一些节点专用于测试、数据保护或用户组。我们可以将 Taint 添加到节点以排斥 Pod,如以下示例所示:

kubectl taint nodes node1 test-environment=true:NoSchedule使用 test-environment=true:NoScheduletaint 时,除非在 podspec 具有匹配的 toleration,否则 Kubernetes Scheduler 将不会分配任何 pod :

taint 和 tolerations 共同发挥作用,让 Kubernetes Scheduler 专用于某些节点并分配特定 Pod。

调度瓶颈

尽管 Kubernetes Scheduler 能选择最佳节点,但是在 Pod 开始运行之后,“最佳节点”可能会改变。所以从长远来看,Pod 的资源使用及其节点分配可能存在问题。

资源请求(Request)和限制(Limit):“Noisy Neighbor”

“Noisy Neighbor”并不特定于 Kubernetes。任何多租户系统都是它们的潜在地。假设有两个容器 A 和 B,它们在同一节点上运行。如果 Pod B 试图通过消耗所有 CPU 或内存来创造 noise,Pod A 将出现问题。如果我们为容器设置了资源请求和限制就能控制住 neighbor。Kubernetes 将确保为容器安排其请求的资源,并且不会消耗超出其资源限制的资源。如果在生产中运行 Kubernetes,最好设置资源请求和限制以确保系统可靠。

系统进程资源不足

Kubernetes 节点主要是连接到 Kubernetes 控制平面的虚拟机。因此,节点上也有自己的操作系统和相关进程。如果 Kubernetes 工作负载消耗了所有资源,则这些节点将无法运行,并会发生各种问题问题。我们需要在 kubelet 中使用 –system -reserved 设置保留资源,以防止发生这种情况。

抢占或调度 Pod

如果 Kubernetes Scheduler 无法将 Pod 调度到可用节点,则可以从节点抢占(preempt)或驱逐(evict)一些 Pod 以分配资源。如果看到 Pod 在集群中移动而没有发现特定原因,可以使用优先级类对其进行定义。同样,如果没有调度好 Pod,并且正在等待其他 Pod,也需要检查其优先级。

以下是示例: