alexellis/k3sup

Support issue for MicroOS

rombert opened this issue · 5 comments

rombert commented

Expected Behaviour

When running k3sup install against a MicroOS deployment the k3s-install.sh script installs the k3s systemd service but does not start it.

I suspect that this is done because a) it installs the system k3s-selinux package and b) MicroOS uses a read-only filesystem and needs a reboot to activate the installed package.

This means that a reboot is needed, otherwise the k3s service is not up and the kubeconfig is not generated.

Current Behaviour

k3sup install fails with

[INFO]  systemd: Enabling k3s unit
 [WARN]  Please reboot your machine to activate the changes and avoid data loss.
Created symlink /etc/systemd/system/multi-user.target.wants/k3s.service → /etc/systemd/system/k3s.service.

ssh: sudo cat /etc/rancher/k3s/k3s.yaml

Error: error received processing command: Process exited with status 1

Are you a GitHub Sponsor (Yes/No?)

  • Yes
  • No

Possible Solution

k3sup install could provide a flag that, when set to true, reboots the server before attempting to retrieve the kubeconfig.

Steps to Reproduce

  1. Download and install a MicroOS VM from https://get.opensuse.org/microos/#download . I use libvirtd - a direct link to the disk file is https://download.opensuse.org/tumbleweed/appliances/openSUSE-MicroOS.x86_64-ContainerHost-kvm-and-xen.qcow2
  2. run k3sup install

Context

Your Environment

  • k3sup version:
0.12.0
  • What Kubernetes distribution, client and server version are you using?
Client Version: version.Info{Major:"1", Minor:"24", GitVersion:"v1.24.0", GitCommit:"4ce5a8954017644c5420bae81d72b09b735c21f0", GitTreeState:"clean", BuildDate:"2022-05-05T00:00:00Z", GoVersion:"go1.18.3", Compiler:"gc", Platform:"linux/amd64"}
  • What OS or type or VM are you using for your cluster? Where is it hosted? (for k3sup install/join):

KVM-based virtual machine running on a remote host.

NAME="openSUSE MicroOS"
# VERSION="20220504"
ID="opensuse-microos"
ID_LIKE="suse opensuse opensuse-tumbleweed"
VERSION_ID="20220504"
PRETTY_NAME="openSUSE MicroOS"
ANSI_COLOR="0;32"
CPE_NAME="cpe:/o:opensuse:microos:20220504"
BUG_REPORT_URL="https://bugs.opensuse.org"
HOME_URL="https://www.opensuse.org/"
DOCUMENTATION_URL="https://en.opensuse.org/Portal:MicroOS"
LOGO="distributor-logo-MicroOS"
  • Operating System and version (e.g. Linux, Windows, MacOS):
$ uname -a
5.18.9-2-default
$ cat /etc/os-release
NAME="openSUSE Tumbleweed"
# VERSION="20220712"
ID="opensuse-tumbleweed"
ID_LIKE="opensuse suse"
VERSION_ID="20220712"
PRETTY_NAME="openSUSE Tumbleweed"
ANSI_COLOR="0;32"
CPE_NAME="cpe:/o:opensuse:tumbleweed:20220712"
BUG_REPORT_URL="https://bugs.opensuse.org"
HOME_URL="https://www.opensuse.org/"
DOCUMENTATION_URL="https://en.opensuse.org/Portal:Tumbleweed"
LOGO="distributor-logo-Tumbleweed"

"Be part of the solution"

Subject to approval, are you willing to work on a Pull Request for this issue or feature request?

  • Yes
  • No

(but expect slow progress, my knowledge of go is really basic)

alexellis commented

/set title: Support issue for MicroOS

alexellis commented

Hi there,

Thanks for your interest.

MicroOS seems to be an edge-case here. I don't want to implement the suggested fix, but you're welcome to patch your own version of k3sup or work around any issues you face.

As per the readme, you could reboot your own server then run: k3sup install --skip-install --ip ... to retrieve the kubeconfig after you've manually rebooted your machine.

Is there any reason why you can't use another distribution?

Alex

alexellis commented

/add label: wontfix

BuddhiAbeyratne commented

Hey @alexellis,

I know that the fix mentioned is a bit scuff but I do feel like it's a change that potentially won't break if we put a timer of sum sort with a retry mechanism

Rational:
MicroOS is supper helpful for running the underlying os updates fully unmanaged. Mainline support would make adoption easier for companies and individuals who would like to have a cluster with low maintenance cost.

Happy to make a PR if you are ok with the idea of having It implemented and would love to go over spec details with you.

If someone wants to build automation around your tool having a random failure makes debugging and detecting actual errors harder.

Trying to implement something to autosacale a bare mettle a provider similar to elastic AWS for shits and giggles and started facing this problem

alexellis commented

The hint about where this needs to be fixed is in the original issue comment:

"the k3s-install.sh script"

That's not something we control within k3sup. Please raise an issue with k3s.