-
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
Allow alternative storage-driver to be selected #7933
Comments
Similar to #7626 |
It is supposed to fallback to not using a preload for such drivers, but to use the regular cache instead. |
I dont think this is wrong, the docker Inside minikube uses overlay storage driver. @steghio could you please do this:
I believe since we install the docker inside minikube oursleves we install it with overlay, so it is not pulling the wrong one. |
@steghio when you modify the configuration, do u use modify the docker on your host or the docker inside minikube? ps: not related to this issue but I am curious why do you use VFS ?
|
Hello @medyagh
I have a fresh docker installation and I modified it via the Specifically I modified the docker folder location and the storage driver being used as mentioned earlier. I installed minikube as DEB package from https://minikube.sigs.k8s.io/docs/start/ - I do not modify anything else, in my home folder there are no When I run the Then, the startup process gets stuck at the SSH/TCP connection with this setup, here is the trimmed output (replaced repeating entries with [...]):
Also:
and:
Yes I saw that too, but if the docker folder is on a NTFS filesystem, it appears that is the only usable storage driver as the others do not list it as supported (overlay for sure does not work, I get a clear error if I try it). I was testing on NTFS in order to share data with my dual boot setup with Windows. Note the very important thing here is this: if I leave my docker folder on the standard location
And after I successfully run
And:
As mentioned, the only difference in my setup is the daemon.json file specifying I wish to use a different location and storage driver for my docker. Lastly, other containers I have can successfully run in both configurations (local EXT4 filesystem and NTFS filesystem). |
PR's welcome for this. Is it possible that setting In the mean-time, using |
I think something goes wrong in the KIC boot, when running on the The main issue here is NTFS, I don't think overlayfs accepts ntfs as the underlying layer... Tested booting minikube on vfs, and that goes OK - just is slow, and eats lots of disk After booting, the docker storage used is 23G (for the kicbase, and for the docker images) |
Same issue with
For some reason, minikube is hardcoding the driver.
Without that, it will default to overlay2 but fall back to aufs (or vfs). I think it comes from that ancient kubernetes example file for docker. https://kubernetes.io/docs/setup/production-environment/container-runtimes/#docker
Which was created before overlayfs was the default, docker < 18.09:
Can argue about json-file vs journald logs, some other day. :-) https://docs.docker.com/config/containers/logging/configure/ As usual (cgroup driver), docker defaults to not using systemd. https://www.projectatomic.io/blog/2015/04/logging-docker-container-output-to-journald/ |
Issues go stale after 90d of inactivity. If this issue is safe to close now please do so with Send feedback to sig-testing, kubernetes/test-infra and/or fejta. |
Stale issues rot after 30d of inactivity. If this issue is safe to close now please do so with Send feedback to sig-testing, kubernetes/test-infra and/or fejta. |
Hi everyone, I have same issue.
|
Steps to reproduce the issue:
Host is Ubuntu 20.04 using ext4 filesystem, with additional mounted NTFS partition.
Docker info:
Client: Docker Engine - Community
Version: 19.03.8
API version: 1.40
Go version: go1.12.17
Git commit: afacb8b7f0
Built: Wed Mar 11 01:25:46 2020
OS/Arch: linux/amd64
Experimental: false
Server: Docker Engine - Community
Engine:
Version: 19.03.8
API version: 1.40 (minimum version 1.12)
Go version: go1.12.17
Git commit: afacb8b7f0
Built: Wed Mar 11 01:24:19 2020
OS/Arch: linux/amd64
Experimental: false
containerd:
Version: 1.2.13
GitCommit: 7ad184331fa3e55e52b890ea95e65ba581ae3429
runc:
Version: 1.0.0-rc10
GitCommit: dc9208a3303feef5b3839f4323d9beb36df0a9dd
docker-init:
Version: 0.18.0
GitCommit: fec3683
minikube start --driver=docker
Full output of failed command:
The command per se does not fail, but it pulls the wrong tarball:
preloaded-images-k8s-v2-v1.18.0-docker-overlay2-amd64.tar.lz4
which is incompatible with the target NTFS filesystem. There is no possibility to specify a different storage driver via additional parameters and also it appears no image with different storage driver exists at all under the pull location: https://storage.googleapis.com/minikube-preloaded-volume-tarballs/
The interesting part is that no error is thrown during startup, but the process will hang towards the end outputting multiple times lines such as:
Error dialing TCP: ssh: handshake failed: read tcp 127.0.0.1:51590->127.0.0.1:39697: read: connection reset by peer
it will then leave the container running, but inaccessible.
Reverting back the docker configuration to use local ext4 filesystem, for example /var/lib/docker makes the process complete successfully and lets the cluster start correctly.
Would it be possible to provide preloaded tarballs that do NOT rely on overlay storage driver? Alternatively, would it be possible to provide configuration options to specify the desired storage driver and let the local process create the correct folders at startup?
Full output of
minikube start
command used, if not already included:Optional: Full output of
minikube logs
command:The text was updated successfully, but these errors were encountered: