Introduction

MicroK8s stores container images through its container runtime, which means removing an image from the "image cache" is really a container-runtime image management task. In practice, the usual workflow is to list the cached images with ctr, remove the ones you no longer need, and make sure no current workload still depends on them.

List the Cached Images First

Before deleting anything, inspect what is actually present.

microk8s ctr images ls

On some setups you may also see the runtime namespace form used explicitly:

microk8s ctr -n k8s.io images ls

This gives you the full image reference you need for removal, including registry and tag.

Remove a Specific Cached Image

Once you know the exact reference, remove it with ctr.

microk8s ctr images rm docker.io/library/nginx:latest

If your setup requires the Kubernetes namespace explicitly, use:

microk8s ctr -n k8s.io images rm docker.io/library/nginx:latest

The command removes the image from the local runtime store. If Kubernetes later needs that image again and a pod still references it, the runtime may pull it back automatically.

Check Whether a Workload Still Uses the Image

Before removing cached images aggressively, inspect your running workloads.

microk8s kubectl get pods -A -o wide
microk8s kubectl describe pod <pod-name> -n <namespace>

If a deployment still references the image, deleting the cache may only free space temporarily, because the image will be fetched again on the next schedule or restart.

Understand the Difference Between Cache and Registry

Deleting a cached image from MicroK8s does not delete it from an external registry, and it does not necessarily delete it from a built-in registry or another node.

That distinction matters in multi-node or CI-driven environments. You may have removed the local runtime copy while leaving the actual source image available elsewhere, which is often exactly what you want.

Use Cleanup Deliberately

A good cleanup pattern is:

1. list images
2. confirm what is no longer needed
3. remove by exact reference
4. verify disk usage afterward

For example:

1microk8s ctr images ls
2df -h
3microk8s ctr images rm myregistry.local/myapp:v1
4microk8s ctr images ls

This makes the result visible instead of treating cleanup as a blind deletion step.

If the Image Was Imported Repeatedly

Images added through docker save and microk8s ctr image import or similar workflows can accumulate stale tags. Removing the runtime image is still the right fix, but you should also review the import process so the same outdated artifact is not reintroduced automatically.

Operationally, image cleanup is often a symptom of a broader workflow issue, such as many one-off tags or unbounded local testing imports.

Common Pitfalls

A common mistake is deleting an image without checking whether a running deployment still references it. The image may simply reappear later.

Another is assuming that removing it from MicroK8s also removes it from the source registry. It does not.

Developers also sometimes delete by a shortened name when the runtime really needs the exact full reference. Listing first avoids that confusion.

Summary

• MicroK8s image-cache cleanup is usually done through microk8s ctr images commands.
• List images first and remove them by exact reference.
• Check whether current workloads still depend on the image before deleting it.
• Removing a local cached image does not delete it from a registry.
• If images keep coming back, inspect the deployment or import workflow that reintroduces them.