Upstream cri patch for default RLIMIT_NOFILE

[zmrow]

Bottlerocket carries a patch to cri that sets a default RLIMIT_NOFILE, introduced to help remediate this OOM issue.

This configurable limit seems more generally useful, so we should upstream the patch.

[rverma-dev]

@zmrow we are also facing issues with rlimit on our elasticsearch clusters, and the current openfiles are shown as (-n) 65536. Is there a way to use the increased limit, the clusters are bootstrapped using eksct.

[zmrow]

Thanks for letting us know - we'll take this into consideration when planning and considering if or how we can make this more configurable.

[zmrow]

Upstream issue: https://github.com/containerd/containerd/issues/6063

[zmrow]

PR: https://github.com/containerd/containerd/pull/6064

[tanvp112]

hi @zmrow, I tested with 1.7.2-28782dce, there's one last setting that required to pass elasticsearch boostrap check which is the memlock. Is it possible to have memlock hard limit set to unlimited?

Thanks.

[stmcginnis]

@zmrow do you know what happened with this?

[webern]

We deleted the patch in #2697 because we now set it via the OCI-defaults

[stmcginnis]

I'm wondering about @tanvp112's memlock mention. Maybe that should be its own issue so we can track it there and not muddy things.

Any idea if that is still needed @tanvp112?

[bcressey]

Seems like it's still needed and we should expand the oci-defaults.resource-limits settings for all the limits in any case.

[tanvp112]

@stmcginnis, yes, this setting is very much needed for in-memory (eg. redis, elk... just to name a few) workloads.

[stmcginnis]

I am going to close this since the topic of this issue has been addressed and open a new issue to track expanding the oci-defaults.resource-limits knobs.

Tracking in #2814