koord-scheduler: Add non-preemptible feature in Elastic Quota Management

[tan90github]

Ⅰ. Describe what this PR does

Add non-preemptible feature in Elastic Quota Management

Ⅱ. Does this pull request fix one issue?

fixes #1473

Ⅲ. Describe how to verify it

Ⅳ. Special notes for reviews

V. Checklist

• I have written necessary docs and comments
• I have added necessary unit tests and integration tests
• All checks passed in make test

[codecov]

Codecov Report

Attention: 24 lines in your changes are missing coverage. Please review.

Comparison is base (14087cb) 65.91% compared to head (6750752) 65.90%.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1668      +/-   ##
==========================================
- Coverage   65.91%   65.90%   -0.01%     
==========================================
  Files         384      384              
  Lines       41568    41613      +45     
==========================================
+ Hits        27398    27426      +28     
- Misses      12137    12152      +15     
- Partials     2033     2035       +2     

Flag	Coverage Δ
unittests	65.90% <70.73%> (-0.01%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files	Coverage Δ
...heduler/plugins/elasticquota/core/quota_summary.go	0.00% <ø> (ø)
...kg/scheduler/plugins/elasticquota/plugin_helper.go	72.33% <100.00%> (+0.13%)	⬆️
...duler/plugins/elasticquota/quota_overuse_revoke.go	71.02% <0.00%> (-0.82%)	⬇️
pkg/scheduler/plugins/elasticquota/preempt.go	1.88% <0.00%> (-0.04%)	⬇️
pkg/webhook/elasticquota/pod_check.go	53.24% <0.00%> (-2.16%)	⬇️
.../scheduler/plugins/elasticquota/core/quota_info.go	82.48% <87.87%> (-0.63%)	⬇️
pkg/scheduler/plugins/elasticquota/plugin.go	57.60% <71.42%> (+1.77%)	⬆️
...r/plugins/elasticquota/core/group_quota_manager.go	73.90% <65.21%> (-0.35%)	⬇️

... and 3 files with indirect coverage changes

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[hormes]

After the non-preemptible Pod reaches min, should it be rejected now or should it remain pending?

[shaloulcy]

After the non-preemptible Pod reaches min, should it be rejected now or should it remain pending?

pending

[tan90github]

After the non-preemptible Pod reaches min, should it be rejected now or should it remain pending?

now it will pending

[shaloulcy]

/lgtm

[eahydra]

/lgtm
/approve

[eahydra]

/lgtm

[koordinator-bot]

[APPROVALNOTIFIER] This PR is APPROVED

Approval requirements bypassed by manually added approval.

This pull-request has been approved by: eahydra

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• apis/OWNERS
• pkg/scheduler/OWNERS [eahydra]
• pkg/webhook/OWNERS [eahydra]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment