Allow splitting k0s into embedded binaries and a stripped k0s executable

Open twz123 opened this issue 1 month ago • 1 comments

Is your feature request related to a problem? Please describe.

The k0s executables distributed via the GitHub Releases page include all their embedded binaries. These binaries are extracted by k0s at runtime. Over the years, there have been several requests for a way to extract these binaries without actually starting k0s. This is useful when building filesystem images or overlays for downstream distribution. It may also be of interest to Kairos or other immutable/host-image systems.

Currently, there is no practical (let alone supported) way to derive these components from an official release artifact.

Describe the solution you would like

Introduce a k0s payload split command that disassembles the current k0s executable its constituents:

Extract all embedded binaries into a user-specified directory.
Optionally write a stripped k0s executable with the embedded payload removed.

This is a proposal for the help text:

$ k0s payload split --help
Splits off the embedded binaries and writes them to the given directory.

Usage:
      k0s payload split [output-dir]

Flags:
      --stripped-executable   Path to write the stripped k0s executable to

Producing a filesystem overlay could look like this:

k0s payload split root/usr/libexec/k0s \
  --stripped-executable root/usr/bin/k0s

Resulting layout:

root/
  usr/
    bin/
      k0s
    libexec/
      k0s/
        kube-apiserver
        kube-controller-manager
        ...

Describe alternatives you've considered

Publish all artifacts as part of the release pipeline. This is a viable alternative. However, there are already a lot of release artifacts. We would need to produce two more per target triple: the stripped k0s executable and a tar file containing the embedded binaries. If folks start asking for additional signatures and hashes for those files, more artifacts will need to be added. This is getting out of hand.

Additional context

Introducing a top-level payload subcommand creates space for additional functionality in the future, such as listing and inspecting or even modifying the embedded payload (see #6731).