One of the key differentiator of Openshift compared to Kubernetes is the added ImageStream object type.

What is an ImageStream?

It basically acts as a pointer to a container image that exists somewhere else. It adds another layer of abstraction. You can then refer to that imagestream object in your buildconfig, deploymentconfig, or deployment object. If we need to change the container image the imagestream is pointing to, we just need to update it and that new image is automatically used in the objects referring to the imagestream.

Automation magic of ImageStream

However, the true beauty of using the ImageStream object is the automation we can build on top of it. For the tag the ImageStream is tracking, you need to set it to periodically check for new image. You can see how to do it here

BuildConfig

We can configure an ImageStream to regularly check for new image tag updates of the remote container image. For example, it is common to have a container image tagged with the OpenJDK version (e.g 17) updated regularly with CVE fixes. The ImageStream can then trigger any BuildConfigs using that openjdk container image with tag “17” as the base layer to build a new application image. This automates rebuild of images whenever the base image is updated.

This is done by adding a trigger in your buildconfig:

type: "ImageChange"
imageChange: {}

The imageChange is left empty to trigger a new buildconfig when the imagestream defined as the “base” in the BuildConfig is updated.

More information can be found here

Deployment

The default Kubernetes Deployment object has no trigger section. However, Openshift allows you to redeploy apps on new ImageStream tag if you add an annotation in the deployment object. More information here

Note that the DeploymentConfig object does has a trigger section where you can redeploy if the ImageStream tag is updated. However as of Openshift 4.14, the DeploymentConfig object is now deprecated.