Provide feedback at the survey
- Override or set the Name and Tag for Container Images
It may be useful to define the tags or digests of container images which are used across many Workloads.
Container image tags and digests are used to refer to a specific version or instance of a container
image - e.g. for the
nginx container image you might use the tag
- Update the container image name or tag for multiple Workloads at once
- Increase visibility of the versions of container images being used within the project
- Set the image tag from external sources - such as environment variables
- Copy or Fork an existing Project and change the Image Tag for a container
- Change the registry used for an image
See Bases and Variations for more details on Copying Projects.
It is possible to set image tags for container images through
kustomization.yaml using the
images field. When
specified, Apply will override the images whose image name matches
name with a new
|Field||Description||Example Field||Example Result|
||Match images with this image name||
||Override the image tag or digest for images whose image name matches
||Override the image name for images whose image name matches
images in the
kustomization.yaml to update the container
Apply will set the
nginx image to have the tag
1.8.0 - e.g.
change the image name to
This will set the name and tag for all images matching the name.
Input: The kustomization.yaml and deployment.yaml files
# kustomization.yaml apiVersion: kustomize.config.k8s.io/v1beta1 kind: Kustomization images: - name: nginx # match images with this name newTag: 1.8.0 # override the tag newName: nginx-special # override the name resources: - deployment.yaml
# deployment.yaml apiVersion: apps/v1 kind: Deployment metadata: name: nginx-deployment labels: app: nginx spec: selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx
Applied: The Resource that is Applied to the cluster
apiVersion: apps/v1 kind: Deployment metadata: labels: app: nginx name: nginx-deployment spec: selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: # The image has been changed - image: nginx-special:1.8.0 name: nginx
Setting a Name
The name for an image may be set by specifying
newName and the name of the old container image.
# kustomization.yaml apiVersion: kustomize.config.k8s.io/v1beta1 kind: Kustomization images: - name: mycontainerregistry/myimage newName: differentregistry/myimage
Setting a Tag
The tag for an image may be set by specifying
newTag and the name of the container image.
# kustomization.yaml apiVersion: kustomize.config.k8s.io/v1beta1 kind: Kustomization images: - name: mycontainerregistry/myimage newTag: v1
Setting a Digest
The digest for an image may be set by specifying
digest and the name of the container image.
# kustomization.yaml apiVersion: kustomize.config.k8s.io/v1beta1 kind: Kustomization images: - name: alpine digest: sha256:24a0c4b4a4c0eb97a1aabb8e29f18e917d05abfe1b7a7c07857230879ce7d3d3
Setting a Tag from the latest commit SHA
A common CI/CD pattern is to tag container images with the git commit SHA of source code. e.g. if
the image name is
foo and an image was built for the source code at commit
then the container image would be
A simple way to push an image that was just built without manually updating the image tags is to
download the kustomize standalone tool and run
kustomize edit set image command to update the tags for you.
Example: Set the latest git commit SHA as the image tag for
kustomize edit set image foo:$(git log -n 1 --pretty=format:"%H") kubectl apply -f .
Setting a Tag from an Environment Variable
It is also possible to set a Tag from an environment variable using the same technique for setting from a commit SHA.
Example: Set the tag for the
foo image to the value in the environment variable
kustomize edit set image foo:$FOO_IMAGE_TAG kubectl apply -f .
kustomization.yaml changes may be committed back to git so that they
can be audited. When committing the image tag updates that have already
been pushed by a CI/CD system, be careful not to trigger new builds +
deployments for these changes.