--- title: 调度器配置 content_type: concept weight: 20 --- {{< feature-state for_k8s_version="v1.19" state="beta" >}} 你可以通过编写配置文件,并将其路径传给 `kube-scheduler` 的命令行参数,定制 `kube-scheduler` 的行为。 调度模板(Profile)允许你配置 {{< glossary_tooltip text="kube-scheduler" term_id="kube-scheduler" >}} 中的不同调度阶段。每个阶段都暴露于某个扩展点中。插件通过实现一个或多个扩展点来提供调度行为。 你可以通过运行 `kube-scheduler --config ` 来设置调度模板, 使用 [KubeSchedulerConfiguration (v1beta1)](/docs/reference/config-api/kube-scheduler-config.v1beta1/) 结构体。 最简单的配置如下: ```yaml apiVersion: kubescheduler.config.k8s.io/v1beta1 kind: KubeSchedulerConfiguration clientConnection: kubeconfig: /etc/srv/kubernetes/kube-scheduler/kubeconfig ``` ## 配置文件 {#profiles} 通过调度配置文件,你可以配置 {{< glossary_tooltip text="kube-scheduler" term_id="kube-scheduler" >}} 在不同阶段的调度行为。 每个阶段都在一个[扩展点](#extension-points)中公开。 [调度插件](#scheduling-plugins)通过实现一个或多个扩展点,来提供调度行为。 你可以配置同一 `kube-scheduler` 实例使用[多个配置文件](#multiple-profiles)。 ### 扩展点 {#extensions-points} 调度行为发生在一系列阶段中,这些阶段是通过以下扩展点公开的: 1. `QueueSort`:这些插件对调度队列中的悬决的 Pod 排序。 一次只能启用一个队列排序插件。 2. `PreFilter`:这些插件用于在过滤之前预处理或检查 Pod 或集群的信息。 它们可以将 Pod 标记为不可调度。 3. `Filter`:这些插件相当于调度策略中的断言(Predicates),用于过滤不能运行 Pod 的节点。 过滤器的调用顺序是可配置的。 如果没有一个节点通过所有过滤器的筛选,Pod 将会被标记为不可调度。 4. `PreScore`:这是一个信息扩展点,可用于预打分工作。 5. `Score`:这些插件给通过筛选阶段的节点打分。调度器会选择得分最高的节点。 6. `Reserve`:这是一个信息扩展点,当资源已经预留给 Pod 时,会通知插件。 这些插件还实现了 `Unreserve` 接口,在 `Reserve` 期间或之后出现故障时调用。 7. `Permit`:这些插件可以阻止或延迟 Pod 绑定。 8. `PreBind`:这些插件在 Pod 绑定节点之前执行。 9. `Bind`:这个插件将 Pod 与节点绑定。绑定插件是按顺序调用的,只要有一个插件完成了绑定,其余插件都会跳过。绑定插件至少需要一个。 10. `PostBind`:这是一个信息扩展点,在 Pod 绑定了节点之后调用。 对每个扩展点,你可以禁用[默认插件](#scheduling-plugins)或者是启用自己的插件,例如: ```yaml apiVersion: kubescheduler.config.k8s.io/v1beta1 kind: KubeSchedulerConfiguration profiles: - plugins: score: disabled: - name: NodeResourcesLeastAllocated enabled: - name: MyCustomPluginA weight: 2 - name: MyCustomPluginB weight: 1 ``` 你可以在 `disabled` 数组中使用 `*` 禁用该扩展点的所有默认插件。 如果需要,这个字段也可以用来对插件重新顺序。 ### 调度插件 {#scheduling-plugin} 1. `UnReserve`:这是一个信息扩展点,如果一个 Pod 在预留后被拒绝,并且被 `Permit` 插件搁置,它就会被调用。 ## 调度插件 {#scheduling-plugins} 下面默认启用的插件实现了一个或多个扩展点: - `SelectorSpread`:对于属于 {{< glossary_tooltip text="Services" term_id="service" >}}、 {{< glossary_tooltip text="ReplicaSets" term_id="replica-set" >}} 和 {{< glossary_tooltip text="StatefulSets" term_id="statefulset" >}} 的 Pod,偏好跨多个节点部署。 实现的扩展点:`PreScore`,`Score`。 - `ImageLocality`:选择已经存在 Pod 运行所需容器镜像的节点。 实现的扩展点:`Score`。 - `TaintToleration`:实现了[污点和容忍](/zh/docs/concepts/scheduling-eviction/taint-and-toleration/)。 实现的扩展点:`Filter`,`Prescore`,`Score`。 - `NodeName`:检查 Pod 指定的节点名称与当前节点是否匹配。 实现的扩展点:`Filter`。 - `NodePorts`:检查 Pod 请求的端口在节点上是否可用。 实现的扩展点:`PreFilter`,`Filter`。 - `NodePreferAvoidPods`:基于节点的 {{< glossary_tooltip text="注解" term_id="annotation" >}} `scheduler.alpha.kubernetes.io/preferAvoidPods` 打分。 实现的扩展点:`Score`。 - `NodeAffinity`:实现了[节点选择器](/zh/docs/concepts/scheduling-eviction/assign-pod-node/#nodeselector) 和[节点亲和性](/zh/docs/concepts/scheduling-eviction/assign-pod-node/#node-affinity)。 实现的扩展点:`Filter`,`Score`. - `PodTopologySpread`:实现了 [Pod 拓扑分布](/zh/docs/concepts/workloads/pods/pod-topology-spread-constraints/)。 实现的扩展点:`PreFilter`,`Filter`,`PreScore`,`Score`。 - `NodeUnschedulable`:过滤 `.spec.unschedulable` 值为 true 的节点。 实现的扩展点:`Filter`。 - `NodeResourcesFit`:检查节点是否拥有 Pod 请求的所有资源。 实现的扩展点:`PreFilter`,`Filter`。 - `NodeResourcesBalancedAllocation`:调度 Pod 时,选择资源使用更为均衡的节点。 实现的扩展点:`Score`。 - `NodeResourcesLeastAllocated`:选择资源分配较少的节点。 实现的扩展点:`Score`。 - `VolumeBinding`:检查节点是否有请求的卷,或是否可以绑定请求的卷。 实现的扩展点: `PreFilter`、`Filter`、`Reserve`、`PreBind` 和 `Score`。 {{< note >}} 当 `VolumeCapacityPriority` 特性被启用时,`Score` 扩展点也被启用。 它优先考虑可以满足所需卷大小的最小 PV。 {{< /note >}} - `VolumeRestrictions`:检查挂载到节点上的卷是否满足卷提供程序的限制。 实现的扩展点:`Filter`。 - `VolumeZone`:检查请求的卷是否在任何区域都满足。 实现的扩展点:`Filter`。 - `NodeVolumeLimits`:检查该节点是否满足 CSI 卷限制。 实现的扩展点:`Filter`。 - `EBSLimits`:检查节点是否满足 AWS EBS 卷限制。 实现的扩展点:`Filter`。 - `GCEPDLimits`:检查该节点是否满足 GCP-PD 卷限制。 实现的扩展点:`Filter`。 - `AzureDiskLimits`:检查该节点是否满足 Azure 卷限制。 实现的扩展点:`Filter`。 - `InterPodAffinity`:实现 [Pod 间亲和性与反亲和性](/zh/docs/concepts/scheduling-eviction/assign-pod-node/#inter-pod-affinity-and-anti-affinity)。 实现的扩展点:`PreFilter`,`Filter`,`PreScore`,`Score`。 - `PrioritySort`:提供默认的基于优先级的排序。 实现的扩展点:`QueueSort`。 - `DefaultBinder`:提供默认的绑定机制。 实现的扩展点:`Bind`。 - `DefaultPreemption`:提供默认的抢占机制。 实现的扩展点:`PostFilter`。 你也可以通过组件配置 API 启用以下插件(默认不启用): - `NodeResourcesMostAllocated`:选择已分配资源多的节点。 实现的扩展点:`Score`。 - `RequestedToCapacityRatio`:根据已分配资源的某函数设置选择节点。 实现的扩展点:`Score`。 - `CinderVolume`:检查该节点是否满足 OpenStack Cinder 卷限制。 实现的扩展点:`Filter`。 - `NodeLabel`:根据配置的 {{< glossary_tooltip text="标签" term_id="label" >}} 过滤节点和/或给节点打分。 实现的扩展点:`Filter`,`Score`。 - `ServiceAffinity`:检查属于某个 {{< glossary_tooltip term_id="service" >}} 的 Pod 与配置的标签所定义的节点集是否适配。 这个插件还支持将属于某个 Service 的 Pod 分散到各个节点。 实现的扩展点:`PreFilter`,`Filter`,`Score`。 ### 多配置文件 {#multiple-profiles} 你可以配置 `kube-scheduler` 运行多个配置文件。 每个配置文件都有一个关联的调度器名称,并且可以在其扩展点中配置一组不同的插件。 使用下面的配置样例,调度器将运行两个配置文件:一个使用默认插件,另一个禁用所有打分插件。 ```yaml apiVersion: kubescheduler.config.k8s.io/v1beta1 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。 {{< note >}} Pod 的调度事件把 `.spec.schedulerName` 字段值作为 ReportingController。 领导者选举事件使用列表中第一个配置文件的调度器名称。 {{< /note >}} {{< note >}} 所有配置文件必须在 QueueSort 扩展点使用相同的插件,并具有相同的配置参数(如果适用)。 这是因为调度器只有一个保存 pending 状态 Pod 的队列。 {{< /note >}} ## {{% heading "whatsnext" %}} * 阅读 [kube-scheduler 参考](/zh/docs/reference/command-line-tools-reference/kube-scheduler/) * 了解[调度](/zh/docs/concepts/scheduling-eviction/kube-scheduler/) * 阅读 [kube-scheduler 配置 (v1beta1)](/zh/docs/reference/config-api/kube-scheduler-config.v1beta1/) 参考