When using Docker in local development, a common command is docker pullto pull the image to the local. As shown in the following code:
docker pull nginxThe above code contains only nginx, which is the simplest form. A full name can consist of 4 parts:
| component | Defaults |
|---|---|
| registry | docker.io |
| group | library |
| Image name (name) | |
| ID or tag (tag) | latest |
Except for the image name, other parts can be omitted. When omitted, the default value will be used. For example, bitnami/postgresql:11 only the registry is omitted, while registry.access.redhat.com/ubi8/ubi-minimal:8.5 all components are provided. nginx Actually equivalent to docker.io/library/nginx:latest.
mirror tag
Most people are not unfamiliar with the label of mirror image. Images generally use semantic version numbers as tags. In addition to tags, each image has a unique ID. This ID is actually a digest of the image's configuration file. Tags can point to different image IDs. This usage pattern can be compared to commit hashes and tags in Git. In Git, each commit has a unique hash as its ID, and tags point to different hash values. The commit hash corresponding to the label can be changed.
Container image IDs and tags have the same characteristics. The image ID pointed to by the same label may change. This is latest especially true for labels. Each time an image is pushed, if the default latest tag is used, latest the tag will be moved to the new image ID. Even with SemVer tags, for example 1.2.0, the same tag may point to different image IDs. As a publisher of images, such situations should be avoided. When a version is released and the corresponding image tag is generated, it should not be released again with the same tag.
Theoretically speaking, using image IDs is more stable than tags when deploying applications, because image IDs are the only ones that remain constant. However, the readability of the image ID is too poor. In practice, tags are generally still used. The usual tag adopts the semantic version number and adds the build number (Build ID) provided by the continuous integration server as a suffix. For example, 1.2.0-b123 to indicate the first build 1.2.0 of a version 123 .
When pulling an image, you can use either a tag or an image ID.
docker pull nginx:1.21.4
docker pull nginx@sha256:2f14a471f2c2819a3faf88b72f56a0372ff5af4cb42ec45aab00c03ca5c9989f
Kubernetes image pull strategy
On Kubernetes, imagePullPolicy properties declared by containers can specify image pull policies. This policy has 3 optional values:
IfNotPresent: Pull when the mirror is not available locally.Always: Pulled every time the container is started.Never: Never pull.
When not specified , the default value is imagePullPolicy if the image tag is not specified, or if the tag is latest; otherwise the default value is .imagePullPolicyAlwaysIfNotPresent
Since the actual image ID specified by the image tag may change, when a new Pod is started, the containers in the new Pod may use the new image. For example, a container image is labeled 1.0.0and already has a Pod running. Then publish the new image again with the same tag. When a new Pod is created due to horizontal scaling, if imagePullPolicy the value is Always, the new Pod uses the new image, even if the label has not changed. Mixing old and new versions can cause problems.
To avoid this, mirror IDs can be used. You can use the admission controller of Kubernetes to modify the Pod declaration, and replace the label of the container image with the image ID. This avoids inconsistencies due to label modifications.
When running on Kubernetes, the status of the Pod can show the image ID used by the container, which is imageID the field in the code below.
containerStatuses:
- containerID: containerd://119cd2bbd8670aeef1a515df4af429aff405c1bff48b8370d503efe577b5a505
image: docker.io/rancher/coredns-coredns:1.8.3
imageID: docker.io/rancher/coredns-coredns@sha256:9d4f5d7968c432fbd4123f397a2d6ab666fd63d13d510d9728d717c3e002dc72