Merge pull request #5674 from ingvagabund/sig-scheduling-code-architecture
sig-scheduling: Scheduler code hierarchy overview
This commit is contained in:
Kubernetes Prow Robot
GitHub
commit
fce5c5dd57
Binary file not shown.
|
After Width: | Height: | Size: 28 KiB |
|
|
@ -0,0 +1,286 @@
|
|||
# Scheduler code hierarchy overview
|
||||
|
||||
## Introduction
|
||||
|
||||
The scheduler watches for newly created Pods that have no Node assigned.
|
||||
For every Pod that the scheduler discovers, the scheduler becomes responsible
|
||||
for finding the best Node for that Pod to run on.
|
||||
Scheduling in general is quite an extensive field in computer science which takes
|
||||
into account various range of constraints and limitations.
|
||||
Each workload may require a different approach to achieve optimal scheduling results.
|
||||
The kube-scheduler provided by Kubernetes project was constructed with a goal
|
||||
to provide high throughput at the cost of being simple.
|
||||
To help in building a scheduler (the default or a custom one) and to share
|
||||
elements of the scheduling logic,
|
||||
[the scheduling framework](https://kubernetes.io/docs/concepts/scheduling-eviction/scheduling-framework/)
|
||||
was implemented.
|
||||
The framework does not provide all pieces to build a new scheduler from scratch.
|
||||
Queues, caches, scheduling algorithms and other building elements are still needed to assemble
|
||||
a fully functional unit. This document aims at describing how all the individual
|
||||
pieces are put together and what’s their role in the overall architecture
|
||||
so a developer can quickly orient in the code.
|
||||
|
||||
## Scheduling a pod
|
||||
|
||||
The default scheduler instance has a loop running indefinitely
|
||||
which (everytime there’s a pod) is responsible for invoking the scheduling logic
|
||||
and making sure a pod gets either a node assigned or requeued for future processing.
|
||||
Each loop consists of a blocking scheduling and a non-blocking binding cycle.
|
||||
The scheduling cycle is responsible for running the scheduling algorithm selecting
|
||||
the most suitable node for placing the pod.
|
||||
The binding cycle makes sure the kube-apiserver is made aware of the selected
|
||||
node at the right time. A pod may be bound immediately, or in the case of gang scheduling,
|
||||
wait until all its sibling pods have their node assigned.
|
||||
|
||||
### Scheduling cycle
|
||||
|
||||
Each cycle honors the following steps:
|
||||
1. Get the next pod for scheduling
|
||||
1. Schedule a pod with provided algorithm
|
||||
1. If a pod fails to be scheduled due to `FitError`, run preemption plugin in
|
||||
`PostFilterPlugin` (if the plugin is registered) to nominate a node where
|
||||
the pods can run. If preemption was successful,
|
||||
let the current pod be aware of the nominated node.
|
||||
Handle the error, get the next pod and start over.
|
||||
1. If the scheduling algorithm finds a suitable node, store the pod into
|
||||
the scheduler cache (`AssumePod` operation) and run plugins from the `Reserve`
|
||||
and `Permit` extension point in that order. In case any of the plugins fails,
|
||||
end the current scheduling cycle, increase relevant metrics and handle
|
||||
the scheduling error through the `Error` handler.
|
||||
1. Upon successfully running all extension points, proceed to the binding cycle.
|
||||
At the same time start processing another pod (if there’s any).
|
||||
|
||||
### Binding cycle
|
||||
|
||||
Consists of the following four steps ran in the same order:
|
||||
- Invoking [WaitOnPermit](https://github.com/kubernetes/kubernetes/blob/a651804427dd9a15bb91e1c4fb7a79994e4817a2/pkg/scheduler/scheduler.go#L560)
|
||||
(internal API) of plugins from `Permit` extension point. Some plugins from the extension point
|
||||
may send a request for an operation requiring to wait for a condition
|
||||
(e.g. wait for additional resources to be available or wait for all pods
|
||||
in a gang to be assumed).
|
||||
Under the hood, `WaitOnPermit` waits for such a condition to be met within a timeout threshold.
|
||||
- Invoking plugins from [PreBind](https://github.com/kubernetes/kubernetes/blob/a651804427dd9a15bb91e1c4fb7a79994e4817a2/pkg/scheduler/scheduler.go#L580) extension point
|
||||
- Invoking plugins from [Bind](https://github.com/kubernetes/kubernetes/blob/a651804427dd9a15bb91e1c4fb7a79994e4817a2/pkg/scheduler/scheduler.go#L592) extension point
|
||||
- Invoking plugins from [PostBind](https://github.com/kubernetes/kubernetes/blob/a651804427dd9a15bb91e1c4fb7a79994e4817a2/pkg/scheduler/scheduler.go#L611) extension point
|
||||
|
||||
In case of processing of any of the extension points fails, `Unreserve` operation
|
||||
of all `Reserve` plugins is invoked (e.g. free resources allocated for a gang of pods).
|
||||
|
||||
## Configuring and assembling the scheduler
|
||||
|
||||
The scheduler codebase spans across various locations. Last but not least to mention:
|
||||
- [cmd/kube-scheduler/app](https://github.com/kubernetes/kubernetes/tree/a651804427dd9a15bb91e1c4fb7a79994e4817a2/cmd/kube-scheduler/app):
|
||||
location of the controller code alongside definition of CLI arguments (honors the standard setup for all Kubernetes controllers)
|
||||
- [pkg/scheduler](https://github.com/kubernetes/kubernetes/tree/a651804427dd9a15bb91e1c4fb7a79994e4817a2/pkg/scheduler):
|
||||
the default scheduler codebase root directory
|
||||
- [pkg/scheduler/core](https://github.com/kubernetes/kubernetes/tree/a651804427dd9a15bb91e1c4fb7a79994e4817a2/pkg/scheduler/core):
|
||||
location of the default scheduling algorithm
|
||||
- [pkg/scheduler/framework](https://github.com/kubernetes/kubernetes/tree/a651804427dd9a15bb91e1c4fb7a79994e4817a2/pkg/scheduler/framework):
|
||||
scheduling framework alongside plugins
|
||||
- [pkg/scheduler/internal](https://github.com/kubernetes/kubernetes/tree/a651804427dd9a15bb91e1c4fb7a79994e4817a2/pkg/scheduler/internal):
|
||||
implementation of the cache, queues and other internal elements
|
||||
- [staging/src/k8s.io/kube-scheduler](https://github.com/kubernetes/kubernetes/tree/a651804427dd9a15bb91e1c4fb7a79994e4817a2/staging/src/k8s.io/kube-scheduler):
|
||||
location of ComponentConfig API types
|
||||
- [test/e2e/scheduling](https://github.com/kubernetes/kubernetes/tree/a651804427dd9a15bb91e1c4fb7a79994e4817a2/test/e2e/scheduling):
|
||||
scheduling e2e
|
||||
- [test/integration/scheduler](https://github.com/kubernetes/kubernetes/tree/a651804427dd9a15bb91e1c4fb7a79994e4817a2/test/integration/scheduler)
|
||||
scheduling integration tests
|
||||
- [test/integration/scheduler_perf](https://github.com/kubernetes/kubernetes/tree/a651804427dd9a15bb91e1c4fb7a79994e4817a2/test/integration/scheduler_perf)
|
||||
scheduling performance benchmarks
|
||||
|
||||
### Initial startup configuration
|
||||
|
||||
Code under `cmd/kube-scheduler/app` is responsible for collecting scheduler
|
||||
configuration and initializing logic allowing the kube-scheduler to run
|
||||
as part of the Kubernetes control plane. The code includes:
|
||||
- Initializing [command line options](https://github.com/kubernetes/kubernetes/blob/a651804427dd9a15bb91e1c4fb7a79994e4817a2/cmd/kube-scheduler/app/server.go#L96)
|
||||
(along with a default `ComponentConfig`) and [validation](https://github.com/kubernetes/kubernetes/blob/a651804427dd9a15bb91e1c4fb7a79994e4817a2/cmd/kube-scheduler/app/server.go#L300)
|
||||
- Initializing [metrics](https://github.com/kubernetes/kubernetes/blob/a651804427dd9a15bb91e1c4fb7a79994e4817a2/cmd/kube-scheduler/app/server.go#L238)
|
||||
(`/metrics`), [health check](https://github.com/kubernetes/kubernetes/blob/a651804427dd9a15bb91e1c4fb7a79994e4817a2/cmd/kube-scheduler/app/server.go#L268)
|
||||
(`/healthz`) and [other handlers](https://github.com/kubernetes/kubernetes/blob/a651804427dd9a15bb91e1c4fb7a79994e4817a2/cmd/kube-scheduler/app/server.go#L225-L236)
|
||||
(authorization, authentication, panic recovery, etc.)
|
||||
- Reading and defaulting configuration of [KubeSchedulerConfiguration](https://github.com/kubernetes/kubernetes/blob/4740173f3378ef9d0dc59b0aa9299444a97d0818/pkg/scheduler/apis/config/types.go#L49-L106)
|
||||
- Building a registry with plugins (in-tree, [out-of-tree](https://github.com/kubernetes/kubernetes/blob/a651804427dd9a15bb91e1c4fb7a79994e4817a2/cmd/kube-scheduler/app/server.go#L312-L317))
|
||||
- Initializing the scheduler with various options such as [profiles, algorithm source, pod back off, etc.](https://github.com/kubernetes/kubernetes/blob/a651804427dd9a15bb91e1c4fb7a79994e4817a2/cmd/kube-scheduler/app/server.go#L326-L337)
|
||||
- Invocation of [LogOrWriteConfig](https://github.com/kubernetes/kubernetes/blob/a651804427dd9a15bb91e1c4fb7a79994e4817a2/cmd/kube-scheduler/app/server.go#L342) which logs the final scheduler configuration for debugging purposes
|
||||
- Right before running, `/configz` [is registered](https://github.com/kubernetes/kubernetes/blob/a651804427dd9a15bb91e1c4fb7a79994e4817a2/cmd/kube-scheduler/app/server.go#L141),
|
||||
[events broadcaster started](https://github.com/kubernetes/kubernetes/blob/a651804427dd9a15bb91e1c4fb7a79994e4817a2/cmd/kube-scheduler/app/server.go#L148),
|
||||
[leader election initiated](https://github.com/kubernetes/kubernetes/blob/a651804427dd9a15bb91e1c4fb7a79994e4817a2/cmd/kube-scheduler/app/server.go#L198-L216),
|
||||
and [the server](https://github.com/kubernetes/kubernetes/blob/a651804427dd9a15bb91e1c4fb7a79994e4817a2/cmd/kube-scheduler/app/server.go#L185)
|
||||
with all the configured handlers and [informers](https://github.com/kubernetes/kubernetes/blob/a651804427dd9a15bb91e1c4fb7a79994e4817a2/cmd/kube-scheduler/app/server.go#L192)
|
||||
is started.
|
||||
|
||||
Once initialized, the scheduler can run.
|
||||
|
||||
In more detail, there’s a [Setup](https://github.com/kubernetes/kubernetes/blob/a651804427dd9a15bb91e1c4fb7a79994e4817a2/cmd/kube-scheduler/app/server.go#L299)
|
||||
function accomplishing what is essentially
|
||||
the initialization of the scheduler’s core process.
|
||||
First, it validates the options that have been passed through (the flags added
|
||||
in `NewSchedulerCommand()` are set directly on this options struct’s fields).
|
||||
If the options passed so far don’t raise any errors, it then calls `opts.Config()`
|
||||
which sets up the final internal settings including secure serving, leader election,
|
||||
clients, and begins parsing options related to the algorithm source
|
||||
(like loading config files and initializing empty profiles as well as handling
|
||||
deprecated options like policy config). The next lines call `c.Complete()` to complete
|
||||
the config by filling in any empty values. At this point any out-of-tree plugins
|
||||
are registered by creating a blank registry and adding entries in that registry
|
||||
for each plugin’s New function. It should be noted that the Registry is simply
|
||||
a map of plugin names to their factory functions. For the default scheduler,
|
||||
this step does nothing (because our main function in `cmd/kube-scheduler/scheduler.go`
|
||||
passes nothing to `NewSchedulerCommand()`).
|
||||
This means the default set of plugins is initialized in `scheduler.New()`.
|
||||
|
||||
Given the initialization is performed outside the scheduling framework,
|
||||
different consumers of the framework can initialize the environment differently
|
||||
to cover their needs. For example, a simulator can inject its own object
|
||||
through informers. Or custom plugins may be provided instead of the default ones.
|
||||
Known consumers of the scheduling framework:
|
||||
- [cluster-autoscaler](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/simulator/scheduler_based_predicates_checker.go#L48-L79)
|
||||
- [cluster-capacity](https://github.com/kubernetes-sigs/cluster-capacity/blob/8e9c2dcf3644cb5f73fca3d35d4e22899c265ad5/pkg/framework/simulator.go#L370-L383)
|
||||
|
||||
### Assembling the scheduler
|
||||
|
||||
The code is located under `pkg/scheduler`.
|
||||
This is where implementation of the default scheduler lives.
|
||||
Various elements of the scheduler are initialized and put together here:
|
||||
- Default scheduling options such as node percentage, initial and maximum backoff, profiles
|
||||
- Scheduler cache and queues
|
||||
- Scheduling profiles instantiated to tailor a framework for each profile
|
||||
to better suit pod placement (each profile defines a set of plugins to use)
|
||||
- Handler functions for getting the next pod for scheduling (`NextPod`) and error handling (`Error`)
|
||||
|
||||
The following steps are taken during the process of creating a scheduler instance:
|
||||
- Scheduler [cache is initialized](https://github.com/kubernetes/kubernetes/blob/a651804427dd9a15bb91e1c4fb7a79994e4817a2/pkg/scheduler/scheduler.go#L206)
|
||||
- Both in-tree and out-of-tree registries with plugins are [merged together](https://github.com/kubernetes/kubernetes/blob/a651804427dd9a15bb91e1c4fb7a79994e4817a2/pkg/scheduler/scheduler.go#L208-L211)
|
||||
- Metrics are [registered](https://github.com/kubernetes/kubernetes/blob/a651804427dd9a15bb91e1c4fb7a79994e4817a2/pkg/scheduler/scheduler.go#L232)
|
||||
- [Configurator](https://github.com/kubernetes/kubernetes/blob/a651804427dd9a15bb91e1c4fb7a79994e4817a2/pkg/scheduler/scheduler.go#L215-L230)
|
||||
building a scheduler instance (wiring the cache, plugin registry,
|
||||
scheduling algorithm and other elements together)
|
||||
- Event handlers [are registered](https://github.com/kubernetes/kubernetes/blob/a651804427dd9a15bb91e1c4fb7a79994e4817a2/pkg/scheduler/scheduler.go#L273)
|
||||
to allow the scheduler to react on changes in PVs,
|
||||
PVCs, services and other objects relevant for scheduling (eventually,
|
||||
each plugin will define a set of events on which it reacts,
|
||||
see [kubernetes/kubernetes#100347](https://github.com/kubernetes/kubernetes/issues/100347)
|
||||
for more details).
|
||||
|
||||
The following diagram shows how individual elements are connected together
|
||||
once initialized. Event handlers make sure pods are properly enqueued
|
||||
in the [scheduling queues](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-scheduling/scheduler_queues.md),
|
||||
the cache is updated with pods and nodes
|
||||
as they go (to provide up-to-date snapshot). Scheduling algorithm and the binding cycle
|
||||
have the right instances of the framework available (one instance of the framework per a profile).
|
||||
|
||||
|
||||
|
||||
#### Scheduling framework
|
||||
|
||||
Its code is currently located under `pkg/scheduler/framework`.
|
||||
It contains [various plugins](https://github.com/kubernetes/kubernetes/tree/a651804427dd9a15bb91e1c4fb7a79994e4817a2/pkg/scheduler/framework/plugins)
|
||||
responsible for filtering and scoring nodes (among others).
|
||||
Used as building blocks for any scheduling algorithm.
|
||||
|
||||
When a [plugin is initialized](https://github.com/kubernetes/kubernetes/blob/4740173f3378ef9d0dc59b0aa9299444a97d0818/pkg/scheduler/framework/runtime/framework.go#L310),
|
||||
it’s passed a [framework handler](https://github.com/kubernetes/kubernetes/blob/4740173f3378ef9d0dc59b0aa9299444a97d0818/pkg/scheduler/framework/runtime/framework.go#L251-L264)
|
||||
which provides interfaces to access and/or manipulate pods, nodes, clientset,
|
||||
event recorder and other handlers every plugin needs to implement its functionality.
|
||||
|
||||
#### Scheduler cache
|
||||
|
||||
Cache is responsible for capturing the current state of a cluster.
|
||||
Keeping a list of nodes and assumed pods alongside states of pods and images.
|
||||
The cache provides methods for reconciling pod and node objects
|
||||
(invoked through event handlers) keeping the state of the cluster up to date.
|
||||
Allowing to update the snapshot of a cluster (to pin the cluster state while a scheduling
|
||||
algorithm is run) with the latest state at the beginning of each scheduling cycle.
|
||||
|
||||
The cache also allows to run assume operation which temporarily stores a pod
|
||||
in the cache and makes it look as the pod is actually already
|
||||
running on a designated node for all consumers of the snapshot.
|
||||
Assume operation exists to remove the time the pod actually gets updated
|
||||
on the kube-apiserver side and thus increasing the scheduler’s throughput.
|
||||
The following operations manipulate with the assumed pods:
|
||||
- `AssumePod`: to signal the scheduling algorithm found a feasible node so the next
|
||||
pod can be attempted while the current pod enters the binding cycle
|
||||
- `FinishBinding`: used to signal Bind finished so the pod can be removed
|
||||
from the list of assumed pods
|
||||
- `ForgetPod`: removes pod from the list of assumed pods, used in case the pod
|
||||
fails to get processed in the binding cycle successfully
|
||||
(e.g. during `Reserve`, `Permit`, `PreBind` or `Bind` evaluation)
|
||||
|
||||
The cache keeps track of the following three metrics:
|
||||
- `scheduler_cache_size_assumed_pods`: number of pods in the assume pods list
|
||||
- `scheduler_cache_size_pods`: number of pods in the cache
|
||||
- `scheduler_cache_size_nodes`: number of nodes in the cache
|
||||
|
||||
#### Snapshot
|
||||
|
||||
The [snapshot](https://github.com/kubernetes/kubernetes/blob/a651804427dd9a15bb91e1c4fb7a79994e4817a2/pkg/scheduler/internal/cache/snapshot.go)
|
||||
captures the state of a cluster carrying information about all nodes
|
||||
in a cluster and objects located on each node.
|
||||
Namely node objects, pods assigned on each node, requested resources of all pods
|
||||
on each node, node’s allocatable, images pulled and other information needed
|
||||
to make a scheduling decision. Every time a pod is scheduled,
|
||||
a snapshot of the current state of the cluster is captured.
|
||||
To avoid a case where a pod or node gets changed while plugins are processed
|
||||
which might lead to data inconsistency as some plugins might get a different
|
||||
view of the cluster.
|
||||
|
||||
#### Configurator
|
||||
|
||||
A [configurator](https://github.com/kubernetes/kubernetes/blob/a651804427dd9a15bb91e1c4fb7a79994e4817a2/pkg/scheduler/factory.go#L90)
|
||||
builds the scheduler instance by wiring plugins, cache, queues,
|
||||
handlers and other elements together. Each profile [is initialized](https://github.com/kubernetes/kubernetes/blob/a651804427dd9a15bb91e1c4fb7a79994e4817a2/pkg/scheduler/factory.go#L138-L147)
|
||||
with its own framework (with all frameworks sharing informers, event recorders, etc.).
|
||||
|
||||
At this point it’s still possible to have the configurator create the instance
|
||||
[from a policy file](https://github.com/kubernetes/kubernetes/blob/a651804427dd9a15bb91e1c4fb7a79994e4817a2/pkg/scheduler/factory.go#L213).
|
||||
Though, this approach is deprecated and will be removed
|
||||
from the configuration eventually. Keeping only the kube scheduler configuration
|
||||
as the only way to provide the configuration.
|
||||
|
||||
#### Default scheduling algorithm
|
||||
|
||||
The codebase defines a [ScheduleAlgorithm](https://github.com/kubernetes/kubernetes/blob/a651804427dd9a15bb91e1c4fb7a79994e4817a2/pkg/scheduler/core/generic_scheduler.go#L61-L66)
|
||||
interface.
|
||||
Any implementation of the interface can be used as a scheduling algorithm.
|
||||
There are two methods:
|
||||
- `Schedule`: responsible for scheduling a pod using plugins from `PreFilter`
|
||||
up to `NormalizeScore` extension points, provides [ScheduleResult](https://github.com/kubernetes/kubernetes/blob/a651804427dd9a15bb91e1c4fb7a79994e4817a2/pkg/scheduler/core/generic_scheduler.go#L70-L77)
|
||||
containing a scheduling decision (the most suitable nodes) with additional
|
||||
accompanying information such as how many nodes were evaluated
|
||||
and how many nodes were found feasible for scheduling.
|
||||
- `Extenders`: currently exposed only for testing
|
||||
|
||||
Each cycle of the default algorithm implementation consists of:
|
||||
1. Taking the [current snapshot](https://github.com/kubernetes/kubernetes/blob/a651804427dd9a15bb91e1c4fb7a79994e4817a2/pkg/scheduler/core/generic_scheduler.go#L101)
|
||||
from the scheduling cache
|
||||
1. [Filter out all nodes](https://github.com/kubernetes/kubernetes/blob/a651804427dd9a15bb91e1c4fb7a79994e4817a2/pkg/scheduler/core/generic_scheduler.go#L110)
|
||||
not feasible for scheduling a pod
|
||||
1. Run [PreFilter plugins](https://github.com/kubernetes/kubernetes/blob/a651804427dd9a15bb91e1c4fb7a79994e4817a2/pkg/scheduler/core/generic_scheduler.go#L230)
|
||||
first (preprocessing phase, e.g. computing pod [anti-]affinity relations)
|
||||
1. Run [Filter plugins](https://github.com/kubernetes/kubernetes/blob/a651804427dd9a15bb91e1c4fb7a79994e4817a2/pkg/scheduler/core/generic_scheduler.go#L261) in parallel:
|
||||
filter out all nodes which does not satisfy pod’s constraints
|
||||
(e.g. sufficient resources, node affinity, etc.), including running filter extenders
|
||||
1. Run [PostFilter plugins](https://github.com/kubernetes/kubernetes/blob/a651804427dd9a15bb91e1c4fb7a79994e4817a2/pkg/scheduler/scheduler.go#L479)
|
||||
if no node can fit the incoming pod
|
||||
1. In case there are at least two feasible nodes for scheduling, run [scoring plugins](https://github.com/kubernetes/kubernetes/blob/a651804427dd9a15bb91e1c4fb7a79994e4817a2/pkg/scheduler/core/generic_scheduler.go#L133):
|
||||
1. Run [PreScore plugins](https://github.com/kubernetes/kubernetes/blob/a651804427dd9a15bb91e1c4fb7a79994e4817a2/pkg/scheduler/core/generic_scheduler.go#L427)
|
||||
first (preprocessing phase)
|
||||
1. Run [Score plugins](https://github.com/kubernetes/kubernetes/blob/a651804427dd9a15bb91e1c4fb7a79994e4817a2/pkg/scheduler/core/generic_scheduler.go#L433) in parallel:
|
||||
each node is given a score vector (each coordinate corresponding to one plugin)
|
||||
1. Run [NormalizeScore plugins](https://github.com/kubernetes/kubernetes/blob/a651804427dd9a15bb91e1c4fb7a79994e4817a2/pkg/scheduler/framework/runtime/framework.go#L798):
|
||||
to have all plugins given a score in <0; 100> interval
|
||||
1. Compute [weighted score](https://github.com/kubernetes/kubernetes/blob/a651804427dd9a15bb91e1c4fb7a79994e4817a2/pkg/scheduler/framework/runtime/framework.go#L810-L828)
|
||||
for each node (each score plugin can have
|
||||
a weight assigned indicating how much its score is preferred over others)
|
||||
1. Run [score extenders](https://github.com/kubernetes/kubernetes/blob/a651804427dd9a15bb91e1c4fb7a79994e4817a2/pkg/scheduler/core/generic_scheduler.go#L456)
|
||||
and add it to the total score of each node
|
||||
1. [Select](https://github.com/kubernetes/kubernetes/blob/a651804427dd9a15bb91e1c4fb7a79994e4817a2/pkg/scheduler/core/generic_scheduler.go#L138)
|
||||
and [give back a node](https://github.com/kubernetes/kubernetes/blob/a651804427dd9a15bb91e1c4fb7a79994e4817a2/pkg/scheduler/core/generic_scheduler.go#L141-L145)
|
||||
with the highest score. If there’s only a [single feasible node](https://github.com/kubernetes/kubernetes/blob/a651804427dd9a15bb91e1c4fb7a79994e4817a2/pkg/scheduler/core/generic_scheduler.go#L125-L131)
|
||||
skip `PreScore`, `Score` and `NormalizeScore` extension points
|
||||
and give back the node right away. If there’s no feasible node, report it.
|
||||
|
||||
Be aware of:
|
||||
- If a plugin provides score normalization, it needs to return non-nil
|
||||
when [ScoreExtensions()](https://github.com/kubernetes/kubernetes/blob/a651804427dd9a15bb91e1c4fb7a79994e4817a2/pkg/scheduler/framework/plugins/podtopologyspread/scoring.go#L254-L256) gets invoked
|
||||
Loading…
Reference in New Issue