Skip to content
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

none: Allow host IP to be settable #2762

Closed
elioengcomp opened this issue Apr 23, 2018 · 17 comments
Closed

none: Allow host IP to be settable #2762

elioengcomp opened this issue Apr 23, 2018 · 17 comments
Labels
area/networking networking issues co/none-driver help wanted Denotes an issue that needs help from a contributor. Must meet "help wanted" guidelines. kind/feature Categorizes issue or PR as related to a new feature. lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. priority/backlog Higher priority than priority/awaiting-more-evidence. r/2019q2 Issue was last reviewed 2019q2

Comments

@elioengcomp
Copy link

elioengcomp commented Apr 23, 2018

Is this a BUG REPORT or FEATURE REQUEST? (choose one): FEATURE REQUEST

Please provide the following details:

Environment:

Minikube version (use minikube version): v0.26.1

  • OS (e.g. from /etc/os-release): Debian GNU/Linux 9 (stretch)
  • VM Driver (e.g. cat ~/.minikube/machines/minikube/config.json | grep DriverName): none
  • ISO version (e.g. cat ~/.minikube/machines/minikube/config.json | grep -i ISO or minikube ssh cat /etc/VERSION):
  • Install tools:
  • Others:

What happened: I'm getting a broken cluster everytime my host IP changes. It looks like the Pods keep trying to reach the host using the old IP. I tried to set the host IP by starting minikube with the following command, but it did not work:

minikube start --vm-driver=none --apiserver-name=localhost --apiserver-ips=127.0.0.1 --extra-config=kubelet.node-ip=127.0.0.1

What you expected to happen: I would like to be able to set the host IP to make my minikube installation survive network changes.

How to reproduce it (as minimally and precisely as possible):

  1. Start a minikube cluster using vm-driver=none
  2. Deploy an application to the cluster (It can be the dashboard)
  3. Stop minikube
  4. Change the host IP address
  5. Restart minikube
  6. Try to access the application.

Output of minikube logs (if applicable):

Anything else do we need to know:

@ntr-808
Copy link

ntr-808 commented Apr 24, 2018

i believe you are supposed to specify a bridge network.
from the readme:

NOTE: Minikube also supports a --vm-driver=none option that runs the Kubernetes components on the host and not in a VM. Docker is required to use this driver but no hypervisor. If you use --vm-driver=none, be sure to specify a bridge network for docker. Otherwise it might change between network restarts, causing loss of connectivity to your cluster.

@elioengcomp
Copy link
Author

@Margh can you provide more details about this?

My daemon.json looks like this:

{
    "bip": "172.17.1.0/16"
}

@ToddMorrill
Copy link

Second the above question. I'm struggling to find clear instructions on how to create a bridge network. The closest thing I can find is this, which doesn't really explain anything or solve the problem.

intelfx added a commit to intelfx/minikube that referenced this issue Jul 25, 2018
I'm not positive on why do we ever need to pick a machine's external IP
for this. Alongside other things, this prohibits using
`minikube --vm-driver=none` on machines without Internet connectivity,
which is stupid.
Fixes kubernetes#3013, kubernetes#2762 and possibly many more similar issues.
intelfx added a commit to intelfx/minikube that referenced this issue Jul 31, 2018
I'm not positive on why do we ever need to pick a machine's external IP
for this. Alongside other things, this prohibits using
`minikube --vm-driver=none` on machines without Internet connectivity,
which is stupid.
Fixes kubernetes#3013, kubernetes#2762 and possibly many more similar issues.
intelfx added a commit to intelfx/minikube that referenced this issue Jul 31, 2018
I'm not positive on why do we ever need to pick a machine's external IP
for this. Alongside other things, this prohibits using
`minikube --vm-driver=none` on machines without Internet connectivity,
which is stupid.
Fixes kubernetes#3013, kubernetes#2762 and possibly many more similar issues.
intelfx added a commit to intelfx/minikube that referenced this issue Jul 31, 2018
I'm not positive on why do we ever need to pick a machine's external IP
for this. Alongside other things, this prohibits using
`minikube --vm-driver=none` on machines without Internet connectivity,
which is stupid.
Fixes kubernetes#3013, kubernetes#2762 and possibly many more similar issues.
intelfx added a commit to intelfx/minikube that referenced this issue Aug 6, 2018
I'm not positive on why do we ever need to pick a machine's external IP
for this. Alongside other things, this prohibits using
`minikube --vm-driver=none` on machines without Internet connectivity,
which is stupid.
Fixes kubernetes#3013, kubernetes#2762 and possibly many more similar issues.
intelfx added a commit to intelfx/minikube that referenced this issue Aug 12, 2018
I'm not positive on why do we ever need to pick a machine's external IP
for this. Alongside other things, this prohibits using
`minikube --vm-driver=none` on machines without Internet connectivity,
which is stupid.
Fixes kubernetes#3013, kubernetes#2762 and possibly many more similar issues.
intelfx added a commit to intelfx/minikube that referenced this issue Aug 13, 2018
I'm not positive on why do we ever need to pick a machine's external IP
for this. Alongside other things, this prohibits using
`minikube --vm-driver=none` on machines without Internet connectivity,
which is stupid.
Fixes kubernetes#3013, kubernetes#2762 and possibly many more similar issues.
intelfx added a commit to intelfx/minikube that referenced this issue Aug 13, 2018
I'm not positive on why do we ever need to pick a machine's external IP
for this. Alongside other things, this prohibits using
`minikube --vm-driver=none` on machines without Internet connectivity,
which is stupid.
Fixes kubernetes#3013, kubernetes#2762 and possibly many more similar issues.
intelfx added a commit to intelfx/minikube that referenced this issue Aug 21, 2018
I'm not positive on why do we ever need to pick a machine's external IP
for this. Alongside other things, this prohibits using
`minikube --vm-driver=none` on machines without Internet connectivity,
which is stupid.
Fixes kubernetes#3013, kubernetes#2762 and possibly many more similar issues.
@fejta-bot
Copy link

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

