minikube start fails in docker-from-docker context #13950
Comments
|
The current setup only supports tcp or ssh in the DOCKER_HOST, it doesn't support the scenario where the socket is tunneled or mounted from another machine. Possibly there could be a way (env var?) to pass the remote host, even when using a Unix socket. Before assuming it is publishing at localhost |
This is what I'm after; I believe I should be able to resolve the remote host both from the context that I'm running |
afbjorklund
added
kind/improvement
|
Something else looks broken on that docker host: Looks like bind mounts aren't working, in your setup.
Since this will try to find the file on the docker host, and fails. Docker falls back to just creating an empty dir, and mounting that. Should look for a remote host, and skip preload in that case.
EDIT: The cache will still work, since the load is done by the client It would be possible to do a similar workaround, also for the preload. |
|
Thought I'd add a little extra evidence here. We're noticing something strange when bind mounting our docker.sock file in different ways within our vscode devcontainer (I don't believe the issue is one with vscode's devcontainer setup, just adding that the below is configuration from one of our devcontainer.json files) vs The former causes Minikube to not start up successfully (with a host timeout error I believe) and leverages the docker --mounts flag under the hood. For the latter, Minikube does indeed start successfully when we manually use the I haven't tested taking the vscode abstraction out of the picture, but I imagine we would see the same thing. Docker calls out some subtle differences between the two, but I haven't noticed any differences between the mounts from one example to the other. From the Docker documentation:
If I can provider further information, let me know. We would really like to use the mounts section for vscode devcontainers for bind mounting our docker socket as it gets around some annoying permissions issues and the --mount flag is recommended over --volume by Docker. |
|
The current code doesn't know about remote servers with local sockets, it assumes that remote servers use tcp and local servers use unix... It should probably have a Boolean to override, similar to allowing both docker engine and docker desktop (on Linux, that is) |
|
For the use case of development containers, we try to avoid the docker-in-docker situation and instead just install the docker cli and bind mount the Uses cases and specifics aside, minikube successfully starts within a devcontainer that uses |
|
interestingly I didn't realize I had a trailing slash on my docker.sock --volume mount (definitely work)... when I removed that trailing slash it stopped working so this works: but this does not: |
|
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 |
k8s-ci-robot
added
the
lifecycle/stale
|
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 |
k8s-ci-robot
added
lifecycle/rotten
|
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:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /close not-planned |
|
@k8s-triage-robot: Closing this issue, marking it as "Not Planned". In response to this:
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. |
|
@B1tVect0r did you find a solution? |
@afbjorklund this issue was closed but we don't have a solution :( |
|
My solution is:
but you can use NodePort as well |
What Happened?
Running
minikube start --driver=dockerfrom inside a container that has the host docker socket mounted (i.e., Docker-from-Docker setup) fails to complete. The Docker container starts properly and is visible from both the host and the container but theminikube startprocess fails to proceed as it seems to be hard-coded to dial127.0.0.1:{minikube container port}for some other post-container-start process. I've tried fiddling with all of the IP-related options for theminikube startcommand that I can find to no avail. Is there a way to do this that I'm missing?Attach the log file
Operating System
Other
Driver
Docker
The text was updated successfully, but these errors were encountered: