<p>Could someone explain what is openshift <strong>imagestream</strong> and how it differs from the regular docker image.</p>
<p>I have gone through this (<a href="https://docs.openshift.com/container-platform/4.1/openshift_images/images-understand.html" rel="nofollow noreferrer">Understanding containers, images, and imagestreams</a>) document but it does not explain much about imagestreams.</p>
<p>I understand that docker images are a blueprint to create containers. Just wondering that a imagesteam is??</p>

<p>Like a lot of (all?) kinds in Kubernetes, an <code>ImageStream</code> is an abstraction. If you can imagine a <code>Pod</code> being an abstraction of the idea of a running container(s), you could imagine an <code>ImageStream</code> 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).</p>
<p>Here's an example of <a href="https://quay.io/repository/keycloak/keycloak?tab=tags" rel="noreferrer">an actual repository in an image registry</a>, where you can see that it contains a list of tags corresponding to different versions of the image.
<a href="https://i.stack.imgur.com/uBaG9.png" rel="noreferrer"><img src="https://i.stack.imgur.com/uBaG9.png" alt="enter image description here" /></a></p>
<p>Here's an example of an <code>ImageStream</code>, 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.
<a href="https://i.stack.imgur.com/8VgVO.png" rel="noreferrer"><img src="https://i.stack.imgur.com/8VgVO.png" alt="enter image description here" /></a></p>
<p>Here you can see that the <code>ImageStreamTags</code> actually point to different repositories, such as <code>rhscl/python-27-rhel7</code>, and <code>ubi8/python-38</code>, in the registry. There's even an example of an <code>ImageStreamTag</code> pointing  to another <code>ImageStreamTag</code> 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.</p>
<p>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 <code>BuildConfig</code> 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.</p>
<p>There are a couple of places that you could benefit from <code>ImageStreams</code> here:</p>
<ol>
<li><p>If the base Python 3.8 image referenced in your <code>BuildConfig</code> is an <code>ImageStreamTag</code> (such as <code>python:3.8</code> 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 <code>ImageStreamTag</code>, and if the base image in the repo has been updated, it can trigger a new build of your app image.</p>
</li>
<li><p>If your build outputs to an <code>ImageStreamTag</code> that's referenced in your <code>Deployment</code>, then your <code>Deployment</code> can be automatically (or not) updated to roll out the new version of your app.</p>
</li>
<li><p>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 <code>ImageStreamTag</code> in the <code>ImageStream</code> which can lead to a rebuild of your app image (and any other builds that you have for other images that reference the <code>ImageStreamTag</code>), and again, a new roll out of your app (and any other apps from other such builds).</p>
</li>
</ol>
<p>^This is just one example of how you might make use of an <code>ImageStream</code>, and is not meant to be exhaustive.</p>
