对比Kubernetes和OpenShift 2/2
6. A different approach to deployments 像前文Ingress/Router类似,OpenShift选择采用不同的方式管理部署。在Kubernetes中,有Deployment对象(您也可以在OpenShift中使用它们与所有其他Kubernetes对象一起使用)负责以滚动更新方式更新pod,并在控制器内部实现。 OpenShift有一个名为DeploymentConfig的类似对象,不是由控制器实现的,而是由基于专用pod控制整个过程的复杂逻辑实现的。它有一些缺点,但相对Kubernetes Deployment也有一个显著优势 - 你可以使用钩子(Hook)来准备你的环境以进行更新 - 例如通过更改数据库架构。这是一个很难用Deployment实现的功能(不,InitContainers不是一回事,因为它很难与许多运行的实例协调)。但是,在处理多个并发更新时,Kubernetes Deployment更好--DacementConfig根本不支持并发更新,而在Kubernetes中,您可以拥有许多并发更新,并且它将设法正确地扩展它们。 哪一个更好? OpenShift DeploymentConfig有更多选项并支持ImageStream,所以我选择它来替代传统的Kubernetes Deployment。 7. Better management of container images 这是我在Kubernetes中非常想要的,也是我个人最喜欢的OpenShift功能。 用于管理容器镜像的ImageStreams。 你知道在传统容器注册表中更改镜像的标签(Tag)有多“简单”吗? 如果没有skopeo等外部工具,您需要下载整个镜像,在本地更改并将其推回Registry。 通过更改容器标记和更新Deployment对象定义来提升应用程序也不是一种愉快的方法。 这就是我喜欢ImageStreams的原因,以下是主要原因和特点: 使用ImageStream,您可以上传一个容器镜像,然后在OpenShift内部管理它的虚拟标记(tag) - 在一个项目中,您将始终使用devel标记并仅在内部更改对它的引用,在prod上您将使用stable或prod标记并在内部管理它 在OpenShift中,不需要对注册表进行处理操作! 当使用带有DeploymentConfig的ImageStream时,您可以设置一个触发器(触发器/Hook),当新镜像出现或标签更改其引用时自动开始部署操作 - 它非常适合开发环境,其中app会在构建新版本时自行部署(无需任何CICD操作!) 使用触发器,您可以实现更多 - 当基础镜像发布新版本时,使用链式构建来创建我们的应用程序/工具的更新版本 您可以通过将镜像曝光为ImageStream来隐藏镜像本身 - 例如 jenkins指向一个原始的官方镜像,当你想要修改一些东西时,你构建自己的,将它推入你的注册表并仅需要更改ImageStream中的引用,而不是像传统的docker镜像那样部署配置 哪一个更好? OpenShift中的ImageStreams更赞! 8. Integrated CI/CD with Jenkins Red Hat在创建Kubernetes项目之前很久就创建了OpenShift,从一开始,它就是一个PaaS平台。 通过从他们的自定义解决方案(他们使用称为gears而不是容器的东西)切换到Kubernetes,更容易带来更多功能,其中最令人兴奋的是集成Jenkins。 有多种CI / CD软件解决方案,但Jenkins仍然是最大,使用最广泛,通用和成熟的解决方案。 它还经常与Kubernetes集群一起用于构建容器镜像,对它们执行持续集成任务,并将它们作为容器部署在具有Continuous