Why does Skaffold maintain two tags when building to the local docker daemon?

Question

Asked in a different question:

why does skaffold need two tags to the same image?

Answer 1

During deployment, Skaffold rewrites the image references in the Kubernetes manifests being deployed to ensure that the cluster pulls the the newly-built images and doesn't use stale copies (read about imagePullPolicy and some of the issues that it attempts to address). Skaffold can't just use the computed image tag as many tag conventions do not produce unique tags and the tag can be overwritten by another developer and point to a different image. It's not unusual for a team of devs, or parallel tests, to push images into the same image repository and encounter tag clashes. For example, latest will be overwritten by the next build, and the default gitCommit tagger generates tags like v1.17.1-38-g1c6517887 which uses the most recent version tag and the current commit SHA and so isn't unique across uncommitted source changes.

When pushing to a registry, Skaffold can use the image's digest, the portion after the @ in gcr.io/my-project/image:latest@sha256:xxx. This digest is the hash of the image configuration and layers and uniquely identifies a specific image. A container runtime ignores the tag (latest here) when there is a digest.

When loading an image to a Docker daemon, as happens when deploying to minikube, the Docker daemon does not maintain image digests. So Skaffold instead tags the image with a second tag using a computed digest. It's extremely unlikely that two different images will have the same computed digest, unless they're the same image.

Tags are cheap: they're like symlinks, pointing to an image identifier.