You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This commit was created on GitHub.com and signed with GitHub’s verified signature.
The key has expired.
Functionality
Complete the design and code development of all the components (distributor, dispatcher, all new CRD controllers, scheduler and resource collector) of the global scheduling platform
Complete the integration and end-to-end testing
Enhance the code design/implementation to allow the global scheduling platform components, such as scheduler, distributor, dispatcher, and cluster to be created in any sequence, and can scale out/in independent of each other
Design and implement a proxy and watch mechanism to support synchronous VM POD and CRUD restful APIs
Design and Implement allocation/batch POD resource API
Add resource capacity deduction of a site after scheduling a pod to a site
Enhance the code quality so that VM POD spec with partial geolocation or partial region/AZ info can be created properly
Performance
Identify the performance bottlenecks of the distributor, dispatcher, and CRD controllers, and optimize code design/implementation to support 1000 clusters, 100 pods/s QPS, and 100 allocations/s
Redesign and re-implement the scheduler component and the resource collector component, which dramatically reduces the average end-to-end scheduling latency per POD from 433ms to 6ms. The test result can be found here
Add allocations to global resource scheduler components. The allocation test scenario has 1000 clusters, and the user sends 1000 allocation requests (each allocation has one VM resource) in one shot. The end-to-end scheduling latency per allocation is now within 6ms