<p>I've seen <a href="https://cloudplatform.googleblog.com/2018/05/Kubernetes-best-practices-Resource-requests-and-limits.html" rel="nofollow noreferrer">articles recommending</a> that resource requests/limit should be implemented. However, none I've found that discuss on <em>what</em> numbers to fill in.</p>

<p>For example, consider a container use zero CPU while idle, 80% under normal user requests and 200% CPU when hit by some rare requests:</p>

<ul>
<li>If I put the maximum, 2000m as CPU request then a core would sit idle most of the time</li>
<li>On the other hand, if I request 800m and several pods are hitting their CPU limit at the same time the context switch overhead will kicks in</li>
</ul>

<p>There are also cases like</p>

<ul>
<li>Internal tools that sit idle most of the time, then jump to 200% on active use</li>
<li>Apps that have different peak time. For example, a SaaS that people use during working hours and a chatbot that start getting load after people leave work. It'd be nice if they could share the unused capacity.</li>
</ul>

<p>Ideally <a href="https://github.com/kubernetes/autoscaler/tree/master/vertical-pod-autoscaler" rel="nofollow noreferrer">vertical pod autoscaler</a> would probably solve these problems automatically, but it is still in alpha today.</p>

willwill
<p>What I've been doing is to use telegraf to collect resource usage, and use the 95th percentile while the limit is set to 1 CPU and twice the memory request.</p>

<p><img src="https://i.stack.imgur.com/FOFRu.png" alt="Screenshot"></p>

<p>The problem with this method is</p>

<ul>
<li>App that utilize multicores during startup, then under a core throughout their life will take longer to starts. I've observed a 2 minutes Spring startup become 5 minutes</li>
<li>Apps that are rarely used will have less resource reserved, and so have to rely on bursting capacity when it get invoked. This could be a problem if it has a surge in popularity.</li>
</ul>
