inaccurate warning with Docker Desktop containerd integration

[nicks]

What Happened?

1. Start Docker Desktop
2. Go to settings -> features in development, and enable containerd integration
3. Start minikube with:

minikube start --driver=docker

Expected result:
No warnings

Actual result:

❗  docker is currently using the stargz storage driver, consider switching to overlay2 for better performance

Not sure why minikube dislikes the stargz storage driver? And typically, users wouldn't want to change the driver in docker desktop from stargz to overlay2?

Attach the log file

n/a

Operating System

macOS (Default)

Driver

Docker

[rumpl]

Hi all, I work on the containerd integration and we are setting stargz as the default in docker desktop which uses overlay for normal images.

Users on linux that enable the containerd image store would get overlay as the default containerd snapshotter and its name in that case is “overlayfs”.

[afbjorklund]

The warning is much older than the stargz changes, which should be added to the check (or remove it).

[rumpl]

IMO the best bet is to remove the check. There are many snapshotters and more to come, minikube can’t know them all.

[afbjorklund]

@rumpl : the main reason is for the preload, I'm not sure what the other "better performance" refers to...

commit 8ec8d1c

• autoset --preload=false when storage driver is not overlay #7626

It needs to match, since it tries to archive /var/lib/docker as is. Maybe could add some more preloads ?

---

For the generic case, we might want to gather all of the "cache" (save) images into one single .tar.lz4 file ?

But I'm not sure what the benchmark is, with multiple .tar.gz versus one big .tar.lz4 containing all images.

[afbjorklund]

Users on linux that enable the containerd image store would get overlay as the default containerd snapshotter and its name in that case is “overlayfs”.

The containerd check was also using the docker check, so separated them:

• Verify containerd storage separately from docker #16972

[afbjorklund]

I think it was checking the wrong docker anyway, so now the preload is disabled for no particular reason...
The original issue was when using the "none" driver, not when using the "docker" driver

[spowelljr]

I think it was checking the wrong docker anyway, so now the preload is disabled for no particular reason... The original issue was when using the "none" driver, not when using the "docker" driver

I think this is contributing to the problem in #16425, there is obviously something wrong with preload=false and kubectl not being present on the machine, but the preload=false is being set when it seems like it shouldn't be, the cluster starts fine with the preload when using the stargz storage driver.