有什么区别 - docker 镜像与 openshift 镜像流?

问题描述

谁能解释一下什么是 openshift imagestream 以及它与常规 docker 镜像有何不同。

我已经阅读了这个 (Understanding containers,images,and imagestreams) 文档,但它没有对图像流进行太多解释。

我知道 docker 镜像是创建容器的蓝图。只是想知道图像团队是??

解决方法

与 Kubernetes 中的许多(所有?)种类一样,ImageStream 是一种抽象。如果您可以将 Pod 想象为正在运行的容器的概念的抽象,那么您可以将 ImageStream 想象为映像注册表中存储库概念的抽象(例如 quay .io,或 OpenShift 集群中的内部容器注册表)。

这是一个 an actual repository in an image registry 示例,您可以在其中看到它包含与图像不同版本对应的标签列表。 enter image description here

这是一个 ImageStream 示例,如 OpenShift Web 控制台中所示。您可以看到它包含一个标签列表,就像前面的外部注册表中的存储库示例一样。 enter image description here

在这里您可以看到 ImageStreamTags 实际上指向注册表中的不同存储库,例如 rhscl/python-27-rhel7ubi8/python-38。甚至还有一个 ImageStreamTag 指向列表底部的另一个 ImageStreamTag 的示例。因此,它并不完全是到图像注册表的 1:1 映射,而是一种更高级别的抽象。

作为您可能选择使用的示例,假设您想在 OpenShift 集群中运行 Python 应用程序。您可以拥有一个 BuildConfig,它知道如何构建您的镜像,方法是从您的 Git 存储库中获取源代码,构建它并将其分层在 Python 3.8 基础镜像之上。然后当它构建时,你希望这个新版本替换集群中正在运行的版本。

这里有几个地方可以让您受益于 ImageStreams

  1. 如果您的 BuildConfig 中引用的基础 Python 3.8 图像是 ImageStreamTag(例如上面示例图片中的 python:3.8)而不是直接在存储库中的图像标签在注册表中;那么您可以定期更新 ImageStreamTag,如果存储库中的基本映像已更新,则可以触发应用映像的新构建。

  2. 如果您的构建输出到您的 ImageStreamTag 中引用的 Deployment,那么您的 Deployment 可以自动(或不)更新以推出您的新版本应用。

  3. 如果您想更改基础 Python 3.8 映像以指向不同的映像(例如来自不同注册表中的不同供应商,或您自己的自定义映像),那么您只需更新 {{1 }} 在 ImageStreamTag 中,这可能会导致重建您的应用程序映像(以及您为引用 ImageStream 的其他映像所拥有的任何其他版本),并再次推出您的应用程序(以及来自其他此类版本的任何其他应用)。

^这只是您可能如何使用 ImageStreamTag 的一个示例,并不意味着详尽无遗。