Adjust systemd service configuration based on image-builder

[s3rj1k]

Description

Syncs systemd service config with values that are used in vanilla image-builder images.

• https://github.com/kubernetes-sigs/image-builder/blob/main/images/capi/ansible/roles/containerd/templates/etc/systemd/system/containerd.service.d/memory-pressure.conf#L8
• https://github.com/kubernetes-sigs/image-builder/blob/main/images/capi/ansible/roles/containerd/templates/etc/systemd/system/containerd.service.d/limit-nofile.conf#L4

Fixes # (issue)

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation update

How Has This Been Tested?

• Manual test
• Auto test added

Manual systemd service test of config validity.

Checklist

• My code follows the style guidelines of this project
• My commit messages are signed-off
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• Any dependent changes have been merged and published in downstream modules
• I have checked my code and corrected any misspellings

[twz123]

Just out of curiosity, have you run into OOM killer issues without the OOM score adjustment? The main difference with the upstream reference you provided is that in upstream these settings only apply to the container runtime, whereas here this change applies to the k0s process itself and all its child processes, including api-server, etcd/kine, and others, not just containerd.

[s3rj1k]

have you run into OOM killer issues without the OOM score adjustment

I did not, but I do not have any kind of load in dev clusters that could actually create that memory load

[s3rj1k]

The main difference with the upstream reference you provided is that in upstream these settings only apply to the container runtime, whereas here this change applies to the k0s process itself and all its child processes, including api-server, etcd/kine, and others, not just containerd.

I've just adjusted LimitNOFILE value to proper infinity, solution to actually do this in they way you are mentioning was already there.

For OOMScore, it makes sense only to put it on systemd unit and we only have one unit.

[twz123]

Can we add a condition around this directive, so it only kicks in if k0s is running the worker components? We could add a comment line with the link to the upstream source, too.

[s3rj1k]

I think you are overengeneering this. If I run k0s as system service I would want it to be not OOMed in any case, not for dev cluster and definitely not for prod cluster.