对比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

对比Kubernetes和OpenShift 1/2

10 most important differences between OpenShift and Kubernetes OpenShift经常被其供应商Red Hat称为“企业Kubernetes”。 在本文中,我描述了OpenShift和Kubernetes之间的真正差异。 它经常令人困惑,因为Red Hat倾向于将其描述为PaaS,有时隐藏Kubernetes是OpenShift不可或缺的一部分,OpenShift只是包含更多功能。 让我们深入研究一下这两者之间的真正差异。 1. OpenShift product vs. Kubernetes project Kubernetes是一个开源项目(甚至是一个框架),而OpenShift是一个有很多变种的产品。 有一个OpenShift的开源版本,叫做OKD。 以前它被称为OpenShift Origin,但Red Hat的一些“聪明”人提出了这个新名称,它的意思是“为Red Hat OpenShift提供动力的Kubernetes的原始社区发行版”(?)。 但是让我们先不要纠缠于它的名字,来关注它的含义。以下几点: OpenShift Container Platform是一种可以在您的基础架构上安装的产品,其中包含订阅后附带的付费技术支持 您需要为集群续订OpenShift订阅,并在群集增长时支付更多费用 Kubernetes有很多发行版,但它是一个项目,如果发生了不好的事情,你可以主要依靠社区或外部专家(在某些情况下,他们有时可能比Red Hat支持更好:-)) Kubernetes每年有很多版本(实际上有4个版本),OpenShift也有很多版本,但它落后于Kubernetes发布时间表 - 目前只有一个版本(OpenShift 3.10包括Kubernetes 1.10,而本文撰写本文时的最新版本是1.11) 作为产品,OpenShift订阅包括CloudForms,通过其功能增强它(例如可配置的退款,监控,中央配置等) OKD版本是免费使用的,包括其商业产品的大部分功能,但您不能购买技术支持,也不能使用基于Red Hat的官方容器镜像 因此,如果您需要Kubernetes的支持,一个选项是购买OpenShift的订阅。 如果你对自我支持感觉不错,那么当然还有Kubernetes有很多辅助项目,整个生态系统和梦幻般的社区。 对于犹豫不决的项目,有一个几乎拥有所有OpenShift功能的OKD项目 - 您可以稍后决定迁移到商业产品或坚持使用OKD。所以,从这个角度,哪一个更好?这取决于你是否愿意支付和使用RedHat的技术支持以及产品附带的所有功能(OpenShift)而不是项目(Kubernetes,还有OKD)和自助(没有技术支持)模型。 2. OpenShift limited installation vs. install Kubernetes (almost)