As davidopp@ mentioned a pod is the unit of scheduling. So to find a
suitable node for a pod, the scheduler has to identify a node that sum(all
container requests) available.

It is also used by the node to enforce overall resource usage across all
containers. Not all memory is reclaimed when a container dies or restarts
and so we need an isolation sandbox that spans across all the containers.

It's not a "concept", but more of an implementation detail. Maybe we can
clarify that more explicitly until we introduce it as a concept in the
future?

On Fri, May 5, 2017 at 12:35 AM, 'David Oppenheimer' via Kubernetes user
discussion and Q&A <kubernetes-users@googlegroups.com> wrote:

>
>
> On Wed, May 3, 2017 at 12:10 PM, 'Ahmet Alp Balkan' via Kubernetes user
> discussion and Q&A <kubernetes-users@googlegroups.com> wrote:
>
>> I am afraid it still does not make sense to me.
>>
>> Why is there even a concept of "Pod-level request/limit" if it is not
>> used anywhere?
>>
>
> It is used by the scheduler. Pod is the atomic unit of scheduling.
>

>
>> As a user, this is confusing me. As far as I can tell, I can configure
>> limits on the Container and if I go beyond that my *Pod* will be killed
>> altogether. This part is clear. However I can't tell what a Pod-level
>> request/limit (just a sum of things which I can't configure directly) does
>> on my cluster today?
>>
>> On Wed, May 3, 2017 at 11:30 AM, 'David Oppenheimer' via Kubernetes user
>> discussion and Q&A <kubernetes-users@googlegroups.com> wrote:
>>
>>>
>>>
>>> On Wed, May 3, 2017 at 10:47 AM, 'Ahmet Alp Balkan' via Kubernetes user
>>> discussion and Q&A <kubernetes-users@googlegroups.com> wrote:
>>>
>>>> Hello, I am trying to understand the Resource Limits/Requests for Pods
>>>> and Containers
>>>> <https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/>
>>>>  document.
>>>> In multiple places, the document implies that users can specify
>>>> ResourceRequirements *at pod-level**. *(I don't mean
>>>> pod.spec.containers.resources.) Most relevantly the doc says:
>>>>
>>>> A Pod resource request/limit for a particular resource type* is the
>>>>> sum *of the resource requests/limits of that type for each Container
>>>>> in the Pod.
>>>>
>>>>
>>> Request and limit are specified only at the per-container level. The
>>> system computes pod-level request and limit by adding up the request and
>>> limit of the containers that are inside the pod. But you can't specify it
>>> at the pod level yourself.
>>>
>>> Does that make sense?
>>>
>>>
>>>
>>>>
>>>> However I can’t find any examples or any fields on the API (kubectl
>>>> explain pod.spec) to specify resource requirements on the pod level.
>>>>
>>>> Any ideas if this is possible at all? This particular document is
>>>> particularly gives the strong impression that this feature exists today. I
>>>> opened this docs issue
>>>> <https://github.com/kubernetes/kubernetes.github.io/issues/3608> to
>>>> track this.
>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "Kubernetes user discussion and Q&A" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>> an email to kubernetes-users+unsubscr...@googlegroups.com.
>>>> To post to this group, send email to kubernetes-users@googlegroups.com.
>>>> Visit this group at https://groups.google.com/group/kubernetes-users.
>>>> For more options, visit https://groups.google.com/d/optout.
>>>>
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Kubernetes user discussion and Q&A" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to kubernetes-users+unsubscr...@googlegroups.com.
>>> To post to this group, send email to kubernetes-users@googlegroups.com.
>>> Visit this group at https://groups.google.com/group/kubernetes-users.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Kubernetes user discussion and Q&A" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to kubernetes-users+unsubscr...@googlegroups.com.
>> To post to this group, send email to kubernetes-users@googlegroups.com.
>> Visit this group at https://groups.google.com/group/kubernetes-users.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Kubernetes user discussion and Q&A" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to kubernetes-users+unsubscr...@googlegroups.com.
> To post to this group, send email to kubernetes-users@googlegroups.com.
> Visit this group at https://groups.google.com/group/kubernetes-users.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Kubernetes user discussion and Q&A" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to kubernetes-users+unsubscr...@googlegroups.com.
To post to this group, send email to kubernetes-users@googlegroups.com.
Visit this group at https://groups.google.com/group/kubernetes-users.
For more options, visit https://groups.google.com/d/optout.
  • [kubernetes... 'Ahmet Alp Balkan' via Kubernetes user discussion and Q&A
    • Re: [k... 'David Oppenheimer' via Kubernetes user discussion and Q&A
      • Re... 'Ahmet Alp Balkan' via Kubernetes user discussion and Q&A
        • ... 'David Oppenheimer' via Kubernetes user discussion and Q&A
          • ... 'Vishnu Kannan' via Kubernetes user discussion and Q&A
    • [kuber... lilanqing

Reply via email to