kubernetes / minikube

Run Kubernetes locally
https://minikube.sigs.k8s.io/
Apache License 2.0
29.45k stars 4.88k forks source link

add documentation for WSL2 #7879

Open cheslijones opened 4 years ago

cheslijones commented 4 years ago
  1. minikube start --driver=docker
  2. minikube ip = 172.17.0.2

How are you supposed to access the web app from a browser when the IP is 172.17.0.2? Browser just spins for a while before saying it can't connect. Only occurs when --driver=docker. Just about every other driver gives you an ip that is accessible from browser.

tstromberg commented 4 years ago

If you are on Docker for macOS or Docker for Windows, networking works a bit differently, as there is no direct IP connectivity to the container. On these platforms, Docker requires individual ports to be proxied through.

See the Deploy applications section of https://minikube.sigs.k8s.io/docs/start/ for instructions on how to get access to your service. Please let me know if this helps!

cheslijones commented 4 years ago

Sorry, I should have specified I'm experimenting with WSL2 and installing docker, kubectl, minikube, and skaffold directly into it and not using Docker for Windows.

I followed the steps in that I basically copied and pasted all of them and was still unable to get any kind of contact between the cluster and browser.

$ kubectl get all
NAME                                  READY   STATUS    RESTARTS   AGE
pod/balanced-77b47f955f-z8z44         1/1     Running   0          2m26s
pod/hello-minikube-5655c9d946-t6fh6   1/1     Running   0          5m31s

NAME                     TYPE           CLUSTER-IP      EXTERNAL-IP     PORT(S)          AGE
service/balanced         LoadBalancer   10.107.211.77   10.107.211.77   8000:31796/TCP   2m20s
service/hello-minikube   NodePort       10.107.31.112   <none>          8080:32498/TCP   5m26s
service/kubernetes       ClusterIP      10.96.0.1       <none>          443/TCP          22m

NAME                             READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/balanced         1/1     1            1           2m26s
deployment.apps/hello-minikube   1/1     1            1           5m31s

NAME                                        DESIRED   CURRENT   READY   AGE
replicaset.apps/balanced-77b47f955f         1         1         1       2m26s
replicaset.apps/hello-minikube-5655c9d946   1         1         1       5m31s

When I did the hello-minikube examples it gave:

$ minikube service hello-minikube
|-----------|----------------|-------------|-------------------------|
| NAMESPACE |      NAME      | TARGET PORT |           URL           |
|-----------|----------------|-------------|-------------------------|
| default   | hello-minikube |        8080 | http://172.17.0.2:32498 |
|-----------|----------------|-------------|-------------------------|
πŸŽ‰  Opening service default/hello-minikube in default browser...
πŸ‘‰  http://172.17.0.2:32498

The balanced examples gave me 10.107.211.77. In both cases, the browser eventually just said "Hmmmm.... can't reach this page".

If I could get the examples to work, I could more than likely figure out how to apply this to my ingress controller for my actual application.

winhtaikaung commented 4 years ago

I am facing this too

cheslijones commented 4 years ago

@winhtaikaung Any luck on your end? If not, would love to hear from a dev or someone who knows how to get around this issue.

afbjorklund commented 4 years ago

Like stated above, this is different when running on Mac or Win - the IP is accessible on Linux...

This is a Docker VM limitation, unfortunately. You might also want to try other minikube drivers ?

https://docs.docker.com/docker-for-mac/networking/#known-limitations-use-cases-and-workarounds

https://docs.docker.com/docker-for-windows/networking/#known-limitations-use-cases-and-workarounds

cheslijones commented 4 years ago

There are no other minikube driver choices for WSL2. You can't have virtualization in WSL2 so scratch kvm2, vmware, hyperv, virtualbox, etc. none doesn't work either. Pretty much just leaves docker.

To expand on "none doesn't work either"...

