[question]There are some doubts when reading elastic quota scheduling

[VinceCui]

What happened:
When the quota req of group A is less than min, it can lend quota to other groups. If the req of group A rises, but there is no free quota globally, at this time, according to the documentation, it should trigger other groups evicting pods to release resources to ensure that the reasonable demands of group A are satisfied, but the following doubts are found:

1. In the PostFilter stage after the pod scheduling of group A fails, you only see that it will evict other low-quality pods in the same group, and you don't see the logic to trigger eviction in other groups.
2. The QuotaOverUsedRevokeController seems to do the above, but it only triggers periodically. As long as the Used of a group is greater than the Runtime, it will trigger eviction, which is also inconsistent with the description in the document.

What you expected to happen:

Environment:

• Koordinator version: - v0.6.2
• Kubernetes version (use kubectl version): v1.22.5
• docker/containerd version: containerd 1.5.0
• OS (e.g: cat /etc/os-release): Ubuntu 20.04.4 LTS
• Kernel (e.g. uname -a): Linux 5.10.112-11.al8.x86_64 ✨ Add NodeMetric API #1 SMP Tue May 24 16:05:50 CST 2022 x86_64 x86_64 x86_64 GNU/Linux

Anything else we need to know:

[eahydra]

Hi @VinceCui, What you mentioned "it should trigger other groups evicting pods to release resources to ensure that the reasonable demands of group A are satisfied" means that the overall Runtime has changed, and some Quota objects have Runtime less than Used and extra Part of it needs to be considered for deportation and release. But it does not mean that eviction must be performed immediately. In an actual production environment, Pods will be created and destroyed more frequently. At this moment, the runtime seen exceeds used, and it may be restored at the next moment.

[stale]

This issue has been automatically marked as stale because it has not had recent activity.
This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, the issue is closed
  You can:
• Mark this issue or PR as fresh with /remove-lifecycle stale
• Close this issue or PR with /close
  Thank you for your contributions.

[stale]

This issue has been automatically closed because it has not had recent activity.
This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, the issue is closed
  You can:
• Reopen this PR with /reopen
  Thank you for your contributions.