3 ms·

There's a great example on why setting limits is a good thing from one of Kelsey Hightower's talks, for some reason your initial comment triggered remembering t

• lobster_johnson 9y ago
  Requests/limits settings also decide what "quality of service" class a pod will use. Setting requests and limits to the same values puts it in "Guaranteed", whereas setting requests and limits to different values gives you "Burstable". The default QoS class is "BestEffort", which makes the pod expendable. (This isn't the best-documented part of Kubernetes.) (Edit: You can see the QoS class of a pod with "kubectl describe pod <name> | grep QoS".) QoS classes are important for scheduling. When Kubernetes needs to evict pods, it will pick burstable and best-effort pods first. Note that setting memory limits can sometimes not work well with apps that use GC. I have had particularly disappointing experiences with Go apps. Go's GC is a bit odd in that it reserves a huge chunk of virtual memory (which is why Go apps, if you look at "vsz" only, often seem to take more RAM than expected), and is not very aggressive about releasing it. I have a Go app that uses only a few megs actual, but because of the GC will allocate half a gig and get OOM-killed by the kernel before the GC is able to collect.
  • xkarga00 9y ago
    You have confused BestEffort with Burstable. Agreed about the docs.
    • lobster_johnson 9y ago
      Gah, of course I did. Thanks, edited.