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.
That's not what you're saying though. You're also putting requests/limits for CPU and memory in the same class, which they're not.
Lack of CPU will never cause a pod to be killed. Evicted, yes. Killed, no.
Lack of memory can cause a pod to be OOM killed. That's an entirely different failure mode.
Eviction should always be expected by your pods. They should be able to handle eviction gracefully. On the other hand, there is nothing you can do to handle an OOM kill gracefully.
Comments
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...
OOM means "Out Of Memory". The post is about CPU.
I am aware of it, are you aware that Kubernetes assigned Burstable Qos if you don't defined CPU requests and limits?
What I'm trying to say that while try to avoid one pitfall you fall right into an other - in short there are good reasons to use cpu limits.
That's not what you're saying though. You're also putting requests/limits for CPU and memory in the same class, which they're not.
Lack of CPU will never cause a pod to be killed. Evicted, yes. Killed, no.
Lack of memory can cause a pod to be OOM killed. That's an entirely different failure mode.
Eviction should always be expected by your pods. They should be able to handle eviction gracefully. On the other hand, there is nothing you can do to handle an OOM kill gracefully.