[feature]Support Scheduling Framework
- Dominant language
- Go
- Stars
- 515
- Forks
- 88
- PR merge metrics
- No merged PRs in 30d
Description
## Why you need it?
目前的调度扩展形式是 Extender,这种方式有一些缺点:
- 因为涉及到HTTP接口调用,会影响调度性能
- Extender每次更新cache前都会加锁,目前在大规模集群(500节点)下进行了压力测试(创建10000个使用存储卷的Pod),会发现tps较低,主要原因就是每次请求等待锁释放会耗时。
## How it could be?
如果改为 Scheduling Framework 形式,上面的两个问题可以解决:
- HTTP调用彻底消失
- Framework可以获取到Score的最终结果(Extender是不提供这种接口的,只有Filter、Score、Bind),在获取到 Node 结果后,将选择的存储设备名称以打标的方式标记在NLS上(也可能是其他资源),这样就可以去掉CSI组件->Extender的回调过程了,这样可以再进一步减少锁的使用。
## Other related information
Contributor guide
No contributing guide indexed for this repository
Research direction
Start by tracing the current Extender scheduling path and its CSI callback, then review the Kubernetes Scheduling Framework integration points. The issue provides no files or tests to begin with; done would mean removing the HTTP and callback paths while preserving storage-device selection and marking the chosen device on NLS or the specified resource.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go, kubernetes
- Domain
- devops, infrastructure
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 20/100