"k3os is no longer maintained": what happens to existing nodes after the repository was archived

Deprecated OS, running cluster

The k3os repository's deprecation notice states the project is no longer maintained, and the GitHub repository has been archived. I have nodes running k3os where the entire system configuration lives in /var/lib/rancher/k3os/config.yaml and upgrades were historically handled by remastering the running image through Kubernetes-driven workflows.

The unresolved decision

Because k3os bundles a pinned k3s version, archiving the project means no further Kubernetes updates, kernel updates, or CVE patches arrive through k3os's own channels. The documented upgrade path effectively terminates at the last published release. Meanwhile k3s itself is actively maintained, so the cluster workload is fine — only the OS wrapper underneath it is frozen.

The failure condition I am planning around is not a crash but a support cliff: at some point the bundled k3s version falls outside the supported Kubernetes skew, and any node-level vulnerability stays unpatched indefinitely.

Questions

• Is in-place migration of a k3os node to an alternative immutable OS (for example an Elemental/SLE Micro-based approach) realistic while preserving the existing k3s cluster state, or is a full reprovision the only supported path?
• Does the deprecation notice name an officially recommended migration target, and does that target preserve the declarative single-YAML configuration model?
• Is there any interim risk in continuing to run the last k3os release if the cluster is isolated and the k3s version is manually kept current?