After referring to a lot of documents it seems they're OK and no need to fix them.
Running a skaffold build
command triggers an image build, which results in an image with two tags
;
One with the most recent git tag or git commit (e.g. my-app:ae7926d), and as the image isn't pushed to a container registry, a tag which uses the 64 character ID of the image.
Skaffold is big on image immutability, and the latter tag
is a content addressable reference to the image in the local cache. If it had been pushed to a registry, the immutable reference would be the image's digest instead.
This ensures we only use the image Skaffold has built, and not a nefarious image masquerading as one and the same
.
As well as providing flexibility on the method of build that we mentioned earlier (i.e. Docker, Jib and so on), Skaffold can accommodate different locations for performing image builds. They can be performed locally, inside a Kubernetes cluster (using Kaniko), or remotely using (unsurprisingly) Google Cloud Build.
Please go through Developing for Kubernetes with Skaffold (Building images) for more information.
Also see the similar SO which is clearly explained about Why does Skaffold maintain two tags when building to the local docker daemon?
Tags are cheap: they're like symlinks, pointing to an image identifier.
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.