Improve Getting Started documentation for WSL2 & Docker

[spowelljr]

We should include all the steps for the user on how to get minikube working with WSL2 and the Docker driver.

Some of the things we need to include are how to change the Linux distro from WSL(1) to WSL2, and enabling the WSL2 backend in Docker Desktop. This should improve the success rate of new Windows users using minikube.

[afbjorklund]

how to change the Linux distro from WSL(1) to WSL2,

that is not really the "Linux distro", that is the whole OS platform ?

i.e. switching from running containers to running virtual machines

https://docs.microsoft.com/en-us/windows/wsl/compare-versions

But then we need to talk about distributions, especially with the known failures when using a system distro...

System has not been booted with systemd as init system (PID 1). Can't operate.

Basically the WSL2 HyperKit VM is being shared between all running distros, running as system containers.

Most likely it will need some special consideration, when adding another layer ?

---

i.e. this affects other drivers as well, not only the "docker" driver.

there is the "none" driver today, and soon a "podman" driver (for WSL)

[jornh]

Some of the things we need to include are how to change the Linux distro from WSL(1) to WSL2, and enabling the WSL2 backend in Docker Desktop. This should improve the success rate of new Windows users using minikube.

Just a quick additional note here. Take it as sort of an experience report from a new user - on what would have helped me in the documentation.

The biggest Fear, Uncertainty and Doubt 😉 inducing part for for me on getting up to speed with Docker & WSL2 (with my preferred working environment being the shell in my WSL distro) was actually this:

• I didn't know that with Docker Desktop & WSL2 already in place - as is now documented through Add docs for setting up WSL 2 & Docker #13345 - all I really needed to install was the Minicube .deb and everything would work seamlessly for my use case. (I guess biggest point was I didn't think minikube would be clever enough to detect the Docker Desktop based docker so it would instead try installing Docker locally, e.g. using a "none" driver, and install yet another Docker in the WSL linux distro)

This is the path I ended up taking:

1. So I actually started off with installing the Windows minicube - that worked fine, but only on the Windows side. It gave me an awful experience from the WSL shell because it added Windows paths to certs etc. in my ~/.kube/config due to that it is shared with some symlinking across the Windows and WSL - unsure but I think something that is configured by Microsofts WSL integration.
2. My next step was to try adding the minikube executable
3. I then did brew uninstall minikube and did the minikube .deb install - and happiness started. 😸 (Meaning I could just have skipped step 1 & 2 - and avoided step 4)
4. I still need to assemble courage and time to uninstall the windows install which I probably will not need.

To sum up: I think there are a number of different ways people prefer to work with minikube (my preferred way is just one example). So I would suggest to start off enumerating at least some of those ways (more can always be added later). Just having a brief mention of that this WSL2/Docker Desktop combination actually works so smoothly

Perhaps a structure like this - with each of the examples would have enough of, steps to do and what you will get ():

• Docker Desktop based
  • minikube working smoothly from Windows (install the windows minikube, e.g. with winget)
  • minikube working smoothly from a WSL2 distro (Docker Desktop w. WSL2 integration, then install package for your distro or from curl/tar)
  • ... perhaps - an option where both will work, by breaking the ~/.kube/config or something. => More work, but some people may want this ...
• Other ways on a Windows machine
  • docker/podman - "none" driver based ??...
  • HyperV VM based ...?
  • ... etc

Thoughts?

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

[k8s-ci-robot]

@k8s-triage-robot: Closing this issue, marking it as "Not Planned".

In response to this:

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.