undefined | Better HN

0 pointspotoftea1y ago0 comments

I can't comment about about other statement.

But there are serious drawbacks if you don't set requests/limits for mission-critical process, is that they can be killed by kernel to free some resources (if the node reach max resource usage)

When you don't set cpu/memory limit your pod QoS class is burstable, which better then BestEffort, but still get assigned `oom_score_adj` score. IMHO you almost 99% you want `Guaranteed` for critical process.

1. oom_score_adj - https://kubernetes.io/docs/concepts/scheduling-eviction/node...

2. Guaranteed - https://kubernetes.io/docs/tasks/configure-pod-container/qua...

3. QoS - https://kubernetes.io/docs/concepts/workloads/pods/pod-qos/

0 comments

3 comments · 1 top-level

lantry1y ago· 2 in thread

The post recommends setting both request and limit for memory. It's only for CPU that it says to use a request and not a limit. It's my understanding that the kernel only kills processes when it's out of memory. In the docs you linked, there doesn't seem to be an "eviction signal" for CPU.

potofteaOP1y ago

This doens't match what I've read.

IF you don't set limit to cpu & memory, your pod QoS will be burstable and from kernel/cgroup perspective this process can be killed - it's only question of oom_score_adj.

OOMScore from linux - https://www.freedesktop.org/software/systemd/man/latest/syst...

cassianoleal1y ago

OOM means "Out Of Memory". The post is about CPU.

> Everything in this post is about CPU and not memory.

1 more reply

j / k navigate · click thread line to collapse