$ sudo minikube start --driver=none --kubernetes-version=1.15.10
πŸ˜„  minikube v1.9.2 on Ubuntu 20.04
✨  Using the none driver based on existing profile
πŸ‘  Kubernetes 1.18.0 is now available. If you would like to upgrade, specify: --kubernetes-version=1.18.0
πŸ‘  Starting control plane node  in cluster minikube
πŸ”„  Restarting existing none bare metal machine for "minikube" ...
ℹ️  OS release is Ubuntu 20.04 LTS

❌  [NONE_DOCKER_EXIT_1] Failed to enable container runtime enable docker.: sudo systemctl start docker: exit status 1
stdout:

stderr:
System has not been booted with systemd as init system (PID 1). Can't operate.
Failed to connect to bus: Host is down

πŸ’‘  Suggestion: Either systemctl is not installed, or Docker is broken. Run 'sudo systemctl start docker' and 'journalctl -u docker'
πŸ“˜  Documentation: https://minikube.sigs.k8s.io/docs/reference/drivers/none
⁉️   Related issue: https://github.com/kubernetes/minikube/issues/4498

$ sudo systemctl start docker
System has not been booted with systemd as init system (PID 1). Can't operate.
Failed to connect to bus: Host is down

Docker is running, by the way... so the error makes no sense.

afbjorklund commented 4 years ago

There are no other minikube driver choices for WSL2. You can't have virtualization in WSL2 so scratch kvm2, vmware, hyperv, virtualbox, etc. none doesn't work either. Pretty much just leaves docker.

WSL (1 is container, 2 is vm) is a little like LXD, it will take more effort to get minikube working there.

See #5392 for details.

The error seems to be due to WSL2 not using systemd, can probably be worked around ? #6954

Sorry for missing "WSL"

sharifelgamal commented 4 years ago

@eox-dev any luck with the above advice?

cheslijones commented 4 years ago

@sharifelgamal Well, basically using docker as the driver doesn't work. Fortunately, podman does although I haven't worked with it extensively so far.

EDIT: Got to play with this for a few hours today. Same issue as with --driver=docker. Get an IP address that I can't access from the browser. Pretty sure not an ingress-nginx as I am using the same version in Pop!_OS and everything works perfectly over there with --driver=kvm2.

Would be great if Microsoft would implement nested virtualization in WSL2 just so you can install kvm or something.

medyagh commented 4 years ago

@eox-dev we had a PR that added support for WSL do you mind trying the binary in this PR to see if that fixes your problem for docker or podman driver?

https://github.com/kubernetes/minikube/issues/7420#issuecomment-638477659

cheslijones commented 4 years ago

@medyagh I gave it a shot, but still running into the same issue where the running application cannot be accessed from the browser.

work@RBA15-WINDOWS:~$ ./minikube-linux-amd64 ip
127.0.0.1

It is usually 172.17.0.2 or 172.17.0.3 with latest release of minikube.

When I deploy the ingress-nginx to route traffic to my app's endpoints though, ingress controller uses 172.17.0.3 and I can't access it.

image

Maybe, it is something I'm just not overlooking, but I have zero issues in macOS with hyperkit and Linux with kvm2. Maybe it is just an issue with WSL2 or the Docker driver.

At some point today I plan on going through this: https://kubernetes.io/blog/2020/05/21/wsl-docker-kubernetes-on-the-windows-desktop/. Maybe that will get me up and running with WSL.

medyagh commented 4 years ago

@medyagh I gave it a shot, but still running into the same issue where the running application cannot be accessed from the browser.

work@RBA15-WINDOWS:~$ ./minikube-linux-amd64 ip
127.0.0.1

It is usually 172.17.0.2 or 172.17.0.3 with latest release of minikube.

When I deploy the ingress-nginx to route traffic to my app's endpoints though, ingress controller uses 172.17.0.3 and I can't access it.

image

Maybe, it is something I'm just not overlooking, but I have zero issues in macOS with hyperkit and Linux with kvm2. Maybe it is just an issue with WSL2 or the Docker driver.

