Kubernetes —调度器配置

这篇具有很好参考价值的文章主要介绍了Kubernetes —调度器配置。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

目录

配置文件

扩展点

调度插件

多配置文件

应用于多个扩展点的插件

调度程序配置迁移


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

调度模板(Profile)允许你配置 kube-scheduler 中的不同调度阶段。每个阶段都暴露于某个扩展点中。插件通过实现一个或多个扩展点来提供调度行为。

你可以通过运行 kube-scheduler --config <filename> 来设置调度模板, 使用 KubeSchedulerConfiguration v1 结构体。

最简单的配置如下:

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

说明:

KubeSchedulerConfiguration v1beta2 在 v1.25 中已弃用,并将在 v1.28 中移除。 KubeSchedulerConfiguration v1beta3 在 v1.26 中已弃用,并将在 v1.29 中移除。

请将 KubeSchedulerConfiguration 迁移到 v1。

配置文件

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

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

扩展点

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

  1. queueSort:这些插件对调度队列中的悬决的 Pod 排序。 一次只能启用一个队列排序插件。
  2. preFilter:这些插件用于在过滤之前预处理或检查 Pod 或集群的信息。 它们可以将 Pod 标记为不可调度。
  3. filter:这些插件相当于调度策略中的断言(Predicates),用于过滤不能运行 Pod 的节点。 过滤器的调用顺序是可配置的。 如果没有一个节点通过所有过滤器的筛选,Pod 将会被标记为不可调度。
  4. postFilter:当无法为 Pod 找到可用节点时,按照这些插件的配置顺序调用他们。 如果任何 postFilter 插件将 Pod 标记为可调度,则不会调用其余插件。
  5. preScore:这是一个信息扩展点,可用于预打分工作。
  6. score:这些插件给通过筛选阶段的节点打分。调度器会选择得分最高的节点。
  7. reserve:这是一个信息扩展点,当资源已经预留给 Pod 时,会通知插件。 这些插件还实现了 Unreserve 接口,在 Reserve 期间或之后出现故障时调用。
  8. permit:这些插件可以阻止或延迟 Pod 绑定。
  9. preBind:这些插件在 Pod 绑定节点之前执行。
  10. bind:这个插件将 Pod 与节点绑定。bind 插件是按顺序调用的,只要有一个插件完成了绑定,其余插件都会跳过。bind 插件至少需要一个。
  11. postBind:这是一个信息扩展点,在 Pod 绑定了节点之后调用。
  12. 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。

说明:

Pod 的调度事件把 .spec.schedulerName 字段值作为 ReportingController。 领导者选举事件使用列表中第一个配置文件的调度器名称。

说明:

所有配置文件必须在 queueSort 扩展点使用相同的插件,并具有相同的配置参数(如果适用)。 这是因为调度器只有一个保存 pending 状态 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

在这里使用 multiPoint 的一个好处是,如果 MyPlugin 将来实现另一个扩展点,multiPoint 配置将自动为新扩展启用它。

可以使用该扩展点的 disabled 字段将特定扩展点从 MultiPoint 扩展中排除。 这适用于禁用默认插件、非默认插件或使用通配符 ('*') 来禁用所有插件。 禁用 Score 和 PreScore 的一个例子是:

apiVersion: kubescheduler.config.k8s.io/v1
kind: KubeSchedulerConfiguration
profiles:
  - schedulerName: non-multipoint-scheduler
    plugins:
      multiPoint:
        enabled:
        - name: 'MyPlugin'
      preScore:
        disabled:
        - name: '*'
      score:
        disabled:
        - name: '*'

从 kubescheduler.config.k8s.io/v1beta3 开始,所有默认插件都通过 MultiPoint 在内部启用。 但是,仍然可以使用单独的扩展点来灵活地重新配置默认值(例如排序和分数权重)。 例如,考虑两个 Score 插件 DefaultScore1 和 DefaultScore2,每个插件的权重为 1。 它们可以用不同的权重重新排序,如下所示:

apiVersion: kubescheduler.config.k8s.io/v1
kind: KubeSchedulerConfiguration
profiles:
  - schedulerName: multipoint-scheduler
    plugins:
      score:
        enabled:
        - name: 'DefaultScore2'
          weight: 5

在这个例子中,没有必要在 MultiPoint 中明确指定插件,因为它们是默认插件。 Score 中指定的唯一插件是 DefaultScore2。 这是因为通过特定扩展点设置的插件将始终优先于 MultiPoint 插件。 因此,此代码段实质上重新排序了这两个插件,而无需同时指定它们。

