An imagestream and its associated tags provide an abstraction for referencing
container images from within OpenShift Dedicated. The imagestream and its tags
allow you to see what images are available and ensure that you are using the
specific image you need even if the image in the repository changes.
Imagestreams do not contain actual image data, but present a single virtual
view of related images, similar to an image repository.
You can configure Builds and Deployments to watch an imagestream for
notifications when new images are added and react by performing a Build or
For example, if a Deployment is using a certain image and a new version of that
image is created, a Deployment could be automatically performed to pick up the
new version of the image.
However, if the imagestreamtag used by the Deployment or Build is not updated,
then even if the container image in the container image registry is updated, the
Build or Deployment will continue using the previous, presumably known good
The source images can be stored in any of the following:
OpenShift Dedicated’s integrated registry.
An external registry, for example
Other imagestreams in the OpenShift Dedicated cluster.
When you define an object that references an imagestreamtag (such as a Build
or Deployment configuration), you point to an imagestreamtag, not the Docker
repository. When you Build or Deploy your application, OpenShift Dedicated queries
the Docker repository using the imagestreamtag to locate the associated ID of
the image and uses that exact image.
The imagestream metadata is stored in the etcd instance along with other
Using imagestreams has several significant benefits:
You can tag, rollback a tag, and quickly deal with images, without having to
re-push using the command line.
You can trigger Builds and Deployments when a new image is pushed to the
registry. Also, OpenShift Dedicated has generic triggers for other resources, such
as Kubernetes objects.
You can mark a tag for periodic re-import. If the source image has changed, that
change is picked up and reflected in the imagestream, which triggers the Build
and/or Deployment flow, depending upon the Build or Deployment configuration.
You can share images using fine-grained access control and quickly distribute
images across your teams.
If the source image changes, the imagestreamtag will still point to a
known-good version of the image, ensuring that your application will not break
You can configure security around who can view and use the images through
permissions on the imagestream objects.
Users that lack permission to read or list images on the cluster level can still
retrieve the images tagged in a project using imagestreams.