Scheduler extension Proposal #11470
Description
Kubernetes scheduler schedules based on resources managed by Kubernetes. Scheduling based on opaque resource counting helps extending this further. But when there is a need for contextual scheduling for resources managed outside of kubernetes(example: place a pod where its storage is), there is no mechanism to do it today.
The proposal is to make kubernetes scheduler extensible by adding the capability to make http calls out to another endpoint to help achieve this functionality. I am curious whether you think the cloud provider abstraction is the right abstraction for implementation.
Here is a rough draft of what I am thinking about. Would like to solicit community feedback
type SchedulerExtension interface {
// Filter based on provider implemented predicate functions.
Filter(pod *api.Pod, nodes *api.NodeList) (*api.NodeList, error)
// Prioritize based on provider implemented priority functions. Weight*priority is added up for each
// such priority function. The returned score is added to the score computed by Kubernetes
// scheduler. The total score is used to do the host selection.
Prioritize(pod *api.Pod, nodes *api.NodeList) (*scheduler/api.HostPriorityList, error)
// Inform the provider about the scheduling decision. This could also be done by the provider
// watching apiserver pods/binding endpoint.
Bind(pod *api.Pod, host string) error
// Inform the provider about the unbind. To be called by apiserver in pod deletion path. This could
// also be accomplished by watching apiserver pods endpoint.
Unbind(pod *api.Pod, host string) error
}