配置 MultiPoint 插件时优先级的一般层次结构如下:

  1. 特定的扩展点首先运行,它们的设置会覆盖其他地方的设置
  2. 通过 MultiPoint 手动配置的插件及其设置
  3. 默认插件及其默认设置

为了演示上述层次结构,以下示例基于这些插件:

插件

扩展点

DefaultQueueSort

QueueSort

CustomQueueSort

QueueSort

DefaultPlugin1

Score, Filter

DefaultPlugin2

Score

CustomPlugin1

Score, Filter

CustomPlugin2

Score, Filter

这些插件的一个有效示例配置是:

apiVersion: kubescheduler.config.k8s.io/v1
kind: KubeSchedulerConfiguration
profiles:
  - schedulerName: multipoint-scheduler
    plugins:
      multiPoint:
        enabled:
        - name: 'CustomQueueSort'
        - name: 'CustomPlugin1'
          weight: 3
        - name: 'CustomPlugin2'
        disabled:
        - name: 'DefaultQueueSort'
      filter:
        disabled:
        - name: 'DefaultPlugin1'
      score:
        enabled:
        - name: 'DefaultPlugin2'

请注意,在特定扩展点中重新声明 MultiPoint 插件不会出错。 重新声明被忽略(并记录),因为特定的扩展点优先。

除了将大部分配置保存在一个位置之外,此示例还做了一些事情:

  • 启用自定义 queueSort 插件并禁用默认插件
  • 启用 CustomPlugin1 和 CustomPlugin2,这将首先为它们的所有扩展点运行
  • 禁用 DefaultPlugin1,但仅适用于 filter
  • 重新排序 DefaultPlugin2 以在 score 中首先运行(甚至在自定义插件之前)

在 v1beta3 之前的配置版本中,没有 multiPoint,上面的代码片段等同于:

apiVersion: kubescheduler.config.k8s.io/v1beta2
kind: KubeSchedulerConfiguration
profiles:
  - schedulerName: multipoint-scheduler
    plugins:

      # 禁用默认的 QueueSort 插件
      queueSort:
        enabled:
        - name: 'CustomQueueSort'
        disabled:
        - name: 'DefaultQueueSort'

      # 启用自定义的 Filter 插件
      filter:
        enabled:
        - name: 'CustomPlugin1'
        - name: 'CustomPlugin2'
        - name: 'DefaultPlugin2'
        disabled:
        - name: 'DefaultPlugin1'

      # 启用并重新排序自定义的打分插件
      score:
        enabled:
        - name: 'DefaultPlugin2'
          weight: 1
        - name: 'DefaultPlugin1'
          weight: 3

虽然这是一个复杂的例子,但它展示了 MultiPoint 配置的灵活性以及它与配置扩展点的现有方法的无缝集成。文章来源地址https://www.toymoban.com/news/detail-644415.html

调度程序配置迁移

  • v1beta1 → v1beta2
  • v1beta2 → v1beta3
  • v1beta3 → v1
  • 在 v1beta2 配置版本中,你可以为 NodeResourcesFit 插件使用新的 score 扩展。 新的扩展结合了 NodeResourcesLeastAllocated、NodeResourcesMostAllocated 和 RequestedToCapacityRatio 插件的功能。 例如,如果你之前使用了 NodeResourcesMostAllocated 插件, 则可以改用 NodeResourcesFit(默认启用)并添加一个 pluginConfig 和 scoreStrategy,类似于:
  • apiVersion: kubescheduler.config.k8s.io/v1beta2 kind: KubeSchedulerConfiguration profiles: - pluginConfig: - args: scoringStrategy: resources: - name: cpu weight: 1 type: MostAllocated name: NodeResourcesFit
  • 调度器插件 NodeLabel 已弃用; 相反,要使用 NodeAffinity 插件(默认启用)来实现类似的行为。
  • 调度程序插件 ServiceAffinity 已弃用; 相反,使用 InterPodAffinity 插件(默认启用)来实现类似的行为。
  • 调度器插件 NodePreferAvoidPods 已弃用; 相反,使用 节点污点 来实现类似的行为。
  • 在 v1beta2 配置文件中启用的插件优先于该插件的默认配置。
  • 调度器的健康检查和审计的绑定地址,所配置的 host 或 port 无效将导致验证失败。

