containerd, docker: consider removing LimitNOFILE specification from service units.

[etungsten]

What I'd like:
To remove LimitNOFILE=infinity from containerd.service, host-containerd.service, and docker.service.

See containerd/containerd#8924 and moby/moby#45534 for details

Remove LimitNOFILE from containerd.service to rely on the systemd v240 implicit default of 1024:524288. On supported platforms with systemd prior to v240, packagers are expected to patch the service with an explicit LimitNOFILE=1024:524288.

When set to infinity (usually as the soft limit) software may experience significantly increased resource usage, resulting in a performance regression or runtime failures that are difficult to troubleshoot.

Any alternatives you've considered:
N/A

[yeazelm]

Looks like we probably should hold off since things may make this problematic: awslabs/amazon-eks-ami#1551. We should track the resolution of this before taking it ourselves.

[bcressey]

In Bottlerocket, the resource limits for pods have been decoupled from the containerd service's limits since #1180 (shortly after 1.0).

That patch hard-coded some lower limits for open files, which created a different set of challenges for pods that needed a higher or lower soft limit. The limits were later made configurable in #2697 via settings.oci-defaults.resource-limits.max-open-files.

Consequently, taking this change shouldn't have the same impact on Bottlerocket nodes. However, I'm still not inclined to pursue this since we don't have any data on what the appropriate limits are for these services on heavily loaded nodes. It may be that containerd needs more than 1024 file descriptors under certain conditions.