At some point today I plan on going through this: https://kubernetes.io/blog/2020/05/21/wsl-docker-kubernetes-on-the-windows-desktop/. Maybe that will get me up and running with WSL.

thank you for providing more context, seems like you found a bug ! I belive u can fix that by using 127.0.0.1 IP and we will need to open a port for the ingress port,

is the port for ingress 80 ? when you used to access 172.17.0.2, did u curl it on http: or https?

cheslijones commented 4 years ago

Yes, using port 80 for local dev. curl on http.

medyagh commented 4 years ago

for docker driver we will need to create a port on 80 during container creation time, this is do-able.

this would be a good fit for v1.12.0 to make docker driver the default driver

@eox-dev do you mind porviding me extact steps, steps by step so I make a PR to fix this?

aaomidi commented 4 years ago

Whats the current work around? Since I'm working with an application that does oauth authentication, I need an IP and Port that preferably doesn't change between each dev build I get out to test.

cheslijones commented 4 years ago

@medyagh Hi, sorry for the delay on getting this to you. I'm so jaded with trying to get this working after so many hours, it takes a lot of motivation to get me looking at it again.

I made this repo with a lengthy README.md with the steps. Let me know if you'd like me to post those steps here as well:

https://github.com/eox-dev/minikube-wsl2

medyagh commented 4 years ago

@medyagh Hi, sorry for the delay on getting this to you. I'm so jaded with trying to get this working after so many hours, it takes a lot of motivation to get me looking at it again.

I made this repo with a lengthy README.md with the steps. Let me know if you'd like me to post those steps here as well:

https://github.com/eox-dev/minikube-wsl2

@eox-dev that is cool ! I would be happy to review the PR if you like to add this as a tutorial to our docs https://minikube.sigs.k8s.io/docs/tutorials/

cheslijones commented 4 years ago

@medyagh Did this help in resolving the issue related to the following comment: https://github.com/kubernetes/minikube/issues/7879#issuecomment-642301304 I'm unable to connect to the running application in the cluster for reasons mentioned in there.

ashishsecdev commented 4 years ago

I am on Windows, any luck with the solution?

aaomidi commented 4 years ago

This has been working fine with me, minikube tunnel command opens up the proper access.

cheslijones commented 4 years ago

This has been working fine with me, minikube tunnel command opens up the proper access.

Using --vm-driver=docker?

Anything special in your ingress configuration?

Just running minikube tunnel with no additional flags?

What is your minikube tunnel output and what is the IP you are navigating to?

As I put in my repo, I've tried just running minikube tunnel and get the following output:

Status:
        machine: minikube
        pid: 4065
        route: 10.96.0.0/12 -> 172.17.0.3
        minikube: Running
        services: [ingress-nginx]
    errors: 
                minikube: no errors
                router: no errors
                loadbalancer emulator: no errors

Go to browser and try to access the running web app in the cluster by navigating to 10.96.0.0 and still run into the same issue as I do when I just try navigating to 172.17.0.3. Browser can't connect.

aaomidi commented 4 years ago

minikube tunnel

My service type is LoadBalancer

{
    "apiVersion": "v1",
    "kind": "Service",
    "metadata": {
        "namespace": "testns",
        "name": "x-service-service"
    },
    "spec": {
        "ports": [
            {
                "port": 3000,
                "targetPort": 3000
            }
        ],
        "selector": {
            "app": "x-service"
        },
        "type": "LoadBalancer"
    }
}
ashishsecdev commented 4 years ago

I tried 'minikube tunnel' already but got no response, just the blinking cursor. I am on Windows 10 and using Docker driver to connect.

Is there any settings that I should change before hitting 'minikube tunnel'?

ashishsecdev commented 4 years ago

minikube tunnel

  • Starting tunnel for service xyz-service-service.

My service type is LoadBalancer

{
    "apiVersion": "v1",
    "kind": "Service",
    "metadata": {
        "namespace": "testns",
        "name": "x-service-service"
    },
    "spec": {
        "ports": [
            {
                "port": 3000,
                "targetPort": 3000
            }
        ],
        "selector": {
            "app": "x-service"
        },
        "type": "LoadBalancer"
    }
}

