Scheduler Configuration [page]deterministic
You can customize the behavior of the `kube-scheduler` by writing a configuration file and passing its path as a command line argument.
A scheduling Profile allows you to configure the different stages of scheduling in the [kube-scheduler](#gloss:kube-scheduler). Each stage is exposed in an extension point. Plugins provide scheduling behaviors by implementing one or more of these extension points.
You can specify scheduling profiles by running `kube-scheduler --config <filename>`, using the KubeSchedulerConfiguration [v1](/docs/reference/config-api/kube-scheduler-config.v1/) struct.
A minimal configuration looks as follows:
```yaml apiVersion: kubescheduler.config.k8s.io/v1 kind: KubeSchedulerConfiguration clientConnection: kubeconfig: /etc/srv/kubernetes/kube-scheduler/kubeconfig ```
> Note: KubeSchedulerConfiguration v1beta3 is deprecated in v1.26 and is removed in v1.29. Please migrate KubeSchedulerConfiguration to [v1](/docs/reference/config-api/kube-scheduler-config.v1/).
## Profiles
A scheduling Profile allows you to configure the different stages of scheduling in the [kube-scheduler](#gloss:kube-scheduler). Each stage is exposed in an [extension point](#extension-points). [Plugins](#scheduling-plugins) provide scheduling behaviors by implementing one or more of these extension points.
You can configure a single instance of `kube-scheduler` to run [multiple profiles](#multiple-profiles).
### Extension points
Scheduling happens in a series of stages that are exposed through the following extension points:
1. `queueSort`: These plugins provide an ordering function that is used to sort pending Pods in the scheduling queue. Exactly one queue sort plugin may be enabled at a time. 1. `placementGenerate`: These plugins generate potential placements (sets of nodes) where a considered PodGroup could be scheduled. This extension point is only applicable to PodGroup scheduling and requires Workload scheduling to be enabled. 1. `placementScore`: These plugins score the placements proposed by `placementGenerate`, to pick the optimal placement for the considered PodGroup. 1. `preFilter`: These plugins are used to pre-process or check information about a Pod or the cluster before filtering. They can mark a pod as unschedulable. 1. `filter`: These plugins are the equivalent of Predicates in a scheduling Policy and are used to filter out nodes that can not run the Pod. Filters are called in the configured order. A pod is marked as unschedulable if no nodes pass all the filters. 1. `postFilter`: These plugins are called in their configured order when no feasible nodes were found for the pod. If any `postFilter` plugin marks the Pod _schedulable_, the remaining plugins are not called. 1. `preScore`: This is an informational extension point that can be used for doing pre-scoring work. 1. `score`: These plugins provide a score to each node that has passed the filtering phase. The scheduler will then select the node with the highest weighted scores sum. 1. `reserve`: This is an informational extension point that notifies plugins when resources have been reserved for a given Pod. Plugins also implement an `Unreserve` call that gets called in the case of failure during or after `Reserve`. 1. `permit`: These plugins can prevent or delay the binding of a Pod. 1. `preBind`: These plugins perform any work required before a Pod is bound. 1. `bind`: The plugins bind a Pod to a Node. `bind` plugins are called in order and once one has done the binding, the remaining plugins are skipped. At least one bind plugin is required. 1. `postBind`: This is an informational extension point that is called after a Pod has been bound. 1. `multiPoint`: This is a config-only field that allows plugins to be enabled or disabled for all of their applicable extension points simultaneously.
For each extension point, you could disable specific [default plugins](#scheduling-pl …(trimmed)