k3os rootfs overlay update and unintended k3s version drift

Rootfs Overlay Update and k3s Version Alignment

The goal is to keep a specific k3s major version stable across OS upgrades. The update.strategy setting defaults to a best‑effort alignment that does not explicitly pin the k3s binary, so an OS refresh can pull in a newer k3s release without notice. This drift can leave a node running an incompatible k3s binary after a rootfs overlay commit, potentially breaking cluster operations.

Key uncertainty: the current k3os configuration does not expose a standard way to bind a particular k3s semver to the update cycle. When external registries are used, the update pipeline does not validate that the fetched k3s image matches the declared version.

Specific questions to clarify this behavior:

• Is there a documented method to pin a k3s major version in /etc/k3os/config.toml that is respected during rootfs overlay updates?
• Does the update.strategy setting support an explicit k3s semver constraint, and if so, how is it expressed?
• When pulling k3s images from a custom registry, what mechanisms exist to automatically verify image compatibility with the OS version?