"Tunnel" option by default works for connecting with LB services.

cheslijones commented 4 years ago

Read up on:

https://minikube.sigs.k8s.io/docs/handbook/accessing/#loadbalancer-access

So is the LoadBalancer supposed to sit in front of the ingress ngixnx controller I'm using or bypass it altogether?

I guess what I'm not understanding is why this is would even be necessary.

So I guess it is the nature of --vm-driver=docker that requires these extra steps of creating a separate LoadBalancer or something?

Upgraded to minikube ip v1.12.0. Now instead of minikube ip being 172.17.0.2, it is 127.0.0.1, which still... can't connect to the running application from the browser. Also tried every Load Balancer IP in every name space with minikube tunnel active (which there was no output to the console while it was running).

At any rate, maybe someone can take a look at my repo when they have 10 minutes to kill and tell me where I am going wrong:

https://github.com/eox-dev/minikube-wsl2

ashishsecdev commented 4 years ago

@eox-dev : I am also stuck on it, looks like I will have to move on AWS to test my deployments.

JohnShahawy commented 4 years ago

@ashishsecdev Would suggest to use kubectl port-forward as a workaround until this is fully fleshed out.

ashishsecdev commented 4 years ago

@JohnShahawy Thanks for your response, I tried >kubectl port-forward webapp{PodName} 30080:30080 but it didn't worked. I am getting the below error on my windows CLI E0717 01:29:06.889150 14396 portforward.go:400] an error occurred forwarding 30080 -> 30080: error forwarding port 30080 to pod c94703e2657682384741912f91a64b7faa4063ec32e8f9d64de0b46f1c2febfe, uid : exit status 1: 2020/07/16 19:59:06 socat[4945] E connect(5, AF=2 127.0.0.1:30080, 16): Connection refused Handling connection for 30080 E0717 01:29:06.907151 14396 portforward.go:400] an error occurred forwarding 30080 -> 30080: error forwarding port 30080 to pod c94703e2657682384741912f91a64b7faa4063ec32e8f9d64de0b46f1c2febfe, uid : exit status 1: 2020/07/16 19:59:06 socat[4946] E connect(5, AF=2 127.0.0.1:30080, 16): Connection refused

ashishsecdev commented 4 years ago

I am trying to create the VMSwitch but it is giving the following error.

PS C:\WINDOWS\system32> New-VMSwitch -Name "Minikube" -AllowManagementOS $True -NetAdapterName $net.Name New-VMSwitch : Failed while adding virtual Ethernet switch connections. Ethernet port '{3A7485A2-9AD6-4889-BFD3-21377A06F1D3}' bind failed: Catastrophic failure (0x8000FFFF). At line:1 char:1 New-VMSwitch -Name "Minikube" -AllowManagementOS $True -NetAdapterNam ... CategoryInfo : NotSpecified: (:) [New-VMSwitch], VirtualizationException FullyQualifiedErrorId : OperationFailed,Microsoft.HyperV.PowerShell.Commands.NewVMSwitch

medyagh commented 4 years ago

@ashishsecdev @JohnShahawy @eox-dev @aaomidi @winhtaikaung

the WSL2 should work now with Docker driver, do you mind trying latest minikube version and docker driver?

ensure docker is running and

minikube delete
minikube start --driver=docker
cheslijones commented 4 years ago

@medyagh Well, I gave it a shot on a few Windows instances. One a fresh Boot Camp partition and the other a fresh VMware Fusion Windows 10 VM. In both cases, I get the same kind of error, which is probably not related to minikube, but skaffold or docker. I haven't received it before.