@k8s-ci-robot k8s-ci-robot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Aug 29, 2018
@intelfx
Copy link

intelfx commented Aug 30, 2018

/remove-lifecycle stale

@k8s-ci-robot k8s-ci-robot removed the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Aug 30, 2018
@tstromberg tstromberg added kind/feature Categorizes issue or PR as related to a new feature. area/networking networking issues co/none-driver labels Sep 19, 2018
@spstarr
Copy link

spstarr commented Sep 20, 2018

--vm-driver=none isn't just for hosts it can be for VMs already created, which is what I use it for.

Except I'd like to be able to choose what interface or IP to bind the cluster.

Right now, I sort of cheat, I use the Docker IP network and route to it from outside the VM, but trying to use Ingress with minikube doesn't work since it won't let me set the IP i want the cluster to be available on (to connect to the pods within the cluster) and Flannel with minikube doesn't work (the example yaml fails for some reason).

@fejta-bot
Copy link

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

@k8s-ci-robot k8s-ci-robot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Dec 19, 2018
intelfx added a commit to intelfx/minikube that referenced this issue Jan 16, 2019
I'm not positive on why do we ever need to pick a machine's external IP
for this. Alongside other things, this prohibits using
`minikube --vm-driver=none` on machines without Internet connectivity,
which is stupid.
Fixes kubernetes#3013, kubernetes#2762 and possibly many more similar issues.
@fejta-bot
Copy link

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten

@k8s-ci-robot k8s-ci-robot added lifecycle/rotten Denotes an issue or PR that has aged beyond stale and will be auto-closed. and removed lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. labels Jan 18, 2019
@tstromberg
Copy link
Contributor

Fixed by intelfx@7535abe

@tstromberg tstromberg added the triage/obsolete Bugs that no longer occur in the latest stable release label Jan 24, 2019
@tstromberg tstromberg reopened this May 22, 2019
@tstromberg
Copy link
Contributor

Looks like I may have been mistaken about this being fixed.

@tstromberg tstromberg changed the title Set host IP for vm-driver=none none: Allow host IP to be settable May 22, 2019
@tstromberg tstromberg added help wanted Denotes an issue that needs help from a contributor. Must meet "help wanted" guidelines. priority/backlog Higher priority than priority/awaiting-more-evidence. and removed lifecycle/rotten Denotes an issue or PR that has aged beyond stale and will be auto-closed. triage/obsolete Bugs that no longer occur in the latest stable release labels May 22, 2019
@tstromberg tstromberg added the r/2019q2 Issue was last reviewed 2019q2 label May 22, 2019
@rodjjo
Copy link

rodjjo commented Jun 18, 2019

minikube start --vm-driver=none --apiserver-name=localhost --apiserver-ips=127.0.0.1 --extra-conf=kubelet.node-ip=127.0.0.1

did you mean --extra-config not --extra-conf ?

@elioengcomp
Copy link
Author

I think so. Just fixed it.

@rodjjo
Copy link

rodjjo commented Jun 18, 2019

@elioengcomp

Mabye you can reuse minikube after ip changes by running:

export CHANGE_MINIKUBE_NONE_USER=true &&  minikube update-context && sudo systemctl restart kubelet && sudo minikube start --vm-driver=none --memory=8192 --kubernetes-version=v1.14.3

^ that does not solve the problem but at least you can still using minikube without reinstalling it.

I updated this comment replacing the command by the one i have tested on my machine.

maybe you have to run minikube stop before running it

@elioengcomp
Copy link
Author

Thanks for the tip @rodjjo. It has been a while since I was working on this. I will give it a try when I have the chance.

@fejta-bot
Copy link

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

@k8s-ci-robot k8s-ci-robot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Sep 16, 2019
@tstromberg
Copy link
Contributor

Closing as there is apparently a workaround.

@raul1991
Copy link

Closing as there is apparently a workaround.

and what is that ? Can you copy that again here ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/networking networking issues co/none-driver help wanted Denotes an issue that needs help from a contributor. Must meet "help wanted" guidelines. kind/feature Categorizes issue or PR as related to a new feature. lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. priority/backlog Higher priority than priority/awaiting-more-evidence. r/2019q2 Issue was last reviewed 2019q2
Projects
None yet
Development

No branches or pull requests

10 participants