node-installer: remove resource limits

[Freax13]

There's no strong reason for having resource limits on the node-installer and given the unpredictable nature of the kernel's resource accounting, we should remove the resource limits so that we don't run into unexpected OOMs.

Fixes f5da52d
Cc @blenessy

[burgerdev]

I think we should still set a request based on the average case, but removing the limit to accommodate the worst case sgtm.

[katexochen]

On Kubernetes, the best practice is to set memory limit=request.

https://home.robusta.dev/blog/kubernetes-memory-limit

cc @3u13r

[3u13r]

On Kubernetes, the best practice is to set memory limit=request.

https://home.robusta.dev/blog/kubernetes-memory-limit

Ah, so I remembered correctly. I was just not sure to bring it up. Ideally the node-installer is more akin to a (daemon set) job than a application deployment which actually does something with the requested memory, right?
The question is, can we have a feasible limit if the needed memory scales with the amount of memory on the host?
Alternatively, we can add a somewhat high limit and then explain the failure in the docs and how the user can increase it?

[burgerdev]

On Kubernetes, the best practice is to set memory limit=request.

https://home.robusta.dev/blog/kubernetes-memory-limit

cc @3u13r

This may be true for apps, but is not for essential system components. We don't want to compete with normal pods for resources.

[katexochen]

This may be true for apps, but is not for essential system components. We don't want to compete with normal pods for resources.

I'd say that this is a rather subjective measurement of what is "essential". There could be other important applications running in the same cluster. The concept of contrast is a "next to", so we shouldn't think we're the most critical component.

[burgerdev]

The question is, can we have a feasible limit if the needed memory scales with the amount of memory on the host? Alternatively, we can add a somewhat high limit and then explain the failure in the docs and how the user can increase it?

The problem is that we need memory in a single burst and don't have much influence over how it's accounted. Setting a request=limit=1G is a little extreme and I'd say a small request with a large limit may be fair, too, but don't quite see what the limit would buy us.

[burgerdev]

Funny thing: the linked blog post even has a section on our issue, I think (Unintuitive page-cache behaviour can lead to unecessary OOMs).

[katexochen]

Okay, just dropping some of the links here again for quicker access, fine to merge as is.

• kubelet counts active page cache against memory.available (maybe it shouldn't?) kubernetes/kubernetes#43916
• https://kubernetes.io/blog/2021/11/26/qos-memory-resources/

[katexochen]

/backport

[edgelessci]

Backport failed for release/v1.1, because it was unable to cherry-pick the commit(s).

Please cherry-pick the changes locally and resolve any conflicts.

git fetch origin release/v1.1
git worktree add -d .worktree/backport-948-to-release/v1.1 origin/release/v1.1
cd .worktree/backport-948-to-release/v1.1
git switch --create backport-948-to-release/v1.1
git cherry-pick -x 7f50e0cc566e630bc30775e44b0a42c31b924360