Normally, the docker prune commands don't delete Kubernetes control plane images that Docker Desktop pulls as part of the Kubernetes setup. But, when you select the new containerd storage option in General settings, the prune commands will delete or de-tag control plane images.
As far as I can tell, Docker Desktop re-pulls these images after restart and doesn't lose the etcd data, so I don't think there's a long-lasting effect of including control plane images in the prune, but I feel it's a confusing and inconsistent behavior.
Reproduce
Enable Kubernetes in default Docker Desktop setup
Run docker image prune --all --force and it will not touch the DD internal K8s images for control plane (but it will delete any image w/o a container attached)
Enable "Use containerd for pulling and storing images" in General settings
Wait for Kubernetes to reinstall in new image store
Run docker image prune --all --force and it will delete some layers and de-tag most K8s control plane images
Expected behavior
The image prune command would behave the same in either dockerd or containerd storage mode.
docker version
Client:
Version: 26.1.4
API version: 1.45
Go version: go1.21.11
Git commit: 5650f9b
Built: Wed Jun 5 11:26:02 2024
OS/Arch: darwin/arm64
Context: desktop-linux
Server: Docker Desktop 4.31.0 (153195)
Engine:
Version: 26.1.4
API version: 1.45 (minimum version 1.24)
Go version: go1.21.11
Git commit: de5c9cf
Built: Wed Jun 5 11:29:12 2024
OS/Arch: linux/arm64
Experimental: false
containerd:
Version: 1.6.33
GitCommit: d2d58213f83a351ca8f528a95fbd145f5654e957
runc:
Version: 1.1.12
GitCommit: v1.1.12-0-g51d5e94
docker-init:
Version: 0.19.0
GitCommit: de40ad0
docker info
Client:
Version: 26.1.4
Context: desktop-linux
Debug Mode: false
Plugins:
buildx: Docker Buildx (Docker Inc.)
Version: v0.14.1-desktop.1
Path: /Users/bret/.docker/cli-plugins/docker-buildx
compose: Docker Compose (Docker Inc.)
Version: v2.27.1-desktop.1
Path: /Users/bret/.docker/cli-plugins/docker-compose
debug: Get a shell into any image or container (Docker Inc.)
Version: 0.0.32
Path: /Users/bret/.docker/cli-plugins/docker-debug
dev: Docker Dev Environments (Docker Inc.)
Version: v0.1.2
Path: /Users/bret/.docker/cli-plugins/docker-dev
extension: Manages Docker extensions (Docker Inc.)
Version: v0.2.24
Path: /Users/bret/.docker/cli-plugins/docker-extension
feedback: Provide feedback, right in your terminal! (Docker Inc.)
Version: v1.0.5
Path: /Users/bret/.docker/cli-plugins/docker-feedback
init: Creates Docker-related starter files for your project (Docker Inc.)
Version: v1.2.0
Path: /Users/bret/.docker/cli-plugins/docker-init
sbom: View the packaged-based Software Bill Of Materials (SBOM) for an image (Anchore Inc.)
Version: 0.6.0
Path: /Users/bret/.docker/cli-plugins/docker-sbom
scout: Docker Scout (Docker Inc.)
Version: v1.9.3
Path: /Users/bret/.docker/cli-plugins/docker-scout
Server:
Containers: 36
Running: 20
Paused: 0
Stopped: 16
Images: 10
Server Version: 26.1.4
Storage Driver: overlayfs
driver-type: io.containerd.snapshotter.v1
Logging Driver: json-file
Cgroup Driver: cgroupfs
Cgroup Version: 2
Plugins:
Volume: local
Network: bridge host ipvlan macvlan null overlay
Log: awslogs fluentd gcplogs gelf journald json-file local splunk syslog
Swarm: inactive
Runtimes: runc io.containerd.runc.v2
Default Runtime: runc
Init Binary: docker-init
containerd version: d2d58213f83a351ca8f528a95fbd145f5654e957
runc version: v1.1.12-0-g51d5e94
init version: de40ad0
Security Options:
seccomp
Profile: unconfined
cgroupns
Kernel Version: 6.6.31-linuxkit
Operating System: Docker Desktop
OSType: linux
Architecture: aarch64
CPUs: 8
Total Memory: 11.92GiB
Name: docker-desktop
ID: 0b63fa3e-377e-42a6-84d2-c19b4822d62e
Docker Root Dir: /var/lib/docker
Debug Mode: false
HTTP Proxy: http.docker.internal:3128
HTTPS Proxy: http.docker.internal:3128
No Proxy: hubproxy.docker.internal
Labels:
com.docker.desktop.address=unix:///Users/bret/Library/Containers/com.docker.docker/Data/docker-cli.sock
Experimental: false
Insecure Registries:
hubproxy.docker.internal:5555
127.0.0.0/8
Live Restore Enabled: false
WARNING: daemon is not using the default seccomp profile
Description
Normally, the docker prune commands don't delete Kubernetes control plane images that Docker Desktop pulls as part of the Kubernetes setup. But, when you select the new containerd storage option in General settings, the prune commands will delete or de-tag control plane images.
As far as I can tell, Docker Desktop re-pulls these images after restart and doesn't lose the etcd data, so I don't think there's a long-lasting effect of including control plane images in the prune, but I feel it's a confusing and inconsistent behavior.
Reproduce
docker image prune --all --force
and it will not touch the DD internal K8s images for control plane (but it will delete any image w/o a container attached)docker image prune --all --force
and it will delete some layers and de-tag most K8s control plane imagesExpected behavior
The image prune command would behave the same in either dockerd or containerd storage mode.
docker version
docker info
Diagnostics ID
93D7D68F-14B0-4AD0-86C7-3F4473A9C98B/20240625015610
Additional Info
No response