One situation might be that you roughly know how much memory your process should be consuming and kill it if it's overconsuming. Something akin to but more dynamic than memory limits.
That's probably something you would want to do as soon as the process is outside its limits, without waiting for a OOM situation.
Right, but you may not catch it before the OOM situation arises I guess?
That could end up with significant false-positives when updating the thing without updating the estimated memory usage (especially if slow bounded fragmentation over a long period of time applies). You might also have some expected ratio of memory usage (e.g. process B uses 3x the memory of process A), but want to allow the absolute usage to grow as more data is processed.
Having the wrong limits will cause the wrong thing to die, regardless of whether they kick in during OOM or orchestration. Better to find out during your planned rollout window if you ask me.
I always used `ulimit -v` and `ulimit -H -v` for this purpose. Maybe this is more fine grained?