This is with using skaffold to spin up the cluster:

 - deployment/client-deployment-dev: container client is waiting to start: companyappacr.azurecr.io/company-app-client:48afc5a81605a63070a8d39378397654f27ac73dfb89a3dc094e90673564654b can't be pulled
    - pod/client-deployment-dev-679b6f9576-86cqb: container client is waiting to start: companyappacr.azurecr.io/company-app-client:48afc5a81605a63070a8d39378397654f27ac73dfb89a3dc094e90673564654b can't be pulled
 - deployment/client-deployment-dev failed. Error: container client is waiting to start: companyappacr.azurecr.io/company-app-client:48afc5a81605a63070a8d39378397654f27ac73dfb89a3dc094e90673564654b can't be pulled.
 - deployment/api-deployment-dev: container api is waiting to start: companyappacr.azurecr.io/company-app-api:920d9cc2a014c57e61c61545e649f71a634a37eecd61123e4a90956f0333248b can't be pulled
    - pod/api-deployment-dev-686558485c-hkxgm: container api is waiting to start: companyappacr.azurecr.io/company-app-api:920d9cc2a014c57e61c61545e649f71a634a37eecd61123e4a90956f0333248b can't be pulled
 - deployment/api-deployment-dev failed. Error: container api is waiting to start: companyappacr.azurecr.io/company-app-api:920d9cc2a014c57e61c61545e649f71a634a37eecd61123e4a90956f0333248b can't be pulled.

I did noticed that minikube ip still comes up with 127.0.01, but because the cluster won't spin up I can't really test it. Maybe one of the others can try it out. I've honestly thrown in the towel with WSL2 being a viable solution and have just been using Pop!_OS or macOS. Maybe someday Microsoft will get it right. At a minimum WSL2 should be functionally the same as the Linux distro of choice... it just isn't.

magnus-larsson commented 4 years ago

Created an issue on problems with minikube tunnel on WSL 2 using minikube v1.14.0, see #9482

Bouhaha-Anas commented 3 years ago

hey @cheslijones, i'm newby in kubernetes and i'm following an online course, I was facing the same problem. I'm working on windows OS (note that the course tutor was working on MacOS), when i made the minikube ip it returns 127.0.0.1 and when i flip to my browser entering the 127.0.0.1:<my-nodePort> the site is not reachable..

But when i ran the command minikube service <my-service> it gave:

NAMESPACE NAME TARGET PORT URL
default client-node-port 3050 http://192.168.49.2:31515
NAMESPACE NAME TARGET PORT URL
default client-node-port http://127.0.0.1:57808

it had opened the browser and showed my application but exposed to a nodePort other than mentionned in my service file ..

I don't know if i could say that the problem is solved or not because the node-port is not the same that i've defined in my configuation.

Aut0R3V commented 3 years ago

@medyagh Hi, sorry for the delay on getting this to you. I'm so jaded with trying to get this working after so many hours, it takes a lot of motivation to get me looking at it again. I made this repo with a lengthy README.md with the steps. Let me know if you'd like me to post those steps here as well: https://github.com/eox-dev/minikube-wsl2

@eox-dev that is cool ! I would be happy to review the PR if you like to add this as a tutorial to our docs https://minikube.sigs.k8s.io/docs/tutorials/ Hey, I just wanted to know if this documentation was updated. If not, then I'd like to help with this.

cheslijones commented 3 years ago

@Aut0R3V Hi, I never updated and sent a PR because I could never get it working.

Aut0R3V commented 3 years ago

@cheslijones thanks for the reply. I also tried solving it using that documentation but I'm getting some issues.

igortas commented 3 years ago

Is there any news on this topic? How to use localhost for nodeport, loadbalancer or ingress, when minikube, kubectl and docker are installed in WSL2, but there is no docker-desktop at all, or minikube as windows executable. Address is constantly 192.168.49.2, and can't be accessed from browser or postman(insomnia).

cheslijones commented 3 years ago

@igortas This is what has been working for me. I've actually been using WSL2 for a few months or so for development, which I thought I'd never see the day that would happen.

