Open cheslijones opened 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!
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.
I am facing this too
@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.
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
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.
There are no other
minikube
driver choices for WSL2. You can't have virtualization in WSL2 so scratchkvm2
,vmware
,hyperv
,virtualbox
, etc.none
doesn't work either. Pretty much just leavesdocker
.
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"
@eox-dev any luck with the above advice?
@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.
@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
@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.
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 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
or172.17.0.3
with latest release ofminikube
.When I deploy the
ingress-nginx
to route traffic to my app's endpoints though, ingress controller uses172.17.0.3
and I can't access it.Maybe, it is something I'm just not overlooking, but I have zero issues in macOS with
hyperkit
and Linux withkvm2
. 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?
Yes, using port 80 for local dev. curl
on http.
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?
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.
@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:
@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:
@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/
@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.
I am on Windows, any luck with the solution?
This has been working fine with me, minikube tunnel
command opens up the proper access.
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.
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"
}
}
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'?
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.
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.
minikube start --vm-driver=kvm2
, minikube addons enable ingress
, skaffold dev
and it just works... no minikube tunnel
, making a separate LoadBalancer, etc.minikube start --vm-driver=hyperkit
, minikube addons enable ingress
, skaffold dev
and it just works... no minikube tunnel
, making a separate LoadBalancer, etc.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:
@eox-dev : I am also stuck on it, looks like I will have to move on AWS to test my deployments.
@ashishsecdev Would suggest to use kubectl port-forward as a workaround until this is fully fleshed out.
@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
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
@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
@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.
Created an issue on problems with minikube tunnel
on WSL 2 using minikube v1.14.0, see #9482
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.
@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.
@Aut0R3V Hi, I never updated and sent a PR because I could never get it working.
@cheslijones thanks for the reply. I also tried solving it using that documentation but I'm getting some issues.
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).
@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:
~/
and not the Windows file system /mnt/c/
.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
).kubectl
using the Linux instructions.minikube
using the Linux instructions.skaffold
(not necessary but that is what I use to build the docker
images and deploy to minikube
)... install using the Linux instructions.minikube
profile with: minikube start --driver=docker
.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
.skaffold dev
.minikube tunnel
in a separate terminal.sudo
and it will say something about needing to access privileged port, or something to that effect.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.
@cheslijones I will update your answer about my working solution with services exposed as nodePort and ingress.
host
is host: 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
@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 ?
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
@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?
Any news yet on whether this might be fixed with Windows 11?
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:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle stale
/lifecycle rotten
/close
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
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?
There are no other
minikube
driver choices for WSL2. You can't have virtualization in WSL2 so scratchkvm2
,vmware
,hyperv
,virtualbox
, etc.none
doesn't work either. Pretty much just leavesdocker
.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>
And we should have docker running in the background or else it won't work I guess
Trying to use systemd where not available is probably a bug, though: https://github.com/kubernetes/minikube/issues/12276#issuecomment-899780802
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:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle rotten
/close
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle rotten
To get host applications such as Browser, IDE, Postman to connect to services/applications deployed in Minikube via Ingress,
minikube start --driver=docker
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.