Kubernetes 调度器学习

最新推荐文章于 2024-05-28 17:17:08 发布

忍冬行者

最新推荐文章于 2024-05-28 17:17:08 发布

阅读量272

点赞数 1

分类专栏： k8s 文章标签： kubernetes 学习

本文链接：https://blog.csdn.net/rendongxingzhe/article/details/126615400

版权

k8s 专栏收录该内容

52 篇文章 6 订阅

订阅专栏

在 Kubernetes 中，调度是指将 Pod 放置到合适的节点上，以便对应节点上的 Kubelet 能够运行这些 Pod。调度器通过 Kubernetes 的监测（Watch）机制来发现集群中新创建且尚未被调度到节点上的 Pod。调度器会将所发现的每一个未调度的 Pod 调度到一个合适的节点上来运行。、

kube-scheduler

kube-scheduler是 Kubernetes 集群的默认调度器，并且是集群控制平面的一部分，kube-scheduler 在设计上允许你自己编写一个调度组件并替换原有的 kube-scheduler。

kube-scheduler 调度流程

kube-scheduler 给一个 Pod 做调度选择时包含两个步骤：

1.过滤过滤阶段会将所有满足 Pod 调度需求的节点选出来，并且过滤掉不满足条件的节点

1.打分在打分阶段，调度器会为 Pod 从所有可调度节点中选取一个最合适的节点。根据当前启用的打分规则，调度器会给每一个可调度节点进行打分。最后，kube-scheduler 会将 Pod 调度到得分最高的节点上。如果存在多个得分最高的节点，kube-scheduler 会从中随机选取一个。

在 Kubernetes v1.23 版本之前，可以使用调度策略来指定 predicates 和 priorities 进程。例如，可以通过运行 kube-scheduler --policy-config-file <filename> 或者 kube-scheduler --policy-configmap <ConfigMap> 设置调度策略。

但是从 Kubernetes v1.23 版本开始，不再支持这种调度策略。同样地也不支持相关的 policy-config-file、policy-configmap、policy-configmap-namespace 和 use-legacy-policy-config 标志。你可以通过使用调度配置来实现类似的行为。

如果在predicates阶段没有找到合适的节点，pod会一直处于pending状态，不断重试调度，知道找到满足条件的节点为止。如果有多个节点满足条件，就继续priorities 进程，按照优先级对节点进行排序。

调度器配置

可以通过编写配置文件，并将其路径传给 kube-scheduler 的命令行参数，定制 kube-scheduler 的行为

你可以通过运行 kube-scheduler --config <filename> 来设置调度模板。

最简单的配置如下：

apiVersion: kubescheduler.config.k8s.io/v1
kind: KubeSchedulerConfiguration
clientConnection:
  kubeconfig: /etc/srv/kubernetes/kube-scheduler/kubeconfig

通过调度配置文件，你可以配置 kube-scheduler 在不同阶段的调度行为。每个阶段都在一个扩展点中公开。调度插件通过实现一个或多个扩展点，来提供调度行为。

你可以配置同一 kube-scheduler 实例使用多个配置文件

扩展点

调度行为发生在一系列阶段中，这些阶段是通过以下扩展点公开的：

queueSort：这些插件对调度队列中的悬决的 Pod 排序。一次只能启用一个队列排序插件。

preFilter：这些插件用于在过滤之前预处理或检查 Pod 或集群的信息。它们可以将 Pod 标记为不可调度。

filter：这些插件相当于调度策略中的断言（Predicates），用于过滤不能运行 Pod 的节点。过滤器的调用顺序是可配置的。如果没有一个节点通过所有过滤器的筛选，Pod 将会被标记为不可调度。

postFilter：当无法为 Pod 找到可用节点时，按照这些插件的配置顺序调用他们。如果任何 postFilter 插件将 Pod 标记为可调度，则不会调用其余插件。

preScore：这是一个信息扩展点，可用于预打分工作。

score：这些插件给通过筛选阶段的节点打分。调度器会选择得分最高的节点。

reserve：这是一个信息扩展点，当资源已经预留给 Pod 时，会通知插件。这些插件还实现了 Unreserve 接口，在 Reserve 期间或之后出现故障时调用。

permit：这些插件可以阻止或延迟 Pod 绑定。

preBind：这些插件在 Pod 绑定节点之前执行。

bind：这个插件将 Pod 与节点绑定。bind 插件是按顺序调用的，只要有一个插件完成了绑定，其余插件都会跳过。bind 插件至少需要一个。

postBind：这是一个信息扩展点，在 Pod 绑定了节点之后调用。

multiPoint：这是一个仅配置字段，允许同时为所有适用的扩展点启用或禁用插件

apiVersion: kubescheduler.config.k8s.io/v1
kind: KubeSchedulerConfiguration
profiles:
  - plugins:
      score:
        disabled:
        - name: PodTopologySpread
        enabled:
        - name: MyCustomPluginA
          weight: 2
        - name: MyCustomPluginB
          weight: 1

你可以在 disabled 数组中使用 * 禁用该扩展点的所有默认插件。如果需要，这个字段也可以用来对插件重新顺序

