-
Notifications
You must be signed in to change notification settings - Fork 40.4k
Container and pod resource limits #168
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
+1. |
We have cpu and memory in the container manifest: However, AFAICT, we don't do anything with them. Besides, I think we want something more similar to lmctfy's API (request, limit, qos for each resource). Another consideration: We could make it fairly easy to add new resources. Kubelet needs to understand each individual resource's characteristics, for isolation, QoS, overcommitment, etc. OTOH, the scheduler could deal with resources entirely abstractly. It could get resources and their capacities from the machines. Similarly, we'd need to make it possible to request abstract resources in the container/pod manifest. |
What we described internally was that "common" resources like CPU, memory, On Fri, Jul 11, 2014 at 2:04 PM, bgrant0607 notifications@github.com
|
Consider that the resource types and units used for pod/container requests could also be used for describing how to subdivide cluster resources (see #442 ). For example, if team A is limited to using 10GB RAM at the cluster level, then team A can run 10 pods x 1GB RAM; or 2 pods x 5GB per pod; or some combination, etc. |
+1 to all of this. Mesos has a very similar model, with the scheduler/allocator able to work with any custom resource, but the slave/containerizer needs to know enough details to map it to an isolator. This would also be the appropriate separation for requested resource vs. resource limits. |
/cc @johnwilkes @davidopp @rjnagal @smarterclayton @brendandburns @thockin The resource model doc has been created. We should align our API with it. v1beta3 leaves resource requests unchanged, though the I propose that we add an optional |
Clarification: The separation of desired-state fields into a |
I don't think we want pod-level resources yet, or if we do then we accept On Thu, Oct 2, 2014 at 2:56 PM, bgrant0607 notifications@github.com wrote:
|
Fair enough. We can't support pod limits until libcontainer and Docker do, so I'd be fine with omitting that for now. |
FYI: Docker now supports updates to cgroups #15078 |
Factor out data comparator for storage tests.
Allowing memory limit over-commiting may cause unpredicatable process killing by triggering kernel OOM killers. I have run a program which allocate 50GB memory in a pod whose memory limit is 118GB on a node with 64GB. when the program is running for several seconds, it is oom killed and i can get the oom killer log in |
Hard limits for CPU are very important for our video transcoding pods we run on Google Container Engine. We need to have nodes with lots of cores for speed but also don't want a single pod greedily using up all the cores. It would be ideal to set their limit at 3/4 of the total nodes CPU. We can currently do this for scheduling with |
I thought we used shares for "request" and quota for "limit" thereby On Sat, Sep 10, 2016 at 6:05 PM, Montana Flynn notifications@github.com
|
So did I - are you not seeing quota enforced? What docker version are you on?
|
It seems hard limits came with v1.2 based on the changelog. I remember when I first started with kubernetes there was a warning saying that CPU limits were not enforced. Maybe it was that my host OS that didn't support it. Looking at the compute resources documentation it looks like kubernetes does support hard limits by default now.
|
Note that CPU hardlimits can be surprising. All it guarantees is that you Now, in reality the time slice is smaller, but it is still in the tens or On Sun, Sep 11, 2016 at 9:54 PM, Montana Flynn notifications@github.com
|
If it's a hard constraint to not tolerate the blips, then you're likely looking for cpu affinity or cpu-sets. xref: #10570 |
I'm on google cloud's container engine and found the warning I referenced above is still shown while running master and nodes kubernetes version 1.3.5: The warning is displayed with
|
@montanaflynn On Google Container Engine can you switch to |
@vishh where / how could I set |
@montanaflynn Assuming you have only the default node-pool, run |
Thanks! Will container engine be using that image by default in the future? |
Yes. That might happen as early as v1.4 on GKE. |
I think we should move to close this issue, the root topic has been addressed but there are multiple side-threads that are on this issue where I believe they would be better served on other issues. @vishh thoughts? |
I think this can be closed.
…On Wed, Dec 7, 2016 at 3:13 PM Timothy St. Clair ***@***.***> wrote:
I think we should move to close this issue, the root topic has been
addressed but there are multiple side-threads that are on this issue where
I believe they would be better served on other issues.
@vishh <https://github.com/vishh> thoughts?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#168 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AF8dbELMdlH4rE1zioGrUTXpVEu6Piwdks5rFxNLgaJpZM4CFzkL>
.
|
Schedule a Pod as follows: apiVersion: v1 kubectl create -f nginx-kusc00101.yaml |
release v1.4.4 debs and rpms
…alue-default Finalize the interface of the Fixtures struct
Pass 2: k8s GCR vanity URL
Before we implement QoS tiers (#147), we need to support basic resource limits for containers and pods. All resource values should be integers.
For inspiration, see lmctfy:
https://github.com/google/lmctfy/blob/master/include/lmctfy.proto
Arguably we should start with pods first, to at least provide isolation between pods. However, that would require the ability to start Docker containers within cgroups. The support we need for individual containers already exists.
We should allow both minimum and maximum resource values to be provided, as lmctfy does. But let's not reuse lmctfy's limit and max_limit terminology. I like "requested" (amount scheduler will use for placement) and "limit" (hard limit beyond which the pod/container is throttled or killed).
Even without limit enforcement, the scheduler could use resource information for placement decisions.
The text was updated successfully, but these errors were encountered: