resourceModels supports extended resources

[chaosi-zju]

What type of PR is this?

/kind feature

What this PR does / why we need it:

resourceModels supports extended resources

Which issue(s) this PR fixes:

Fixes #4050

Special notes for your reviewer:

Demo：https://h3ld32xlpo.feishu.cn/wiki/Rj5mwS3TCigHY4kMKzhcqTggnlg

Test Steps：

1. create KinD Clusters (notes that member1 cluster has three nodes)

hack/create-cluster.sh karmada-host ~/.kube/karmada-host.config
hack/create-cluster.sh member2 ~/.kube/members.config
hack/create-cluster.sh member3 ~/.kube/members.config

sed -i'' -e "/control-plane/p; s/control-plane/worker/" artifacts/kindClusterConfig/general-config.yaml
sed -i'' -e "/control-plane/p; s/control-plane/worker/" artifacts/kindClusterConfig/general-config.yaml
hack/create-cluster.sh member1 ~/.kube/members.config

2. install karmada by helm script in local up install karmada by helm #4045

# modify the NEED_CREATE_KIND_CLUSTER=false, and IMAGE_FROM=make
hack/local-up-karmada-helm.sh

3. mock extension resource karmada.io/gpu by the method described in my Demo

then member1 will have 3 nodes, each node have 3 karmada.io/gpu, 9 in total

and member2 will have 1 node, with 5 karmada.io/gpu, 5 in total

4. A perfect way to edit extension resource model in cluster object is like:

$ for cluster in "member1" "member2"; do
  kubectl --context karmada-apiserver patch cluster ${cluster} -n karmada-system --type='json' -p '[
      {"op": "add", "path": "/spec/resourceModels/0/ranges/-", "value": {"name": "karmada.io/gpu", "min": "0", "max": "4"}},
      {"op": "add", "path": "/spec/resourceModels/1/ranges/-", "value": {"name": "karmada.io/gpu", "min": "4", "max": "8"}},
      {"op": "add", "path": "/spec/resourceModels/2/ranges/-", "value": {"name": "karmada.io/gpu", "min": "8", "max": "12"}},
      {"op": "add", "path": "/spec/resourceModels/3/ranges/-", "value": {"name": "karmada.io/gpu", "min": "12", "max": "16"}},
      {"op": "add", "path": "/spec/resourceModels/4/ranges/-", "value": {"name": "karmada.io/gpu", "min": "16", "max": "20"}},
      {"op": "add", "path": "/spec/resourceModels/5/ranges/-", "value": {"name": "karmada.io/gpu", "min": "20", "max": "24"}},
      {"op": "add", "path": "/spec/resourceModels/6/ranges/-", "value": {"name": "karmada.io/gpu", "min": "24", "max": "28"}},
      {"op": "add", "path": "/spec/resourceModels/7/ranges/-", "value": {"name": "karmada.io/gpu", "min": "28", "max": "32"}},
      {"op": "add", "path": "/spec/resourceModels/8/ranges/-", "value": {"name": "karmada.io/gpu", "min": "32", "max": "9223372036854775807"}},
  ]'
done
cluster.cluster.karmada.io/member1 patched
cluster.cluster.karmada.io/member2 patched

you can see cluster.cluster.karmada.io/member1 patched, which means the resource model of karmada.io/gpu applied.

then you will see the resourceSummary of cluster object updated:

in the cluster object of member1:

resourceSummary:
    allocatable:
      cpu: "12"
      ephemeral-storage: 618482556Ki
      hugepages-1Gi: "0"
      hugepages-2Mi: "0"
      karmada.io/gpu: "9"
      memory: 49179180Ki
      pods: "330"
    allocatableModelings:
    - count: 3
      grade: 0
    - count: 0
      grade: 1

in the cluster object of member2：

resourceSummary:
    allocatable:
      cpu: "4"
      ephemeral-storage: 206160852Ki
      hugepages-1Gi: "0"
      hugepages-2Mi: "0"
      karmada.io/gpu: "5"
      memory: 16393060Ki
      pods: "110"
    allocatableModelings:
    - count: 0
      grade: 0
    - count: 1
      grade: 1

5. I deployed a pod requesting 5 karmada.io/gpu, described in my Demo

then it will be assign to member2 cluster, which is just as expected.

though member1 cluster has 9 karmada.io/gpu, none of its nodes satisfy the requirement, so only member2 is able to deploy that pod.

status:
  aggregatedStatus:
  - applied: true
    clusterName: member2
    health: Healthy
    status:
      availableReplicas: 1
      readyReplicas: 1
      replicas: 1
      updatedReplicas: 1

Does this PR introduce a user-facing change?:

`karmada-controller-manager`: Resource models now support any arbitrary resource type and are no longer limited to `cpu`, `memory`, `storage`, and `ephemeral-storage`.

[codecov-commenter]

Codecov Report

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

Comparison is base (5b8a7f7) 52.00% compared to head (e9e8653) 51.99%.

Files	Patch %	Lines
pkg/modeling/modeling.go	75.00%	1 Missing ⚠️

❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #4307      +/-   ##
==========================================
- Coverage   52.00%   51.99%   -0.01%     
==========================================
  Files         242      242              
  Lines       23993    23977      -16     
==========================================
- Hits        12478    12468      -10     
+ Misses      10834    10829       -5     
+ Partials      681      680       -1     

Flag	Coverage Δ
unittests	51.99% <95.45%> (-0.01%)	⬇️

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

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

[chaosi-zju]

I have carefully tested this feature, it is ok.

Is there any further comments? If you have any other suggestions, please let me know~

[XiShanYongYe-Chang]

Ok, thanks~
LGTM

[RainbowMango]

/lgtm

@chaunceyjiang Do you have any further comment?

[chaosi-zju]

Test report updated

[Poor12]

LGTM.
Thank you for enhancing this feature.

[chaunceyjiang]

/lgtm

[RainbowMango]

/approve

I updated the release note by the way.

[karmada-bot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: chaunceyjiang, 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