Bake K3S

[gcavalcante8808]

Bake K3S as a systemd sysext image.

This PR aims to bake K3S as a systemd sysext and also provide a systemd unit file to manage k3s.

How to use

[ describe what reviewers need to do in order to validate this PR ]

Testing done

[Describe the testing you have done before submitting this PR. Please include both the commands you issued as well as the output you got.]

• Changelog entries added in the respective changelog/ directory (user-facing change, bug fix, security fix, update)
• Inspected CI output for image differences: /boot and /usr size, packages, list files for any missing binaries, kernel modules, config files, kernel modules, etc.

[pothos]

Thanks! I made some suggestions but overall it's nice. If you also want to have it built in the releases of this repo, you can add it to release_build_versions.txt as k3s-v1.27.11+k3s1 (or whatever version we should use - ideally we add some logic to discover the latest version but we haven't done that yet for other extensions as well).

[gcavalcante8808]

@pothos Great! Thanks for the updates on the PR and also thanks to accept!

[kastl-ars]

Sorry for the beginner's question, but why does it install to /usr/local/bin/k3s? Is it intended to be usable with the install script from k3s.io that will create the service files and such?

Or is this by principle, because /usr/bin/ should not be modified by sysexts in Flatcar?

[pothos]

/usr/bin/ is the normal place, it's up to the preference of the deployed software/the deployer, like sbin vs bin. In general one can say that /usr/local/ would be good to keep things separated but I don't think it makes a big difference (And might even be more confusing when two same binaries land on the system). With systemd-dissect --mtree one has a reliable way of seeing sysext contents.