About the Extender Webhook scheduler features

[antmoveh]

/kind feature /enhancement

The existing carina scheduling is extended in Framework V2 mode. The POD Scheduler field in the cluster must be Carina-Scheduler. Now let's discuss whether we need to add an Extender Webhook Scheduler

①: The Extender Webhook Scheduler is not added ②: Add an Extender Webhook Scheduler, and keep the existing scheduler ③: Replace the existing scheduler with the Extender Webhook Scheduler.

[antmoveh]

@ZhangZhenhua @zhangkai8048 @fanhaouu @duanhongyi

Please vote on the plan you support

[antmoveh]

@duanhongyi
You can add a description of the limitations of the scheduler

[duanhongyi]

I spent some time studying the Kube scheduler part of the code; The conclusion is that it is difficult to be compatible with 1.18-1.25; Since the versions of Kube API have changed greatly since 1.18, the Kube scheduler of each version after all basic versions is only compatible with Kube within two versions; For example, the version of Kube scheduler is 1.24, so it is only compatible with versions 1.24 and 1.25. I tested the schedulers of versions 1.22, 1.23, 1.24 and 1.25 respectively, and found that it is indeed impossible to achieve compatibility in the span of 1.18-1.25. Please refer to the official compatibility instructions of Kube for details:

https://kubernetes.io/releases/version-skew-policy/#kube-controller-manager-kube-scheduler-and-cloud-controller-manager

I wonder if it's better for us to switch the scheduler code from the framework mode to the extender webhook mode? This is only an independent HTTP service and does not depend on the scheduler framework related to the Kube version. The scheduler and Kube be be highly decoupled and more flexible. The disadvantage is that there is more scheduling cost.

[duanhongyi]

If the webhook method can perfectly replace the schedule framework method, there is no need to maintain an additional wheel. 🛞 🛞 🛞

This is my suggestion. 😄

[duanhongyi]

Perhaps we have another option, that is, to replace the scheduler with the storage capacity tracking mode; This has the following advantages:

1. Wider applicability. After all, using scheduler webhook in many managed clusters requires permission to configure kube-scheduler --config=xxx . At present, many clusters do not have this capability.
2. Storage capacity has no intrusion and compatibility problems of scheduler frame.

As a transitional scheme, we can keep the current scheduler frame scheme. Users can choose between 'scheduler' and 'storage capacity'. If we no longer need scheduler at a certain point in the future, we can delete the code of scheduler.

[fanhaouu]

@duanhongyi storage capacity only supports filter, can't score node

[antmoveh]

The scoring function is necessary, it is a scalable scheduling policy.

It is possible to make a webhook with only filtering functionality and no additional functionality

[duanhongyi]

评分功能是必要的，它是一个可扩展的调度策略。

可以制作仅具有过滤功能而没有附加功能的Webhook

+1

[antmoveh]

评分功能是必要的，它是一个可扩展的调度策略。 可以制作仅具有过滤功能而没有附加功能的Webhook

+1

即便额外增加一个webhook调度器 改动也是很大的，代码内部有很多关于scheduler:carina-scheduler的使用，而且并非简单改改值就可以的。