This is what I've been doing and tested on several installs:

  1. Install WSL2 (obviously)... I've just been using Ubuntu 20.04 and make sure you are always working in ~/ and not the Windows file system /mnt/c/.
  2. Install docker directly into WSL2 without Docker Desktop using the Linux instructions. (Also, make sure to create docker group and add user, restart WSL2, and make sure it is running with sudo service docker start).
  3. Install kubectl using the Linux instructions.
  4. Install minikube using the Linux instructions.
  5. Install skaffold (not necessary but that is what I use to build the docker images and deploy to minikube)... install using the Linux instructions.
  6. Create your minikube profile with: minikube start --driver=docker.
  7. For ingress-nginx I run the following command. It is actually labeled as being for Docker for Mac, but it works with Docker Desktop for Windows, Docker Desktop for macOS, and apparently WSL2 without Docker Desktop for Windows: kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v0.45.0/deploy/static/provider/cloud/deploy.yaml.
  8. Start-up your cluster. In my case it is just: skaffold dev.
  9. When it is starting up, or after, run: minikube tunnel in a separate terminal.
  10. You will be prompted for your sudo and it will say something about needing to access privileged port, or something to that effect.
  11. You won't see any output in that terminal window after sudo (that tripped me up the first time), but when you go to 127.0.0.1 or localhost in the browser, you'll see the application running as expected. (minikube ip and minikube profile list will always say 192.168.49.2, just ignore it).

That is my use case and that has worked for me on any computer I've tried it on. Kind of lame having minikube tunnel using up a terminal window, but it is what it is. Don't know about NodePort, or LoadBalancer, I just use ingress-nginx.

The thing I like about this is the directions are basically the same whether using macOS, WSL2, or Windows, so it is easier to communicate. Doing this on Linux doesn't quite work the same due to Docker networking differently in Linux, but it sounds like it is being addressed: https://github.com/kubernetes/minikube/issues/10812. On Linux using the --driver=docker actually gives it a unique IP address (I believe).

I'm just using the Beta Channel Windows, but it worked for me on the Relase Channel as well. No modifications whatsoever to WSL2 or the kernel, just a clean install of WSL2.

I'm even running mkcert for TLS certificates in local development due to working with external APIs. If you need that as well I can provide instructions on that as well.

igortas commented 3 years ago

@cheslijones I will update your answer about my working solution with services exposed as nodePort and ingress.

  1. I have custom ingress file, the key host is host: localhost
  2. In separate terminal, i'm running minikube tunnel
  3. curl localhost

For now minikube don't like to work if i set custom host in ingress, even I've tried to update /etc/localhosts/ as: 192.168.49.2 local.dev, for example

Update: I like to add another point which is connected to kube-apiserver and installation with snap. Snap was throwing error: cannot communicate with server: Post http://localhost/v2/snaps/kube-apiserver: dial unix /run/snapd.socket: connect: no such file or directory First there is currently one script on github: https://github.com/DamionGans/ubuntu-wsl2-systemd-script which enables systemd on wsl2 and helps to run with snap, but after the restart my VS Code terminal was mess and stop to sync everything from git, started mounting /mnt/c, instead linux etc.. So this is the reference to the correct answer. https://github.com/microsoft/WSL/issues/2972#issuecomment-653714964

medyagh commented 3 years ago

@cheslijones thank you for sharing your interesting story of using minikube, I am glad you got it working in WSL2,

I agree it is kind of not ideal to have another terminal to use the loadbalancer feature, to avoid that you could use the minikube server command

if you have a nodeport or hostport service you could list them with minikube service list and access then using minikube service svc_name

@igortas do you feel like we should a documentation page just for WSL2 on our website ? if yes would you be interested to add a section in docker driver for WSL2 ?

https://minikube.sigs.k8s.io/docs/drivers/docker/

shankar-forgerock commented 3 years ago

Hi Medya,

Thank you for the pointer.

https://minikube.sigs.k8s.io/docs/drivers/docker/Β  looks very promising.

For WSL2 environments, it will be worth clarifying if Docker should be installed on WSL2 guest or in Windows host.

