koord-scheduler: support force sync data from informer#830
Conversation
Codecov ReportBase: 67.93% // Head: 67.93% // Increases project coverage by
Additional details and impacted files@@ Coverage Diff @@
## main #830 +/- ##
=======================================
Coverage 67.93% 67.93%
=======================================
Files 216 217 +1
Lines 24381 24432 +51
=======================================
+ Hits 16564 16599 +35
- Misses 6668 6685 +17
+ Partials 1149 1148 -1
Flags with carried forward coverage won't be shown. Click here to find out more.
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. ☔ View full report at Codecov. |
205cf28 to
197e512
Compare
197e512 to
08372e8
Compare
|
Discussion from kubernetes kubernetes/kubernetes#113763 |
08372e8 to
79e1d0f
Compare
79e1d0f to
3a6927d
Compare
Signed-off-by: Joseph <joseph.t.lee@outlook.com>
3a6927d to
b7f2eba
Compare
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: buptcozy The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
/lgtm |
|
/milestone v1.1 |
Signed-off-by: Joseph joseph.t.lee@outlook.com
Ⅰ. Describe what this PR does
Currently, the existing scheduling plugins of koord-scheduler will construct the internal state data of the plugin based on the data in the Informer, such as which Pods are maintained in NodeNUMAResource and which CPUs are allocated, which Pods are maintained in DeviceShare and which GPU instances are allocated, and so on. These data must be correct, otherwise it may cause problems with the resources allocated during Pod scheduling, or the orchestration results may not meet expectations, which will seriously affect the runtime problems or availability of workloads.
In the current existing code, the EventHandler is registered with the Informer, and the internal state can be constructed after WaitForCacheSync returns, but WaitForCacheSync only means that the data queried from the APIServer is synchronized to the Store inside the Informer, and does not perceive the Event in the EventHandler whether processing is complete. This also means that when WaitForCacheSync returns, EventHandler may not have finished processing the existing Add Event, and this problem will be more obvious in a larger cluster.
Therefore, we need a mechanism that can help the plugin to correctly convert the data in the Informer to the internal state of the plugin, and ensure that subsequent Add/Update/Delete Events can be processed correctly. Hence the introduction of
ForceSyncedEventHandler.When the plugin is initialized, you can register the EventHandler through
frameworkexthelp.ForceSyncFromInformer. This function will automatically start the Informer, and wait for the data to be synchronized successfully before pouring the current data into the EventHandler.