Issue 1:
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:

Issue 2:
Proposal #17048 introduces client/server container runtime into kubelet, it supposes container's networking is processed by kubelet network plugins.

As suggested by @thockin, we should have more discussions about the role of network plugins in all of this. @thockin provides two options here:

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.

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.

Concerns on Option 1):

Is kubelet network plugin general enough for all runtimes?

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?

Concerns on Option 2):

What changes should be made toward the runtime API?

How RemoteRuntimes cooperate with kubelet network plugins?

Will this impact the functionality of kube-proxy?

CC @thockin @freehan @dchen1107 @kubernetes/sig-node @kubernetes/sig-network