Add a currentPodRequests field to NodeStatus

[ahakanbaba]

Is this a request for help? (If yes, you should use our troubleshooting guide and community support channels, see http://kubernetes.io/docs/troubleshooting/.):

What keywords did you search in Kubernetes issues before filing this one? (If you have found any duplicates, you should instead reply there.):

Search for these keywords did not find anything
is:issue is:open node status resources requests current

---

Is this a BUG REPORT or FEATURE REQUEST? (choose one):

FEATURE REQUEST

Hi all,
we propose to add a new field to the NodeStatus .
The name could be currentPodRequests or requestedResources or allocatedResources .
We are open to other name suggestions.

As the desired semantics, we propose this field to contain the sum of requested resources of all the currently running pods in that node.

The same computation is done every time one executes kubectl describe node.
The resources table is computed every time from scratch.
For example

 Namespace          Name                        CPU Requests    CPU Limits  Memory Requests Memory Limits
  ---------         ----                        ------------    ----------  --------------- -------------
  default           k8s-master-127.0.0.1                0 (0%)      0 (0%)      0 (0%)      0 (0%)
  default           k8s-proxy-127.0.0.1             0 (0%)      0 (0%)      0 (0%)      0 (0%)
  hello-world-hbaba-build   hello-world-hbaba-989929512-6jiaf       800m (20%)  20 (500%)   100Mi (2%)  100Mi (2%)
  hello-world-hbaba-build   hello-world-hbaba-989929512-8hq9v       800m (20%)  20 (500%)   100Mi (2%)  100Mi (2%)
  hello-world-hbaba-build   hello-world-hbaba-989929512-jjd5n       800m (20%)  20 (500%)   100Mi (2%)  100Mi (2%)
  hello-world-hbaba-build   hello-world-hbaba-989929512-n00t2       800m (20%)  20 (500%)   100Mi (2%)  100Mi (2%)
  kube-system           kube-dns-v10-z4ics              310m (7%)   310m (7%)   170Mi (4%)  170Mi (4%)
Allocated resources:
  (Total limits may be over 100%, i.e., overcommitted. More info: http://releases.k8s.io/HEAD/docs/user-guide/compute-resources.md)
  CPU Requests  CPU Limits  Memory Requests Memory Limits
  ------------  ----------  --------------- -------------
  3510m (87%)   80310m (2007%)  570Mi (14%) 570Mi (14%)

The code for that table is in kubernetes/pkg/kubectl/describe.go file in describeNodeResource function. It iterates over a collection that is accessed like this :
nodeNonTerminatedPodsList, err := d.Core().Pods(namespace).List(api.ListOptions{FieldSelector: fieldSelector})

From the above example, the proposed field would look like this

"status": {
      ......................
                "currentPodRequests": {
                    "cpu": "3510m",
                    "memory": "570Mi",
                },
...................
}

Our use case for this field is the following:
We would like to understand the "utilization" of the nodes and we would like to understand how much resources have been allocated to running pods and how much is left.
We are interested in this "currentPodRequests" information at the node level as well as at the global cluster level.
We thought a new field in the NodeStatus would be suitable to contain that information .

We have created this issue to get any reactions to this suggestion. Has there been any similar discussions before? Any other issues or pr's anyone can point us. What is the reaction of the community to such a change? Any suggestions for implementation? Any pitfalls to avoid ?

Another alternative is to compute this information on demand from kube-state-metrics agent. This is the similar approach to the kubectl describe nodes implementation.

If this issue and the proposal does not get a favorable reaction, we want to add this computation to kube-state-metrics.

Thanks for all the responses and the time spent in advance.

Kubernetes version (use kubectl version):

Environment:

• Cloud provider or hardware configuration:
• OS (e.g. from /etc/os-release):
• Kernel (e.g. uname -a):
• Install tools:
• Others:

What happened:

What you expected to happen:

How to reproduce it (as minimally and precisely as possible):

Anything else do we need to know:

[ahakanbaba]

@ghodss

[ghodss]

@dchen1107 any thoughts?

[fejta-bot]

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

Prevent issues from auto-closing with an /lifecycle frozen comment.

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

[fejta-bot]

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
/remove-lifecycle stale

[fejta-bot]

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