到了这里,关于Kubernetes —调度器配置的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • Kubernetes核心概念汇总—调度、抢占和驱逐

    在 Kubernetes 中,调度 (scheduling) 指的是确保 Pod 匹配到合适的节点, 以便 kubelet 能够运行它们。 抢占 (Preemption) 指的是终止低优先级的 Pod 以便高优先级的 Pod 可以调度运行的过程。 驱逐 (Eviction) 是在资源匮乏的节点上,主动让一个或多个 Pod 失效的过程。 调度 Kubernetes 调度器

    2024年02月12日
    浏览(43)
  • Linux6.37 Kubernetes 集群调度

    第三章 LINUX Kubernetes 集群调度 一、调度约束 当定义 Pod 时可以选择性地为每个容器设定所需要的资源数量。 最常见的可设定资源是 Kubernetes 是通过 List-Watch 的机制进行每个组件的协作,保持数据同步的,每个组件之间的设计实现了解耦。 用户是通过 kubectl 根据配置文件,向

    2024年02月13日
    浏览(32)
  • 当节点内存管理遇上 Kubernetes:自动调度与控制

    在现代的容器化环境中,节点资源的管理是一个重要的任务。特别是对于内存资源的管理,它直接影响着容器应用的性能和可用性。在 Kubernetes 中,我们可以利用自动调度和控制的机制来实现对节点内存的有效管理。本文将介绍一种基于 Bash 脚本的节点内存管理方案,并探讨

    2024年02月07日
    浏览(37)
  • 在CSDN学Golang云原生(Kubernetes Pod调度)

    在 Kubernetes 中,可以使用 NodeSelector 字段来指定 Pod 调度到哪些节点上运行。NodeSelector 是一个键值对的 map,其中键是节点的标签名,值是标签值。具体步骤如下: 在节点上添加标签 首先需要在节点上添加相应的标签,例如: 编写 Pod 的 YAML 文件 在编写 Pod 的 YAML 文件时,需

    2024年02月15日
    浏览(38)
  • CKA 10_Kubernetes工作负载与调度 资源调度 资源限制 LimitRanger 资源配额 ResourceQuota

    官方文档: 概念 | 策略 | 限制范围 官方文档: 概念 | 策略 | 资源配额 默认情况下, Kubernetes 集群上的容器运行使用的计算资源没有限制。 使用资源配额,集群管理员可以以名字空间为单位,限制其资源的使用与创建。 在命名空间中,一个 Pod 或 Container 最多能够使用命名空

    2024年02月08日
    浏览(66)
  • kubernetes scheduler 源码解析及自定义资源调度算法实践

    小到运行着几十个工作负载的 kubernetes 集群,大到运行成千上万个工作负载 kubernetes 集群,每个工作负载到底应该在哪里运行,这需要一个聪明的大脑进行指挥,kubernetes scheduler 就是这个聪明的大脑。从结果看,他的工作很简单,只是为 pod.spec.nodeName 填充上一个 node 的名字而

    2023年04月24日
    浏览(32)
  • 【容器化应用程序设计和开发】2.2 容器编排和Kubernetes调度

    往期回顾: 第一章:【云原生概念和技术】 第二章:2.1 容器化基础知识和Docker容器 第二章:2.2 Dockerfile 的编写和最佳实践 容器编排是指自动化部署、管理和运行容器化应用程序的过程。Kubernetes 是一个流行的容器编排平台,它提供了一种自动化的方式来创建、部署和管理容

    2024年02月03日
    浏览(41)
  • 研发工程师玩转Kubernetes——使用Node特性定向调度Pod

    在《研发工程师玩转Kubernetes——使用污点(taint)驱逐Pod》中我们提到亲和性(affinity)中的requiredDuringSchedulingIgnoredDuringExecution,它可以定向调度Pod。本节我们将使用相关特性完成定向调度的介绍。 我们先模拟Pod被部署在Master Node上的场景。这个时候我们可以使用nodeSelector对

    2024年02月08日
    浏览(46)
  • 飞天使-k8s知识点19-kubernetes实操4-资源调度 标签和选择器:Label与Selector的使用-版本回退

    添加label 资源调度 Deployment:创建与配置文件解析 rs pod deploy 的关联信息展示 Deployment:滚动更新 Deployment:回滚 回退版本实际操作

    2024年02月20日
    浏览(50)
  • 【kubernetes系列】Kubernetes之配置dashboard安装使用

    Dashboard 是基于网页的 Kubernetes 用户界面。 你可以使用 Dashboard 将容器应用部署到 Kubernetes 集群中,也可以对容器应用排错,还能管理集群资源。 你可以使用 Dashboard 获取运行在集群中的应用的概览信息,也可以创建或者修改 Kubernetes 资源 (如 Deployment,Job,DaemonSet 等等)。

    2024年02月07日
    浏览(41)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包