调度插件

下面默认启用的插件实现了一个或多个扩展点：

ImageLocality：选择已经存在 Pod 运行所需容器镜像的节点。

实现的扩展点：score。

TaintToleration：实现了污点和容忍。

实现的扩展点：filter、preScore、score。

NodeName：检查 Pod 指定的节点名称与当前节点是否匹配。

实现的扩展点：filter。

NodePorts：检查 Pod 请求的端口在节点上是否可用。

实现的扩展点：preFilter、filter。

NodeAffinity：实现了节点选择器和节点亲和性。

实现的扩展点：filter、score。

PodTopologySpread：实现了 Pod 拓扑分布。

实现的扩展点：preFilter、filter、preScore、score。

NodeUnschedulable：过滤 .spec.unschedulable 值为 true 的节点。

实现的扩展点：filter。

NodeResourcesFit：检查节点是否拥有 Pod 请求的所有资源。得分可以使用以下三种策略之一：LeastAllocated（默认）、MostAllocated 和 RequestedToCapacityRatio。

实现的扩展点：preFilter、filter、score。

NodeResourcesBalancedAllocation：调度 Pod 时，选择资源使用更为均衡的节点。

实现的扩展点：score。

VolumeBinding：检查节点是否有请求的卷，或是否可以绑定请求的卷。实现的扩展点：preFilter、filter、reserve、preBind 和 score。
说明：
当 VolumeCapacityPriority 特性被启用时，score 扩展点也被启用。它优先考虑可以满足所需卷大小的最小 PV。

VolumeRestrictions：检查挂载到节点上的卷是否满足卷提供程序的限制。

实现的扩展点：filter。

VolumeZone：检查请求的卷是否在任何区域都满足。

实现的扩展点：filter。

NodeVolumeLimits：检查该节点是否满足 CSI 卷限制。

实现的扩展点：filter。

EBSLimits：检查节点是否满足 AWS EBS 卷限制。

实现的扩展点：filter。

GCEPDLimits：检查该节点是否满足 GCP-PD 卷限制。

实现的扩展点：filter。

AzureDiskLimits：检查该节点是否满足 Azure 卷限制。

实现的扩展点：filter。

InterPodAffinity：实现 Pod 间亲和性与反亲和性。

实现的扩展点：preFilter、filter、preScore、score。

PrioritySort：提供默认的基于优先级的排序。

实现的扩展点：queueSort。

DefaultBinder：提供默认的绑定机制。

实现的扩展点：bind。

DefaultPreemption：提供默认的抢占机制。

实现的扩展点：postFilter。

你也可以通过组件配置 API 启用以下插件（默认不启用）：

CinderLimits：检查是否可以满足节点的 OpenStack Cinder 卷限制。实现的扩展点：filter

你可以配置 kube-scheduler 运行多个配置文件。每个配置文件都有一个关联的调度器名称，并且可以在其扩展点中配置一组不同的插件。

使用下面的配置样例，调度器将运行两个配置文件：一个使用默认插件，另一个禁用所有打分插件。

apiVersion: kubescheduler.config.k8s.io/v1
kind: KubeSchedulerConfiguration
profiles:
  - schedulerName: default-scheduler
  - schedulerName: no-scoring-scheduler
    plugins:
      preScore:
        disabled:
        - name: '*'
      score:
        disabled:
        - name: '*'

对于那些希望根据特定配置文件来进行调度的 Pod，可以在 .spec.schedulerName 字段指定相应的调度器名称。

默认情况下，将创建一个调度器名为 default-scheduler 的配置文件。这个配置文件包括上面描述的所有默认插件。声明多个配置文件时，每个配置文件中调度器名称必须唯一。

如果 Pod 未指定调度器名称，kube-apiserver 将会把调度器名设置为 default-scheduler。因此，应该存在一个调度器名为 default-scheduler 的配置文件来调度这些 Pod。

应用于多个扩展点的插件

从 kubescheduler.config.k8s.io/v1beta3 开始，配置文件配置中有一个附加字段 multiPoint，它允许跨多个扩展点轻松启用或禁用插件。 multiPoint 配置的目的是简化用户和管理员在使用自定义配置文件时所需的配置。

考虑一个插件，MyPlugin，它实现了 preScore、score、preFilter 和 filter 扩展点。要为其所有可用的扩展点启用 MyPlugin，配置文件配置如下所示：

apiVersion: kubescheduler.config.k8s.io/v1
kind: KubeSchedulerConfiguration
profiles:
  - schedulerName: multipoint-scheduler
    plugins:
      multiPoint:
        enabled:
        - name: MyPlugin

这相当于为所有扩展点手动启用 MyPlugin，如下所示：

apiVersion: kubescheduler.config.k8s.io/v1
kind: KubeSchedulerConfiguration
profiles:
  - schedulerName: non-multipoint-scheduler
    plugins:
      preScore:
        enabled:
        - name: MyPlugin
      score:
        enabled:
        - name: MyPlugin
      preFilter:
        enabled:
        - name: MyPlugin
      filter:
        enabled:
        - name: MyPlugin