ok, so on the subject of milliunits: https://github.com/DirectXMan12/k8s-prometheus-adapter/blob/master/docs/walkthrough.md#quantity-values or https://github.com/kubernetes-incubator/custom-metrics-apiserver/blob/master/docs/getting-started.md#quantities explains.

on the subject of what the values actually mean:

• cores are a meaurement of CPU time over time (which sounds weird, but it's not actually). Normal CPU usage from the OS is measured in cumulative CPU time used. As your process runs actively, it accumulates CPU time used. When it's not running, or waiting on something else, it doesn't use CPU time. We take the rate of change of that cumulative usage, and call it "cores", because 1 second of CPU usage used over 1 second of real time means that the CPU dedicated an entire core of the CPU to your process for that 1 second interval.

• memory is the sum of the memory usage for the containers in your pod, for pods. For nodes, I believe it's the memory usage as reported by the system-wide node cgroup. So it may include stuff that's not in a pod, IIRC. We just report the information given to us by cadvisor on the node.

@DirectXMan12 thanks for the explanation, that makes more sense now. However, I would be happy if the documentation for metrics server could contain a description of the units.

I'd be happy to accept a PR to update the docs :-).

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

@fejta-bot: Closing this issue.

I'd be happy to accept a PR to update the docs :-).

@DirectXMan12 , I would like to update the docs, I looked in this repo and also in https://github.com/DirectXMan12/k8s-prometheus-adapter/tree/master/docs but I'm not sure if that is the correct place.

Since this thread appears in search results, the docs seem to be updated at:
https://kubernetes.io/docs/tasks/configure-pod-container/assign-cpu-resource/#cpu-units

I can understand the concept of units, requests, limits and actuals, but have a hard time to reconcile the 'kubectl top' output with that of "traditional linux commands", e.g., uptime (load everages of past 1, 5, and 15 minutes), free (memory used, free, shared, buff/cache, available), top ('uptime' + 'free -k', then VIRT/RES/SHR memory and %CPU/%MEM on processes).

One question on the kubectl top commands is for what time period it is reporting? When samples are taken and what samples are rolled up for the output? On the other hand, Linux commands always report the state at the time the command is executed, and they include non-kubernetes processes.

The understanding would have impact on managing the resource utilization and the stability of kubernetes. We have random node crashes, suspecting resource crunch, but the utilization numbers are usually low. Kubernetes require us to turn off swapping, which can be a contributing factor because no swapping means no wiggle room in memory overruns, and wasted inactive contents occupying memory.

Hey @wu105,
kubectl top was not designed to be standalone tool to debug resource usage or be replacement to traditional linux command.
It's a additional tool for core metrics pipeline.

Main purpose of metrics pipeline is delivering metrics for autoscaling purposes. Values exposed are curated to autoscaling and OOM detection. Building autoscaling pipeline that can scale to thousands of nodes has different requirements than collecting accurate resource usage that you talk about.

Please take a look at new FAQ section for metrics server. https://github.com/kubernetes-sigs/metrics-server
I would be happy to answer any additional questions, but please create a separate issue for it. Writing on old issues makes it harder for other people to discover this thread.

I would encourage you to look into monitoring systems like Prometheus that are closer to what your describing.

Submitted #447