1 - 调度器配置
Kubernetes v1.19 [beta]
你可以通过编写配置文件,并将其路径传给 kube-scheduler
的命令行参数,定制 kube-scheduler
的行为。
调度模板(Profile)允许你配置 kube-scheduler 中的不同调度阶段。每个阶段都暴露于某个扩展点中。插件通过实现一个或多个扩展点来提供调度行为。
你可以通过运行 kube-scheduler --config <filename>
来设置调度模板,
使用 KubeSchedulerConfiguration (v1beta1) 结构体。
最简单的配置如下:
apiVersion: kubescheduler.config.k8s.io/v1beta1
kind: KubeSchedulerConfiguration
clientConnection:
kubeconfig: /etc/srv/kubernetes/kube-scheduler/kubeconfig
配置文件
通过调度配置文件,你可以配置 kube-scheduler 在不同阶段的调度行为。 每个阶段都在一个扩展点中公开。 调度插件通过实现一个或多个扩展点,来提供调度行为。
你可以配置同一 kube-scheduler
实例使用多个配置文件。
扩展点
调度行为发生在一系列阶段中,这些阶段是通过以下扩展点公开的:
QueueSort
:这些插件对调度队列中的悬决的 Pod 排序。 一次只能启用一个队列排序插件。
PreFilter
:这些插件用于在过滤之前预处理或检查 Pod 或集群的信息。 它们可以将 Pod 标记为不可调度。
Filter
:这些插件相当于调度策略中的断言(Predicates),用于过滤不能运行 Pod 的节点。 过滤器的调用顺序是可配置的。 如果没有一个节点通过所有过滤器的筛选,Pod 将会被标记为不可调度。
PreScore
:这是一个信息扩展点,可用于预打分工作。
Score
:这些插件给通过筛选阶段的节点打分。调度器会选择得分最高的节点。
Reserve
:这是一个信息扩展点,当资源已经预留给 Pod 时,会通知插件。 这些插件还实现了Unreserve
接口,在Reserve
期间或之后出现故障时调用。
Permit
:这些插件可以阻止或延迟 Pod 绑定。
PreBind
:这些插件在 Pod 绑定节点之前执行。
Bind
:这个插件将 Pod 与节点绑定。绑定插件是按顺序调用的,只要有一个插件完成了绑定,其余插件都会跳过。绑定插件至少需要一个。
PostBind
:这是一个信息扩展点,在 Pod 绑定了节点之后调用。
对每个扩展点,你可以禁用默认插件或者是启用自己的插件,例如:
apiVersion: kubescheduler.config.k8s.io/v1beta1
kind: KubeSchedulerConfiguration
profiles:
- plugins:
score:
disabled:
- name: NodeResourcesLeastAllocated
enabled:
- name: MyCustomPluginA
weight: 2
- name: MyCustomPluginB
weight: 1
你可以在 disabled
数组中使用 *
禁用该扩展点的所有默认插件。
如果需要,这个字段也可以用来对插件重新顺序。
调度插件
UnReserve
:这是一个信息扩展点,如果一个 Pod 在预留后被拒绝,并且被Permit
插件搁置,它就会被调用。
调度插件
下面默认启用的插件实现了一个或多个扩展点:
-
SelectorSpread
:对于属于 Services、 ReplicaSets 和 StatefulSets 的 Pod,偏好跨多个节点部署。实现的扩展点:
PreScore
,Score
。
-
ImageLocality
:选择已经存在 Pod 运行所需容器镜像的节点。实现的扩展点:
Score
。
-
TaintToleration
:实现了污点和容忍。实现的扩展点:
Filter
,Prescore
,Score
。
-
NodeName
:检查 Pod 指定的节点名称与当前节点是否匹配。实现的扩展点:
Filter
。
-
NodePorts
:检查 Pod 请求的端口在节点上是否可用。实现的扩展点:
PreFilter
,Filter
。
-
NodePreferAvoidPods
:基于节点的 注解scheduler.alpha.kubernetes.io/preferAvoidPods
打分。实现的扩展点:
Score
。
-
PodTopologySpread
:实现了 Pod 拓扑分布。实现的扩展点:
PreFilter
,Filter
,PreScore
,Score
。
-
NodeUnschedulable
:过滤.spec.unschedulable
值为 true 的节点。实现的扩展点:
Filter
。
-
NodeResourcesFit
:检查节点是否拥有 Pod 请求的所有资源。实现的扩展点:
PreFilter
,Filter
。
-
NodeResourcesBalancedAllocation
:调度 Pod 时,选择资源使用更为均衡的节点。实现的扩展点:
Score
。
-
NodeResourcesLeastAllocated
:选择资源分配较少的节点。实现的扩展点:
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 启用以下插件(默认不启用):
-
NodeResourcesMostAllocated
:选择已分配资源多的节点。实现的扩展点:
Score
。
-
RequestedToCapacityRatio
:根据已分配资源的某函数设置选择节点。实现的扩展点:
Score
。
-
CinderVolume
:检查该节点是否满足 OpenStack Cinder 卷限制。实现的扩展点:
Filter
。
-
NodeLabel
:根据配置的 标签 过滤节点和/或给节点打分。实现的扩展点:
Filter
,Score
。
-
ServiceAffinity
:检查属于某个 服务(Service) 的 Pod 与配置的标签所定义的节点集是否适配。 这个插件还支持将属于某个 Service 的 Pod 分散到各个节点。实现的扩展点:
PreFilter
,Filter
,Score
。
多配置文件
你可以配置 kube-scheduler
运行多个配置文件。
每个配置文件都有一个关联的调度器名称,并且可以在其扩展点中配置一组不同的插件。
使用下面的配置样例,调度器将运行两个配置文件:一个使用默认插件,另一个禁用所有打分插件。
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。
Pod 的调度事件把 .spec.schedulerName
字段值作为 ReportingController。
领导者选举事件使用列表中第一个配置文件的调度器名称。
所有配置文件必须在 QueueSort 扩展点使用相同的插件,并具有相同的配置参数(如果适用)。 这是因为调度器只有一个保存 pending 状态 Pod 的队列。
接下来
- 阅读 kube-scheduler 参考
- 了解调度
- 阅读 kube-scheduler 配置 (v1beta1) 参考
2 - 调度策略
在 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
标志。
你可以通过使用 调度配置来实现类似的行为。
接下来
- 了解 调度。
- 了解 kube-scheduler 配置。
- 阅读 kube-scheduler 配置参考(v1beta3)。