Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[question] why function EstimateNode use node.Status.Allocatable by default #2166

Open
qwjhq opened this issue Aug 12, 2024 · 2 comments
Open
Assignees
Labels
area/koord-scheduler kind/question Support request or question relating to Koordinator
Milestone

Comments

@qwjhq
Copy link

qwjhq commented Aug 12, 2024

default_estimator.go function EstimateNode
if node node.Annotations node.koordinator.sh/raw-allocatable not set
EstimateNode() will use node.Status.Allocatable by default why not node.Status.Capacity

node memory useage get from machine /proc/meminfo (i.MemTotal - i.MemAvailable) * 1024 is true, but filterNodeUsage memory percent is node_usage / node_Allocatable .
if use node_Allocatable is right why node memory usage use (i.MemTotal - i.MemAvailable) , not all pod in node use total, because there will some memory can not be use.

What you expected to happen:
EstimateNode() use node.Status.Capacity default or node memory useage use pod in node use real total

Environment:

  • Koordinator version: - v1.4.0
  • Kubernetes version (use kubectl version): v1.20.10
  • docker/containerd version: docker 1.20
  • OS (e.g: cat /etc/os-release): Ubuntu 22.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:

get node usage message from code
I0812 17:08:44.083434   10160 tsdb_storage.go:147] append labels {__name__="node_memory_usage"}, ts 1723453724083, value 5.702279168e+09
I0812 17:08:44.083462   10160 tsdb_storage.go:147] append labels {__name__="node_cpu_usage"}, ts 1723453724083, value 2.206460272868489
I0812 17:08:44.083495   10160 node_resource_collector.go:163] collectNodeResUsed finished, count 2, cpu[2.206460272868489], mem[5.702279168e+09]

node top message
kubectl top  node test-node
NAME                                             CPU(cores)   CPU%   MEMORY(bytes)   MEMORY%   
test-node   808m         23%    1187Mi          24%  


root@ubuntu:~# free 
               total        used        free      shared  buff/cache   available
Mem:         7434284     5380960      593512        3240     1459812     1886340
Swap:              0           0           0

node threshold 
cpu 65% memory 95%

root@ubuntu:~# kubectl get node test-node -oyaml
 allocatable:
    cpu: 3500m
    ephemeral-storage: "301139765777"
    hugepages-1Gi: "0"
    hugepages-2Mi: "0"
    hugepages-32Mi: "0"
    hugepages-64Ki: "0"
    kubernetes.io/batch-cpu: "1277"
    kubernetes.io/batch-memory: "0"
    memory: 4923436Ki
    pods: "43"
  capacity:
    cpu: "4"
    ephemeral-storage: 308519744Ki
    hugepages-1Gi: "0"
    hugepages-2Mi: "0"
    hugepages-32Mi: "0"
    hugepages-64Ki: "0"
    kubernetes.io/batch-cpu: "1277"
    kubernetes.io/batch-memory: "0"
    memory: 7434284Ki
    pods: "43"
@qwjhq qwjhq added the kind/question Support request or question relating to Koordinator label Aug 12, 2024
@saintube
Copy link
Member

@qwjhq Good advice. For the LoadAware scheduling plugin, the node capacity is more suitable to be the denominator than the node allocatable or the raw allocatable since the node usage in the NodeMetric reports the total usage of the machine. For some fine-grained cases, e.g. differentiating the proportion of the system usage and pods usage, perhaps we should add additional fields to describe.
PTAL @ZiMengSheng @hormes @zwzhang0107

@songtao98
Copy link
Contributor

/assign

@songtao98 songtao98 added this to the someday milestone Aug 27, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/koord-scheduler kind/question Support request or question relating to Koordinator
Projects
None yet
Development

No branches or pull requests

3 participants