Yeah, I think Mayank wants us to display free resources directly rather than capacity, request, and limit: "What would be nice is, to see somewhere in the nodes, how much free resources are remaining without doing the math."
On Wed, Jul 13, 2016 at 1:01 AM, 'Filip Grzadkowski' via Containers at Google <[email protected]> wrote: > This data is already available in kubectl describe node (see bolded font > at the bottom): > > $ kubectl describe node kubernetes-minion-group-r0hq > Name: kubernetes-minion-group-r0hq > Labels: > beta.kubernetes.io/arch=amd64,beta.kubernetes.io/instance-type=n1-standard-2,beta.kubernetes.io/os=linux,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-b,kubernetes.io/hostname=kubernetes-minion-group-r0hq > CreationTimestamp: Wed, 06 Jul 2016 11:38:16 +0200 > Phase: > Conditions: > Type Status LastHeartbeatTime LastTransitionTime Reason Message > ---- ------ ----------------- ------------------ ------ ------- > NetworkUnavailable False Mon, 01 Jan 0001 00:00:00 +0000 Wed, 06 Jul > 2016 11:38:55 +0200 RouteCreated RouteController created a route > OutOfDisk False Wed, 13 Jul 2016 09:59:49 +0200 Fri, 08 Jul 2016 > 22:39:55 +0200 KubeletHasSufficientDisk kubelet has sufficient disk space > available > MemoryPressure False Wed, 13 Jul 2016 09:59:49 +0200 Wed, 06 Jul 2016 > 11:38:16 +0200 KubeletHasSufficientMemory kubelet has sufficient memory > available > Ready True Wed, 13 Jul 2016 09:59:49 +0200 Fri, 08 Jul 2016 22:39:55 > +0200 KubeletReady kubelet is posting ready status. WARNING: CPU > hardcapping unsupported > KernelDeadlock False Wed, 13 Jul 2016 09:59:37 +0200 Wed, 06 Jul 2016 > 11:39:00 +0200 KernelHasNoDeadlock kernel has no deadlock > Addresses: 10.128.0.6,104.155.157.50 > Capacity: > memory: 7679820Ki > pods: 110 > alpha.kubernetes.io/nvidia-gpu: 0 > cpu: 2 > System Info: > Machine ID: > System UUID: D9F98F64-7A5D-300A-2B76-0BFADF0196B0 > Boot ID: 5e3da196-09a4-4704-a7ef-740c50356ace > Kernel Version: 3.16.0-4-amd64 > OS Image: Debian GNU/Linux 7 (wheezy) > Container Runtime Version: docker://1.11.2 > Kubelet Version: v0.0.0-master+$Format:%h$ > Kube-Proxy Version: v0.0.0-master+$Format:%h$ > PodCIDR: 10.244.4.0/24 > ExternalID: 6109616175150362585 > Non-terminated Pods: (3 in total) > Namespace Name CPU Requests CPU Limits Memory Requests Memory Limits > --------- ---- ------------ ---------- --------------- ------------- > kube-system fluentd-cloud-logging-kubernetes-minion-group-r0hq 100m (5%) 0 > (0%) 200Mi (2%) 200Mi (2%) > kube-system kube-proxy-kubernetes-minion-group-r0hq 100m (5%) 0 (0%) 0 > (0%) 0 (0%) > kube-system node-problem-detector-v0.1-5mf5i 20m (1%) 200m (10%) 20Mi > (0%) 100Mi (1%) > *Allocated resources:* > * (Total limits may be over 100%, i.e., overcommitted. More info: > http://releases.k8s.io/HEAD/docs/user-guide/compute-resources.md > <http://releases.k8s.io/HEAD/docs/user-guide/compute-resources.md>)* > * CPU Requests CPU Limits Memory Requests Memory Limits* > * ------------ ---------- --------------- -------------* > * 220m (11%) 200m (10%) 220Mi (2%) 300Mi (4%)* > No events. > > > -- > Filip > > On Wed, Jul 13, 2016 at 9:18 AM, 'David Oppenheimer' via Containers at > Google <[email protected]> wrote: > >> >> >> On Wed, Jul 13, 2016 at 12:05 AM, Mayank <[email protected]> wrote: >> >>> Thanks David. I guess my question was not entirely clear. What you >>> mention here makes complete sense. What would be nice is, to see somewhere >>> in the nodes, how much free resources are remaining without doing the math. >>> That way we could also alarm if the node is reaching its capacity. Is there >>> an issue filed for this or i can goahead and file this . >>> >> >> I don't think there's an issue; feel free to file one. It's a little >> tricky to describe it properly because there are many definitions of free. >> The one I used in the previous email is "free based on request." There's >> also "free based on limit" (which can be negative due to overcommit) and >> "free based on usage" (which we will be able to show once the metrics API >> is plumbed through the API server). But probably the first one is what >> people are most interested in, since that's the one that determines how >> much more request you can schedule onto a node. >> >> We also could integrate it with "kubectl top >> <https://github.com/kubernetes/kubernetes/issues/11382>" though that >> seems like maybe too much feature creep. >> >> >>> >>> >>> >>> On Monday, July 11, 2016 at 1:06:11 PM UTC-7, David Oppenheimer wrote: >>>> >>>> The node capacity is the physical size of the node, and never changes. >>>> I think you're thinking of the amount of free resources on the node, which >>>> does change when you deploy pods to the node. To find the free resources, >>>> subtract "Allocated resources" from "Capacity" (in "kubectl describe >>>> node"). >>>> >>>> >>>> >>>> On Mon, Jul 11, 2016 at 9:41 AM, Mayank <[email protected]> wrote: >>>> >>>>> I have kubernetes cluster deployed on bare metal. When I deploy pods >>>>> or use deployments with resource limits I don't see the resource being >>>>> subtracted from there overall node capacity . Is there something specific >>>>> I >>>>> need to on the nose configuration to enable this? >>>>> >>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "Containers at Google" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to [email protected]. >>>>> To post to this group, send email to [email protected]. >>>>> Visit this group at https://groups.google.com/group/google-containers. >>>>> For more options, visit https://groups.google.com/d/optout. >>>>> >>>> >>>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Containers at Google" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> To post to this group, send email to [email protected]. >>> Visit this group at https://groups.google.com/group/google-containers. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Containers at Google" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To post to this group, send email to [email protected]. >> Visit this group at https://groups.google.com/group/google-containers. >> For more options, visit https://groups.google.com/d/optout. >> > > -- > You received this message because you are subscribed to the Google Groups > "Containers at Google" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at https://groups.google.com/group/google-containers. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Containers at Google" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/google-containers. For more options, visit https://groups.google.com/d/optout.
