fix bug of resource computing

[Garrybest]

Signed-off-by: Garrybest garrybest@foxmail.com

What type of PR is this?
/kind bug

What this PR does / why we need it:

1. If pod limits are specified, but requests are not, default requests to limits.
2. If Overhead is being utilized, add to the total requests for the pod.

Which issue(s) this PR fixes:
Fixes #

Special notes for your reviewer:

Does this PR introduce a user-facing change?:

karmada-scheduler: Fixed pod requested resource inaccuracy issue in case of pod limits specified but leaves request empty.

[RainbowMango]

cc @huone1
Could you please look at this PR?

[RainbowMango]

I wonder how and when the SetDefaults_Pod executed? Does the karmada-apiserver also set the defaults for Pod?

[Garrybest]

I wonder how and when the SetDefaults_Pod executed? Does the karmada-apiserver also set the defaults for Pod?

The api-server mutating webhook will set the default values. See here

[huone1]

the overhead resource data should be obtained through by RuntimeClass; the podtemplate shouldn't have the overhead info and the POD instance just contain the the overhead info

[RainbowMango]

/lgtm
/approve

[karmada-bot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: RainbowMango

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:

• OWNERS [RainbowMango]

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

[RainbowMango]

Discussed this with @huone1 locally, I get his concern now.

Since the karmada-apiserver only set overhead fields for Pod, but not for other workloads like Deployment, Job, etc.
So, the overhead will be always empty for these workloads, which means we can't get precise resource requirements.