Disk space leak caused by "minikube image load"

[yankay]

What Happened?

Disk space leak caused by "minikube image load". Reference: #21103 (comment)

The images are stored in ~/.minikube/cache/images. It appears the space is not being cleaned up after executing the minikube image load command.

This may lead to disk space exhaustion.

Attach the log file

None

Operating System

None

Driver

None

[nirs]

Cleanup after minikube image load is not efficient, since user may want to load the same image multiple times to different clusters:

minikube image load docker.io/library/alpine:latest -p c1                                
minikube image load docker.io/library/alpine:latest -p c2        

Caching images on the host makes sense since it saves the time pull the images, or allow using minikube in an environment without network access.

If users want to avoid the caching, they can use:

podman save docker.io/library/alpine:latest -o tmp
minikube image load tmp -p c1                                
minikube image load tmp -p c2        
rm tmp

This is also 10 times faster:

% cat load-image.sh 
minikube image load docker.io/library/alpine:latest -p c1
minikube image load docker.io/library/alpine:latest -p c2

% cat load-tar.sh 
podman save docker.io/library/alpine:latest -o tmp
minikube image load tmp -p c1
minikube image load tmp -p c2
rm tmp

% time sh load-image.sh
sh load-image.sh  0.14s user 0.14s system 3% cpu 7.505 total

% time sh load-tar.sh  
sh load-tar.sh  0.11s user 0.10s system 34% cpu 0.613 total

With #21103 the difference is much smaller.

But loading an image is much simpler, so it makes sense to support it.

I think documenting that loaded images are cached in ~/.minikube/cache/images is good enough.

We have minikube cache command that seems to be deprecated and not working. Maybe we should revive it and add an option to purge the cache.

[nirs]

Turns out that we never use the cached image - loading an image twice pulls it from the registry again: #21144

[afbjorklund]

The cache folder is not a leak, but it does need to be cleaned up manually.

Also it is in the wrong* location, but that is a known minikube/machine issue...

* most OS (or XDG) have a dedicated cache directory

[nirs]

The cache folder is not a leak, but it does need to be cleaned up manually.

I think the best way would to document that image load copies the image to the cache directory, so users can clean up if needed.

Also it is in the wrong* location, but that is a known minikube/machine issue...

• most OS (or XDG) have a dedicated cache directory

This is another issue, but I'm not sure that using ~/.cache or ~/Library/Caches is better. Having everything under .minkkube makes it much easier to manage and document. The same documentation works on any platform.

If we switch to the platform cache directory we ned to add a command to clean the cache since most users do not know what is the cache directory and which one we use (XDG? macOS?).

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

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

/lifecycle stale