Applying resource limit after pod startsup

[bal...@gmail.com]

Hi all

We have a situation where our pods need a load of cpu on startup only and it seems that the limits for CPU that we have specified in our deployment is throttling the pod on startup and causing it to take over 2 mins to start. If we removed the limits configured in our deployment then start up is in seconds.

e.g this

resources:
limits:
cpu: 600m
memory: 768Mi
requests:
cpu: 600m
memory: 768Mi

is replace by this

resources:
limits:
cpu: 600m
memory: 768Mi
requests:
memory: 768Mi

Means startup in under 6 seconds.

Ideally we would like to be able to apply some sort of cpu limits after the pod has started. Does anyone know if this can be achieved?

Thanks in advance

[Guang Ya Liu]

You can use `kubectl edit <podname>` to update, but this will cause the pod restart.

--
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+unsubscribe@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.

[Matthias Rampke]

Philosophically, the problem is what Kubernetes could do with the reclaimed CPU. The pod could restart at any time, so it can't really promise this CPU time to a different pod. It can let others use this on a best effort basis, but that's already the case when you make a request and don't use it fully. The limits only bound the actual usage, so that the pod could not use more than it has requested (in your case, since request == limit)

From that angle, I would set the CPU limit such that application startup time is acceptable, up to unlimited. The only concern is that during this time, other pods on the same node(s) could suffer. Does that happen for you? If it doesn't cause issues for you, there is nothing wrong with going without a limit.

Also keep in mind that CPU time is handed out every 100ms, so an application that sometimes tries to use all cores (such as the JVM during GC, unless tuned otherwise) will eat up all shares for a "1 core" allocation very quickly and then gets stalled for a long time. We turned off limits on all latency-sensitive applications because of this, and monitor actual usage & adjust requests instead.

/MR 

To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-use...@googlegroups.com.
To post to this group, send email to kubernet...@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-use...@googlegroups.com.
To post to this group, send email to kubernet...@googlegroups.com.

[Brent Newson]

thanks for the explanation, very much appreciated!

To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-users+unsubscribe@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+unsubscribe@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 a topic in the Google Groups "Kubernetes user discussion and Q&A" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/kubernetes-users/zNfUR2wx3Ro/unsubscribe.
To unsubscribe from this group and all its topics, send an email to kubernetes-users+unsubscribe@googlegroups.com.
To post to this group, send email to kubernetes-users@googlegroups.com.