Microsoft Windows support

[AceHack]

What would you like to be added:
I would like support for the kubefirst cli on native windows installed with something like scoop or choco

Why is this needed:
K3d and kubeadm are supported on windows. What would stop this?

[PatrickLaabs]

Hey @AceHack,
as far as I am aware of, the limitation is currently made by the way the binaries are being built. And this is not the only thing, that might hurt.

If you are using a Windows Machine you can use WSL2 or Multipass to create Linux VM.
WSL2 is a little bit closer to the Windows operating system, of a system perspective (you will have your home directory mounted on the windows side, on Multipass you will have to set it up by yourself). But both ways will do its thing.

The installation of WSL2 is pretty much straightforward:
https://learn.microsoft.com/en-us/windows/wsl/install

But: (@jarededwards , @fharper , @johndietz correct me if I am wrong)
The Team is also working on implementing a feature, to run kubefirst on an already provisioned kubernetes cluster. Like Docker-Desktop Kubernetes, or Rancher-Desktop. Which MIGHT make it possible to run kubefirst (if the binary gets build for windows) on windows.

[claywd]

@AceHack Hey! Thanks for popping this issue!

Firstly, I would have to validate that all of our dependencies can run cross platform and don't have any assumptions of a *nix system. Off the top of my head, I think most of our packages are cross platform already. I think certs might be a sticking point and some port forwarding commands we like that don't translate. Basically, anywhere we call the system kernel for path based utils, we'd have to confirm support for in windows. Alot of isn't going to be supported so we'd have to dev out alternatives and feature flag based on platform.

Secondly, our primary support platform is *nix systems. If we ran into issues on Windows, it might take a while for things to get handled. Probably not the experience we want to create for users.

Lastly, as @PatrickLaabs pointed out, we really do have it working in Windows Subsystem for Linux using docker desktop (on windows). I use it as my daily driver and although it can be a bit slow (because of how extensive the platform is) it definitely works and is very usable.

Let me know what your thoughts are and if there is a really compelling case for native windows support via powershell and the various windows package managers we can spike out what it would take and put it on the roadmap somewhere.

[fharper]

@PatrickLaabs was also right about running kubefirst on an existing cluster.

In 2.1, you'll be able to use Helm & kubectl to deploy the kubefirst ecosystem without using our CLI, and it's dropping tonight. Keep a closer look on our blog for more information.

[PatrickLaabs]

Just to mention with 2.1 and WSL2:

You need to import your generated certificates from mkcert to your trusted store and restart your browser. I did this with Chrome (Inside the settings, and looked up for 'certificate') in order to open up the web application. (But all Chromium-powered Browsers follow the same pattern, like Edge)
The Path of your certificates can be found via 'mkcert -CAROOT'

Currently, you cannot use the new Kubefirst Web-Console for a local provisioning of a cluster. I hope this feature will come soon :) But you can start with Civo and AWS

https://kubefirst.io/blog/release2-1/

[fharper]

@claywd will write down some documentation about this soon, stay tuned!

[fharper]

@AceHack is running kubefirst on WSL2 a proper solution for you?