<p dir="auto"><strong>Is this a request for help?</strong> (If yes, you should use our troubleshooting guide and community support channels, see <a href="http://kubernetes.io/docs/troubleshooting/" rel="nofollow">http://kubernetes.io/docs/troubleshooting/</a>.):</p>
<p dir="auto"><strong>What keywords did you search in Kubernetes issues before filing this one?</strong> (If you have found any duplicates, you should instead reply there.):</p>
<p dir="auto">Search for these keywords did not find anything<br>
is:issue is:open  node status resources requests current</p>
<hr>
<p dir="auto"><strong>Is this a BUG REPORT or FEATURE REQUEST?</strong> (choose one):</p>
<p dir="auto">FEATURE REQUEST</p>
<p dir="auto">Hi all,<br>
we propose to add a new field to the NodeStatus .<br>
The name could be <code class="notranslate">currentPodRequests</code> or <code class="notranslate">requestedResources</code> or <code class="notranslate">allocatedResources</code> .<br>
We are open to other name suggestions.</p>
<p dir="auto">As the desired semantics, we propose this field to contain the sum of requested resources of all the currently running pods in that node.</p>
<p dir="auto">The same computation is done every time one executes <code class="notranslate">kubectl describe node</code>.<br>
The resources table is computed every time from scratch.<br>
For example</p>
<div class="snippet-clipboard-content notranslate position-relative overflow-auto" data-snippet-clipboard-copy-content=" 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%)"><pre class="notranslate"><code class="notranslate"> 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%)
</code></pre></div>
<p dir="auto">The code for that table is in <code class="notranslate">kubernetes/pkg/kubectl/describe.go</code> file in <code class="notranslate">describeNodeResource</code> function. It iterates over a collection that is accessed like this :<br>
<code class="notranslate">nodeNonTerminatedPodsList, err := d.Core().Pods(namespace).List(api.ListOptions{FieldSelector: fieldSelector})</code></p>
<p dir="auto">From the above example, the proposed field would look like this</p>
<div class="snippet-clipboard-content notranslate position-relative overflow-auto" data-snippet-clipboard-copy-content="&quot;status&quot;: {
      ......................
                &quot;currentPodRequests&quot;: {
                    &quot;cpu&quot;: &quot;3510m&quot;,
                    &quot;memory&quot;: &quot;570Mi&quot;,
                },
...................
}"><pre class="notranslate"><code class="notranslate">"status": {
      ......................
                "currentPodRequests": {
                    "cpu": "3510m",
                    "memory": "570Mi",
                },
...................
}
</code></pre></div>
<p dir="auto">Our use case for this field is the following:<br>
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.<br>
We are interested in this "currentPodRequests" information at the node level as well as at the global cluster level.<br>
We thought a new field in the NodeStatus would be suitable to contain that information .</p>
<p dir="auto">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 ?</p>
<p dir="auto">Another alternative is to compute this information on demand from kube-state-metrics agent. This is the similar approach to the <code class="notranslate">kubectl describe nodes</code> implementation.</p>
<p dir="auto">If this issue and the proposal does not get a favorable reaction, we want to add this computation to kube-state-metrics.</p>
<p dir="auto">Thanks for all the responses and the time spent in advance.</p>

<p dir="auto"><strong>Kubernetes version</strong> (use <code class="notranslate">kubectl version</code>):</p>
<p dir="auto"><strong>Environment</strong>:</p>
<ul dir="auto">
<li><strong>Cloud provider or hardware configuration</strong>:</li>
<li><strong>OS</strong> (e.g. from /etc/os-release):</li>
<li><strong>Kernel</strong> (e.g. <code class="notranslate">uname -a</code>):</li>
<li><strong>Install tools</strong>:</li>
<li><strong>Others</strong>:</li>
</ul>
<p dir="auto"><strong>What happened</strong>:</p>
<p dir="auto"><strong>What you expected to happen</strong>:</p>
<p dir="auto"><strong>How to reproduce it</strong> (as minimally and precisely as possible):</p>
<p dir="auto"><strong>Anything else do we need to know</strong>:</p>
<p dir="auto">Proposal <a class="issue-link js-issue-link" data-error-text="Failed to load title" data-id="116067975" data-permission-text="Title is private" data-url="https://github.com/kubernetes/kubernetes/issues/17048" data-hovercard-type="pull_request" data-hovercard-url="/kubernetes/kubernetes/pull/17048/hovercard" href="https://github.com/kubernetes/kubernetes/pull/17048">#17048</a> introduces client/server container runtime into kubelet, it supposes container's networking is processed by kubelet network plugins.</p>
<p dir="auto">As suggested by <a class="user-mention notranslate" data-hovercard-type="user" data-hovercard-url="/users/thockin/hovercard" data-octo-click="hovercard-link-click" data-octo-dimensions="link_type:self" href="https://github.com/thockin">@thockin</a>, we should have more discussions about the role of network plugins in all of this. <a class="user-mention notranslate" data-hovercard-type="user" data-hovercard-url="/users/thockin/hovercard" data-octo-click="hovercard-link-click" data-octo-dimensions="link_type:self" href="https://github.com/thockin">@thockin</a> provides two options <a href="https://github.com/kubernetes/kubernetes/pull/17048#discussion_r70025255" data-hovercard-type="pull_request" data-hovercard-url="/kubernetes/kubernetes/pull/17048/hovercard">here</a>:</p>
<ul dir="auto">
<li>Option 1) we expect all RemoteRuntimes to NOT set up networking at all and let us do it. This means even more esoteric runtimes have to defer to us.</li>
<li>Option 2) we expect all RemoteRuntimes to handle networking, in which case the very notion of a network plugin should be removed from the RuntimeManager, and the API may have to grow some network functions.</li>
</ul>
<p dir="auto"><strong>Concerns on Option 1)</strong>:</p>
<ul dir="auto">
<li>Is kubelet network plugin general enough for all runtimes?</li>
<li>All current network plugins suppose containers are netns-based, while it is not true for hypervisors, e.g. HyperContainer. How can do deal with those hypervisor-based runtimes?</li>
</ul>
<p dir="auto"><strong>Concerns on Option 2)</strong>:</p>
<ul dir="auto">
<li>What changes should be made toward the runtime API?</li>
<li>How RemoteRuntimes cooperate with kubelet network plugins?</li>
<li>Will this impact the functionality of kube-proxy?</li>
</ul>
<p dir="auto">CC <a class="user-mention notranslate" data-hovercard-type="user" data-hovercard-url="/users/thockin/hovercard" data-octo-click="hovercard-link-click" data-octo-dimensions="link_type:self" href="https://github.com/thockin">@thockin</a> <a class="user-mention notranslate" data-hovercard-type="user" data-hovercard-url="/users/freehan/hovercard" data-octo-click="hovercard-link-click" data-octo-dimensions="link_type:self" href="https://github.com/freehan">@freehan</a> <a class="user-mention notranslate" data-hovercard-type="user" data-hovercard-url="/users/dchen1107/hovercard" data-octo-click="hovercard-link-click" data-octo-dimensions="link_type:self" href="https://github.com/dchen1107">@dchen1107</a> @kubernetes/sig-node @kubernetes/sig-network</p>