Regards

Shankar

On 5/12/21 11:55 AM, Medya Ghazizadeh wrote:

@cheslijones https://github.com/cheslijones thank you for sharing your interesting story of using minikube, I am glad you got it working in WSL2,

||

I agree it is kind of not ideal to have another terminal to use the loadbalancer feature, to avoid that you could use the minikube server command

if you have a nodeport or hostport service you could list them with |minikube service list| and access then using minikube service svc_name

@igortas https://github.com/igortas do you feel like we should a documentation page just for WSL2 on our website ? if yes would you be interested to add a section in docker driver for WSL2 ?

https://minikube.sigs.k8s.io/docs/drivers/docker/ https://minikube.sigs.k8s.io/docs/drivers/docker/

β€” You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/kubernetes/minikube/issues/7879#issuecomment-840020955, or unsubscribe https://github.com/notifications/unsubscribe-auth/AISGH6PRJQK5VIHL6OBEYGLTNLFINANCNFSM4MPUXWPA.

--

ForgeRock https://www.forgerock.com/ Shankar Raman Senior Technical WriterΒ  |Β  ForgeRock @. @.> web www.forgerock.com https://www.forgerock.com/

-- ForgeRock values your Privacy https://www.forgerock.com/your-privacy

igortas commented 3 years ago

@shankar-forgerock Install and configure everything inside WSL2. U don't need docker-desktop.

@medyagh Looks like a good idea. Where we can continue to chat on this topic?

dgoldssfo commented 3 years ago

Any news yet on whether this might be fixed with Windows 11?

k8s-triage-robot commented 3 years ago

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:

You can:

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

/lifecycle stale

sayantani11 commented 3 years ago

Is the issue solved? I also use minikube on WSL, but I haven't faced this problem as of now. But I am also unable to go through the entire conversation, can someone summaries may be?

sayantani11 commented 3 years ago

There are no other minikube driver choices for WSL2. You can't have virtualization in WSL2 so scratch kvm2, vmware, hyperv, virtualbox, etc. none doesn't work either. Pretty much just leaves docker.

To expand on "none doesn't work either"...

$ sudo minikube start --driver=none --kubernetes-version=1.15.10
πŸ˜„  minikube v1.9.2 on Ubuntu 20.04
✨  Using the none driver based on existing profile
πŸ‘  Kubernetes 1.18.0 is now available. If you would like to upgrade, specify: --kubernetes-version=1.18.0
πŸ‘  Starting control plane node  in cluster minikube
πŸ”„  Restarting existing none bare metal machine for "minikube" ...
ℹ️  OS release is Ubuntu 20.04 LTS

❌  [NONE_DOCKER_EXIT_1] Failed to enable container runtime enable docker.: sudo systemctl start docker: exit status 1
stdout:

stderr:
System has not been booted with systemd as init system (PID 1). Can't operate.
Failed to connect to bus: Host is down

πŸ’‘  Suggestion: Either systemctl is not installed, or Docker is broken. Run 'sudo systemctl start docker' and 'journalctl -u docker'
πŸ“˜  Documentation: https://minikube.sigs.k8s.io/docs/reference/drivers/none
⁉️   Related issue: https://github.com/kubernetes/minikube/issues/4498

$ sudo systemctl start docker
System has not been booted with systemd as init system (PID 1). Can't operate.
Failed to connect to bus: Host is down

Docker is running, by the way... so the error makes no sense.

Try: minikube start --vm-driver=docker minikube ip = <ip>

sayantani11 commented 3 years ago

And we should have docker running in the background or else it won't work I guess

afbjorklund commented 3 years ago

Trying to use systemd where not available is probably a bug, though: https://github.com/kubernetes/minikube/issues/12276#issuecomment-899780802

k8s-triage-robot commented 3 years ago

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:

You can:

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

/lifecycle rotten

sh2sg commented 1 year ago

To get host applications such as Browser, IDE, Postman to connect to services/applications deployed in Minikube via Ingress,