-
Notifications
You must be signed in to change notification settings - Fork 4.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support for Windows 10 WSL2 #5392
Comments
Yes, there is a plan to support WSL2! I'm not sure if folks have experimented with Help wanted =) |
Interestingly, using WSL will not save you from running a VM. Similar to Docker-for-Windows it will just let you run on someone else’s VM... https://devblogs.microsoft.com/commandline/announcing-wsl-2/
|
For folks looking for WSL 2 support via In particular, it's worth noting the following: WhitewaterFoundry/Pengwin#485 (comment) for a Debian iptables incompatibility It's possible the Debian or Pengwin distros are compatible with the suggested fix, but I was not having luck switching on legacy iptables in the store-provided Ubuntu distro. Switching to virtualized minikube, it looks as if there are some Kernel flag incompatibilities in the stock WSL 2 kernel that ships with 1909: microsoft/WSL#4165 (comment) notes some kernel incompatibilities requiring a new kernel compile The noted kernel flag is now turned on by default in future kernel builds: https://github.com/microsoft/WSL2-Linux-Kernel/blob/master/Microsoft/config-wsl#L1448 Running that config file through Docker's ./check-config, all but CONFIG_DEVPTS_MULTIPLE_INSTANCES under "Generally Necessary" are enabled in Microsoft's latest Linux kernel builds. So I got myself a copy of the WSL2 kernel and followed the compile instructions (and inserting the missing "apt"): https://github.com/microsoft/WSL2-Linux-Kernel/blob/master/README-Microsoft.WSL2 (
It's getting late here, so I'll leave |
following these instructions: having some networking difficulties with that though so YMMV Edit: I also then managed to completely break my WSL install so be warned. Edit: ran afoul of this issue: microsoft/WSL#4364 😿 |
@chrisfowles It looks like there's a collision in the use of port 53 between WSL and Docker for WSL (or another user program on Windows listening on port 53) that causes this error... microsoft/WSL#4364 (comment) Personally, I'm still running Windows preview builds, but I've temporarily stopped experimenting with Docker/K8S inside WSL. I'll wait until I either have an urgent need or things have shipped and stabilized a bit more. Right now I don't see much of a performance penalty to using K8S from Docker for Windows, it would just be nice to standardize on one copy of Linux for all the things, but it sounds like there are still a couple rough edges being worked out. :) |
WSL2 and it's network limitations are causing issues for us (CRC/Minishift) to consider using this. There is a dedicated switch used, that is only usable for WSL2 and created on the fly (WSL), which does not allow you to easily communicate with others on the same host but other segments. This is unlike WSL1. We are still experimenting, but so far it has not been an improvement over the approach to just run a separate, and dedicated, VM |
not entirely same but in same category #3248 |
Wanting to check in on WSL2 support. Just thought I'd give it a shot but running into:
Docker is running with
I image WSL2 and minikube just aren't there yet, but thought I'd ask. EDIT: Never mind... I ran it without EDIT: Never mind... Worked for one day and now it is back to not working:
|
Have the same issue as above. Still can't use minikube on WSL on win10. |
Huzzah - WSL2 support works at head, with some caveats! I did some experimentation today with minikube on WSL2 (Ubuntu), specifically with
I found a solution for this issue at microsoft/WSL#4189 (comment)
That got me further, but it then v1.8.2 crashed with some bogus "machine not found error". I then upgraded to minikube v1.9.0 (master), and it all works just fine:
We'll definitely need to document this. |
@tstromberg Hi, thanks for the report, just wonder which version of minikube should I download to get it working? |
I'm curious what others' experience using Docker, kubectl, and minikube in WSL2 is. I personally had to throw in the towel after a few weeks and go back to my Ubuntu partition for a couple reasons:
If others are not experiencing this and are able to use this stack in WSL2 without issues, I'd like to hear what you are doing that I might be doing wrong. Would love to use WSL2, but in its current state, it just doesn't work for me. EDIT
Probably a dozen times in that time frame. |
@eox-dev - thanks for the update. I only had a chance to play around for a couple of minutes. Once a cluster is started, does it work until the host machine reboots? If not, what kind of errors are you seeing? |
Sorry just getting back to this. For a while, about a week and half, it was until the host machine rebooted. Then it became several times throughout the day.
First attempt at
Check
Fix it with the following:
Docker is back up and running. Second attempt as
Success!
I threw in the towel at that point. I found some similar issues that says it could be the I tried to Also, it takes about five minutes |
Windows 10 Home insider edition build 19041.208, Looks like everything is coming up except the pod/service network and the external NAT to the API server.
Some minikube logs container status
docker
kubelet
kube-apiserver
describe nodes
|
I also ran into the same issue running
Upon inspecting the minikube docker container, I do see the that using the exposed port (127.0.0.1:32834 ) works from the Ubuntu shell:
Comparing this to the URL used by
and as a result, it works without any issues. |
Windows 10 Pro: Insider build 19041.264 docker version
Got the same error as @svrc-pivotal with some additional info:
|
I was already trying to run the minikube on WSL 2 for a few days. Like my colleagues @nezorflame and @svrc-pivotal I was using a docker driver to start the minikube, but the same error was happening to them. So, I started looking for driver alternatives and in the minikube documentation I found: https://minikube.sigs.k8s.io/docs/drivers/podman/ Which is an experimental driver. I was hopeless about finding a solution, but I decided to test it and it works! |
@ReiJr : that is excellent news! It was actually intended for RHEL, great that it works on "Windows" Currently we are test-driving a new kicbase image that updates the underlying OS to Ubuntu 20.04 Issue #8250 Hopefully 1.11 |
Seems that microk8s doesn't have this problem https://ubuntu.com/blog/kubernetes-on-windows-with-microk8s-and-wsl-2 |
@thehappycoder I've been a happy user of |
Minikube also defaults to systemd, mostly because kubeadm does... There is some work to make it work on distributions without systemd, but those are getting more and more rare now. Especially the hacks to get systemd running in docker-on-docker (and crio-on-podman) are especially awful, and we regularly run into bugs with systemd that we have to patch downstream. |
In the case of WSL2 it's not a matter of distro, WSL2 instances simply don't run systemd by design, no matter the distro. What I'm trying to say is that it shouldn't be expected that users hack WSL2 themselves in order to be able to run I'm not sure how the WSL2 driver for |
The same is true for docker containers, so there are similar tricks into enabling it. We "borrow" those from KIND, but still: eeww COPY entrypoint /usr/local/bin/entrypoint
# systemd exits on SIGRTMIN+3, not SIGTERM (which re-executes it)
# https://bugzilla.redhat.com/show_bug.cgi?id=1201657
STOPSIGNAL SIGRTMIN+3
ENTRYPOINT [ "/usr/local/bin/entrypoint", "/sbin/init" ] (the |
I guess I will have to watch the video, to see why you want to run a LXD system container inside a Windows Server VM - rather than just spawning an Ubuntu VM and installing Kubernetes on it... |
Because Microsoft did a great job at integrating WSL2 inside their OS. You can share files seamlessly between Windows and WSL2 instances, access services running inside WSL2 on It's all about the tight integration and the user experience. If you don't care about that, a VM is perfectly fine, but WSL2 offers much more than that. But I digress, this thread is about minikube's WSL2 integration. @afbjorklund when you mentioned
did you mean the current WSL2 backend is just a wrapper around |
Ok, get it. Sounds similar to the Docker Desktop user experience.
I don't think that minikube has a WSL2 backend (yet?) This issue is talking about two very different tracks:
Then there are other ways, like running "remotely".
|
Sounds like a "proper" WSL2 backend could borrow a lot of great ideas from Docker for Windows then :)
|
@antoineco : we are trying converting the buildroot iso image to a docker tar image #6942 Maybe some of that would be applicable to WSL2 as well, since it's not a traditional hypervisor
But there's all kinds of fun stuff involved, like when |
Right, even better if it's already a tgz. I've never looked into the internals and I believe you when you say it will most likely not work out of the box. Maybe some of the ideas exchanged here will become useful if someone ever gets their hands dirty with a true WSL2 backend. |
Curious how you are connecting to the cluster from browser. |
I've just tried the
Not sure, maybe some extra work is required, but for now it seems working. Great job! |
I'm trying to play with the Windows build 161, WSL 2.0 after upgrades of May 2020 and CentOS 8. It looks like I hit the same issue. My iptables version is v1.8.4 (nf_tables). All WSL 2 distros share the same Linux kernel from Microsoft 4.19.121-microsoft-standard The is purpose is VSCode partner Docker instead of Docker Desktop which introduces too many dependencies from Windows and MobyLinux, for integration with Cmd.exe, PowerShell, Windows Defender and VPN. |
Hi all, (I followed this article: https://medium.com/javarevisited/using-wsl-2-with-x-server-linux-on-windows-a372263533c3) I haven't got the foggiest idea as to why this is the case... any explanation is highly appreciated! |
@huberv if the minikube command you posted is running inside the WSL instance and not in some other VM, all services exposed on the WSL loopback should also be exposed on the Windows network. I use this all the time with |
Is there is a plan to support WSL2 on Windows 10?
Docker is already experimenting with it:
https://docs.docker.com/docker-for-windows/wsl-tech-preview/
Do You think supporting WSL2 could save us from using virtual machines?
The text was updated successfully, but these errors were encountered: