whats the difference - docker images vs openshift imagestreams?

Question

Could someone explain what is openshift imagestream and how it differs from the regular docker image.

I have gone through this (Understanding containers, images, and imagestreams) document but it does not explain much about imagestreams.

I understand that docker images are a blueprint to create containers. Just wondering that a imagesteam is??

Answer 1

Like a lot of (all?) kinds in Kubernetes, an ImageStream is an abstraction. If you can imagine a Pod being an abstraction of the idea of a running container(s), you could imagine an ImageStream being an abstraction of the idea of a repository in an image registry (such as quay.io, or the internal container registry in an OpenShift cluster).

Here's an example of an actual repository in an image registry, where you can see that it contains a list of tags corresponding to different versions of the image.

Here's an example of an ImageStream, as represented in the OpenShift web console. You can see that it contains a list of tags, just like the previous example of a repository in an external registry.

Here you can see that the ImageStreamTags actually point to different repositories, such as rhscl/python-27-rhel7, and ubi8/python-38, in the registry. There's even an example of an ImageStreamTag pointing to another ImageStreamTag at the bottom of the list. So it's not exactly a 1:1 mapping to an image registry, it's kind of a higher level abstraction.

As an example of when you might choose to use one, imagine you want to run your Python app in your OpenShift cluster. You could have a BuildConfig that knows how to build your image, by taking your source code from your Git repository, building it and layering it on top of a Python 3.8 base image. Then when it's built, you want this new version to replace the running version in the cluster.

There are a couple of places that you could benefit from ImageStreams here:

1. If the base Python 3.8 image referenced in your BuildConfig is an ImageStreamTag (such as python:3.8 in the above example picture) rather than an image tag directly in a repo in a registry; then you could have periodic updates to the ImageStreamTag, and if the base image in the repo has been updated, it can trigger a new build of your app image.

2. If your build outputs to an ImageStreamTag that's referenced in your Deployment, then your Deployment can be automatically (or not) updated to roll out the new version of your app.

3. If you wanted to change the base Python 3.8 image to point to a different image (such as from a different vendor in a different registry, or your own custom one) then you just need to update the ImageStreamTag in the ImageStream which can lead to a rebuild of your app image (and any other builds that you have for other images that reference the ImageStreamTag), and again, a new roll out of your app (and any other apps from other such builds).

^This is just one example of how you might make use of an ImageStream, and is not meant to be exhaustive.