k3OS RAM-Only Boot: Immutable k3s Nodes From a Single k3os.yaml

Disposable k3s agents that must not drift between runs

Ephemeral CI runners and edge gateways need a node that boots clean, joins a cluster, runs work, and can be discarded without leftover packages or manual SSH fixes. The useful takeaway is that k3OS gives you an immutable, RAM-only k3s node provisioned from a single k3os.yaml, but the project is archived since late 2022 and carries unpatched CVE risk.

Immutable OS, persistent state partition

k3OS boots a minimal kernel + initramfs, loads the root filesystem into RAM, and starts k3s automatically. There is no package manager and no writable root by default. The OS layer is immutable; only /var/lib/rancher/k3s and /oem are persisted on a state partition when you use the disk install mode. Live ISO/PXE mode is fully stateless.

Upgrades are atomic: replace the ISO or image and reboot. Rollback is booting a previous ISO. That separation of OS and state is the engineering decision that makes nodes reproducible.

Single source of truth: k3os.yaml via cloud-init

All cluster configuration is expressed in one k3os.yaml consumed by a stripped-down cloud-init at first boot. It controls token, datastore, network, kubelet args, sysctls and kernel cmdline. Because the file is declarative, it can be stored in git and baked into an ISO for air-gapped use.

Access is console only. k3OS ships with no SSH by default and no package manager. Configuration is inspected or changed with k3os config on the node console as root. The minimal attack surface is intentional, but recovery requires physical or serial console access.

Worked example: RAM-only agent joining an external datastore

Use case: a small edge node that should not run embedded etcd. The server uses an external MySQL/PostgreSQL datastore so agents can stay low RAM.

Create k3os.yaml on the provisioning host. Placeholders must be replaced before embedding in the ISO or PXE config.

# k3os.yaml for agent, RAM-only boot
k3os:
  version: v0.24.4
cluster:
  server: https://<SERVER_IP>:6443
  token: <CLUSTER_TOKEN>
  mode: agent
  datastore:
    endpoint: mysql://<DB_USER>:<DB_PASS>@tcp(<DB_HOST>:3306)/k3s
network:
  interface: eth0
  hostname: <NODE_HOSTNAME>

Where to apply: the file is consumed at first boot by cloud-init. In PXE/live ISO mode the node boots RAM-only and will not persist changes across reboots. In disk install mode, run k3os install from the live environment as root to create the state partition; the OS remains immutable while k3s data persists.

Meaningful risks: the token and DB credentials live in clear text in k3os.yaml. Protect the file at rest and in transit. No SSH means you cannot debug remotely without console. k3s version is pinned to the OS release; upgrading k3s independently breaks OS-k3s integration assumptions.

Trade-off and limitation: archived and frozen

k3OS is archived. No security patches, kernel updates, or k3s version bumps after v0.24.x. Kernel support is frozen around the 5.10/5.15 era; newer NICs, GPUs or ARM SoCs may lack drivers. Cloud-init is a subset; complex multi-network or encrypted disk setups often require custom initramfs hooks. State partition LUKS encryption was experimental and documented as unsupported for production.

Practical check before use: verify the GitHub archive banner for rancher/k3os and the final release notes for v0.24.4-k3s1r0. Audit NVD/GHSA for kernel 5.10/5.15 and containerd 1.6.x vulnerabilities post-2022. Test a live ISO boot in a VM to observe RAM-only behavior, cloud-init flow, and k3s startup logs via console.

Actionable closing

If you need the RAM-only, git-ops provisioning pattern today, evaluate maintained immutable Kubernetes OS alternatives such as Talos Linux, Flatcar, or Bottlerocket. If you keep k3OS for labs or air-gapped demos, isolate nodes, avoid internet exposure, and treat the image as unmaintained.