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

Answer to the exact question

When the rancher/k3os repository is archived, the OS stops receiving new releases, kernel patches, or security updates. The nodes keep running with the last bundled k3s version, but the underlying OS is frozen. You can still upgrade k3s manually, but the OS itself remains unsupported.

Confirmed facts (based on the archive status and last release notes)

• Repository is archived – no new commits, no new releases.
• The last k3os release bundles a fixed k3s version (e.g., v1.27.x).
• Manual k3s upgrades are possible via the standard curl -sfL https://get.k3s.io | sh - script, but they bypass the OS’s integrity checks.
• There is no official migration target listed in the deprecation notice.

Likely implications for your cluster

Because the OS is frozen, any kernel‑level CVEs discovered after the last release will not be patched automatically. If the cluster is exposed to untrusted networks, this could be a security risk. On the other hand, if the cluster is isolated and you keep k3s up‑to‑date, the risk is mitigated but not eliminated.

Migration options

1. Re‑provision with a supported OS – install a standard distribution (Ubuntu LTS, CentOS Stream, RHEL, SLE Micro, Elemental) and run k3s or RKE2 there. Preserve cluster state by taking an etcd snapshot and restoring it on the new nodes.
2. Manual k3s upgrade on the same node – run the upgrade script, then verify that the kernel and container runtime remain compatible. This keeps the same OS but does not fix kernel CVEs.

Re‑provision steps (simplified)

# 1. Take etcd snapshot on the cluster
etcdctl snapshot save /tmp/etcd-snapshot.db

# 2. Provision new VM with your chosen OS
# 3. Install k3s (or RKE2) on the new node
curl -sfL https://get.k3s.io | sh -

# 4. Restore etcd snapshot on the new node
etcdctl snapshot restore /tmp/etcd-snapshot.db --data-dir /var/lib/rancher/etcd

# 5. Join the node to the cluster
k3s agent --server https://:6443 --token 

Manual upgrade steps (on the same node)

# Verify current k3s version
k3s --version

# Upgrade k3s
curl -sfL https://get.k3s.io | sh -

# Verify that the container runtime and kernel modules are still loaded
systemctl status containerd
lsmod | grep k3s

Interim risk assessment

Continuing to run the last k3os release is acceptable if:

• The cluster is fully isolated from untrusted networks.
• You regularly perform manual k3s upgrades to stay within the supported Kubernetes skew.

However, the OS will remain vulnerable to any kernel‑level CVEs discovered after the last release. If the node can be accessed from the internet or an untrusted internal network, the risk is higher.

What to do next

1. Confirm network exposure – is the cluster reachable from any external network or IP range?

2. Decide on a migration path – if isolation is not guaranteed, plan a reprovision to a supported OS.

3. Backup first – take an etcd snapshot before any changes.

4. Document the plan – record the OS, k3s version, and upgrade schedule.

Missing diagnostic detail

To tailor the recommendation precisely, please let us know whether your cluster is exposed to external networks or is fully isolated.