For anyone that may be searching about installing k3s in MicroOS. I tried to follow the instructions in SDB:K3s cluster deployment on MicroOS, but hit a few snags.
Is it possible that SELinux was added to MicroOS after the instructions were written? Well, they cannot be followed as they are, because of SELinux. (I didn’t expect SELinux, I thought openSUSE used AppArmor.)
The idea is to create a service that will download an install k3s on next boot. The problem is that, when using the SelfInstall image, the service is started right after the installation and configuration (ignition + combustion), and at this time, SELinux is disabled (as reported by sestatus). So the install script fails because it cannot change the SELinux context for the k3s binary. Of course: SELinux is disabled.
After forcing a reboot, SELinux is enabled in Enforcing mode, and then k3s can be installed without error.
But since the k3s installation service failed, it won’t start again because it successfully downloaded the binary. k3s has to be deleted from /usr/local/bin in order to restart the installation successfully.
So the service must not be enabled in the combustion script (comment or delete the line systemctl enable install-rancher-k3s.service).
After rebooting, just enable and start the service with
systemctl enable --now install-rancher-k3s.service
wait for the installation to finish, then enable and start the server (or agent).
In my case, I used the Fuel Ignition website to create both combustion script and ignition configuration (what a great help it was), but it comes to the same thing as the combustion script alone.
I have to say that I had a hard time piecing together how to install and configure MicroOS, but in the end it took me less reading than using Fedora/CentOS CoreOS or bootc. 
I originally wanted to use Cayo from the Universal Blue project, but it’s still in development, so I was going for the bootc approach with Fedora or CentOS. However the process seemed to me more involved than MicroOS.
But what really caught my interest with MicroOS is the transactional updates. I really dig the container images approach from Universal Blue and bootc, but the problem is that updates are container layers, and end up being a lot more heavier than MicroOS updates. (I used Aurora 42 for 3 months, a Fedora Atomic based KDE desktop from Universal Blue.)
Also I want to use the Rancher System Upgrade Controller to manage k3s upgrades, which will be simpler than managing upgrades with a pipeline that builds a new container image.
