[question] 关于batch资源计算方式的疑问

[j4ckstraw]

What happened:

1. 为什么要引入一种按照request来计算batch资源的策略？
2. 对于koord-mid priority是否应该使用mid-cpu/mid-memory？
3. 接问题2，如果koord-mid priority使用mid-cpu/mid-memory资源，在按照request policy计算batch资源时，扣减High Priority Pod Request，这里podRequest计算有问题。
   https://github.com/koordinator-sh/koordinator/blob/f43d4fd947017b7b7fd4d6e453b171bf7387457f/pkg/slo-
   controller/noderesource/plugins/batchresource/plugin.go#L187C5-L187C5

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:

[saintube]

@j4ckstraw 感谢你的提问。
关于第1点，当前内存维度支持基于 request 的计算策略，可以用于满足仅 CPU 超卖的场景。
关于第2、3点，属于 batch 资源计算中对 Mid Pod request 的感知不准确，需要进行 bugfix，我们可以在此跟踪修复，感兴趣的话也欢迎你的贡献～

[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.