OpenShift被其供应商——Red Hat称为“ Enterprise Kubernetes”。在本文中，我将描述OpenShift和Kubernetes之间的真正差异。由于Red Hat倾向于将其描述为PaaS，因此常常令人困惑，有时掩盖了Kubernetes是OpenShift不可或缺的一部分，并围绕它构建了更多功能这一事实。让我们深入研究一下两者之间的真正区别。

1. OpenShift产品与Kubernetes项目

Kubernetes是一个开源的项目（甚至框架），而OpenShift是一个产品是有多种版本。其中一个称为OKD的OpenShift开源版本。以前它被称为OpenShift Origin，但是Red Hat的一些“聪明”的人想出了这个新名称，它的意思是“推动Red Hat OpenShift的Kubernetes的Origin社区发行版”（？）。但是，让我们暂时忘掉名称，只关注其含义。

有几个：

OpenShift Container Platform是一种产品，您可以将其安装在基础设施上，该产品包含订阅附带的付费支持
您需要为集群续订OpenShift订阅，并且随着集群的增长需要支付更多费用
Kubernetes有很多发行版，但这是一个项目，如果出现了故障，您可以主要依靠社区或外部专家（在某些情况下，它们有时可能比Red Hat支持的要好）
Kubernetes每年有很多版本（实际上是4个），OpenShift也有很多版本，但是它落后于Kubernetes的发布时间表—— 在撰写本文时，版本3远远落后于它（包括Kubernetes 1.11，而最新版本是1.14）而版本4是仅落后于一个版本，在以后的版本中应该紧随上游Kubernetes
作为产品，OpenShift订阅包括CloudForms（仅在版本3中），这些CloudForms通过其功能（例如，可配置的计费，监控，集中配置等）增强了它的功能。
OKD版本可以免费使用，并包含其商业产品的大多数功能，但是您不能购买支持，也不能使用基于Red Hat的官方镜像

因此，如果您需要对Kubernetes的支持，一种选择是购买OpenShift的订阅。如果您对自己的支持感到满意，那么当然会有Kubernetes，其中有大量的附带项目，整个生态系统和完善的社区。对于犹豫不决的人，有一个具有几乎所有OpenShift功能的OKD项目——您以后可以决定迁移到商业产品还是坚持使用OKD。

哪个更好？

这取决于您是否愿意付费和使用支持以及产品（OpenShift）附带的所有功能，而不是带有自助模型的项目（Kubernetes，还有OKD）。

2. OpenShift受限安装vs Kubernetes的无限制安装

如果您决定安装OpenShift，则需要使用

OpenShift 3上的Red Hat Enterprise Linux（RHEL）或Red Hat Atomic
仅在OpenShift 4上，Red Hat CoreOS（控制平面需要——主服务器和基础服务器，默认为计算节点），以及可选的RHEL（用于计算节点）
RHEL或CentOS（用于OKD）。

您不能将其安装在其他Linux发行版上。另一方面，Kubernetes几乎可以安装在任何Linux发行版上，例如Debian，Ubuntu（最受欢迎的发行版）和许多其他发行版。

在选择OpenShift进行安装时，您可以根据版本将其安装在多个平台上：

OpenShift 3——手动遵循参考指南（是的，您需要使用ssh，yum，vim和其他旧式工具进行安装）或带有openshift-ansible项目。后者可能是一个更好的选择，但是由于它需要通用并且是用Ansible编写的，所以它有点慢，复杂且难以解决。它确实具有企业环境所梦寐以求的主要功能—— 整个集群的滚动更新。这是一个主要优势，当您决定升级Kubernetes集群时，您可能会喜欢它。
OpenShift 4——具有简化且易于使用的安装程序，当前支持AWS和vSphere。它由专用的Operator软件执行，整个配置保存在群集内的ConfigMap中（而不是主服务器上的文件，如版本3）。仍然可以进行裸机安装，但是当前它们需要许多手动步骤。此外，它还需要Internet连接，因此无法使用离线安装。

另一方面，Kubernetes具有许多可用的安装工具（例如，kubeadm，kube-spray，kops），其中一些更适合云计算，一些更通用，更复杂，由您来决定如何安装集群并对其进行升级（如果该工具支持）。

关于平台选择自由的最后一件事是主要云平台上提供的服务。Kubernetes可在其中三个上使用——Google GCP上的GKE，Amazon AWS上的EKS和Microsoft Azure上的AKS。对于OpenShift，有一个名为OpenShift Online，OpenShift Dedicated和Azure上的OpenShift的产品。此外，您可以使用以下方法测试单节点安装：

Minikube为Kubernetes
适用于OKD的Minishift（以前称为OpenShift Origin）
用于OpenShift容器平台3的CDK
OpenShift容器平台4的CRC（CodeReady容器）

哪个更好？

Kubernetes已经成为一种标准，并且比OpenShift可以在更多平台上使用。但是，有了新的，更灵活，更快的安装程序，我们可以预期OpenShift将成为Kubernetes（在云中）的一个很好的替代方案。

3. OpenShift比默认的Kubernetes具有更严格的安全策略

这可能是因为OpenShift产品的目标群体，但实际上默认策略比Kubernetes上严格。例如，Docker Hub上可用的大多数容器镜像都不会在OpenShift上运行，因为它禁止以根用户身份运行容器，甚至许多官方镜像都不满足此要求。这就是为什么人们有时会感到困惑和愤怒，因为他们无法像在Kubernetes上那样运行简单的应用程序。有一种简便的方法可以禁用该策略，但是仍然显示出另一种安全性方法。

此外，RBAC是OpenShift不可或缺的一部分，因为有许多版本，而有些人则使用没有RBAC安全性的Kubernetes。小型的开发/测试设置是可以的，但是在现实生活中，您希望具有一定级别的权限——即使有时很难学习和理解（因为它是最初的）。在OpenShift中，您实际上别无选择，您必须在使用它并在其上部署越来越多的应用程序的过程中学习它。

最后一部分是身份验证和授权模型。OpenShift中还有其他机制可以简化与Active Directory的集成，但更有趣的部分是对外部应用程序的授权。作为OpenShift的一部分，您可以安装其他组件，例如：

内部容器厂库
基于EFK的日志记录堆栈（ElasticSearch，Fluentd，Kibana）
基于Prometheus的监控
Jenkins

并且您使用单个帐户通过OAuth机制（作为sidecars运行的oauth——代理）对其进行身份验证。这使权限管理更加容易，并且可以带来EFK等其他功能，在这些功能中，您只能看到您有权访问的名称空间/项目的日志。是的——您也可以在Kubernetes上实现相同的目标，但这需要大量工作。

哪个更好？

在OpenShift中绝对是“默认情况下安全”的方法。

4. OpenShift模板不如Kubernetes Helm charts灵活

对于直接来自Kubernetes世界的使用Helm及其镜像的人来说，OpenShift模板作为部署整个资源堆栈的主要方法太简单了。Helm charts使用复杂的模板和OpenShift模板所缺失的包版本控制。它使在OpenShift上的部署更加困难，并且在大多数情况下，您需要一些外部包安装管理程序（如我一样），以使其在更复杂的场景中比简单的一个pod应用程序部署更加灵活和有用。Helm 更好，但其当前架构（Tiller组件作为Pod安装需要具有非常大的权限）与OpenShift中更严格的安全策略不兼容。

OpenShift 3中还有其他一些可用选项，例如Automation Broker（以前称为Ansible Service Broker）或Service Catalog，但是可以将它们安装在Kubernetes上，而Helm不是OpenShift上的（受支持）选项。希望将来随着Helm第3版的出现而改变，届时将不会有使安全变得困难的Tiller组件。在此之前，在使用OpenShift时，您需要以某种方式适应那些不灵活的模板，并羡慕那些花哨的Helm charts。

OpenShift 4有一个集成的OperatorHub，它正成为提供服务（即数据库，队列系统）的首选方式。它将最终成为在OpenShift（以及Kubernetes）上部署服务的最佳方法。

哪个更好？

Kubernetes Helm更加灵活，即将发布的版本3将使其更加安全，并适用于更严格的项目。但是，随着OperatorHub上提供更多运算符，OpenShift 4将获得优势。

5. OpenShift上的路由器与Kubernetes上的Ingress

在Kubernetes提出Ingress之前，红帽就已经需要针对OpenShift上运行的容器的自动化反向代理解决方案。因此，现在在OpenShift中，我们有了Route对象，它的作用几乎与Kubernetes中的Ingress相同。主要区别在于，路由是由良好的HAproxy实施的，可以用基于F5 BIG-IP的商业解决方案代替。但是，在Kubernetes上，您有更多选择，因为Ingress是由多个服务器实现的接口，这些服务器从最流行的nginx，traefik，AWS ELB / ALB，GCE，Kong和包括HAproxy在内的其他服务。

那么您可能会问哪个更好？就个人而言，我认为OpenShift中的HAproxy更加成熟，尽管它没有某些Ingress实现的功能那么多。但是，在Kubernetes上，您可以使用不同的增强功能——我最喜欢的增强功能是与cert-manager的集成，该集成允许您自动管理SSL证书。没有更多的手动操作来颁发和更新证书，此外，由于与Letsencrypt集成，您可以免费使用受信任的CA ！

作为一个有趣的事实，我想提一下，从OpenShift 3.10开始，Kubernetes Ingress对象被OpenShift识别并由路由器转换/实现。这是向兼容为Kubernetes准备的配置迈出的一大步，现在无需任何修改即可在OpenShift上启动它。

哪个更好？

两者都很棒，Ingress比路由器更新，更不成熟，但它们做得很好。

6.一种不同的部署方法

与Ingress相似，OpenShift选择了一种不同的管理部署方式。在Kubernetes中，有一些Deployment对象（您也可以在OpenShift中将它们与所有其他Kubernetes对象一起使用）来负责以滚动更新方式更新Pod，并且在控制器内部实现。OpenShift有一个类似的对象DeploymentConfig，它不是由控制器实现的，而是由基于控制整个过程的专用容器的复杂逻辑实现的。它有一些缺点，但与Kubernetes部署相比，还有一个显着优势——您可以使用hooks为更新做好准备的环境——例如，通过更改数据库架构。这是一个很难用Deployment实施的漂亮功能（不，InitContainers是不一样的，因为很难与许多正在运行的实例协调它）。但是，部署在处理多个并发更新时会更好——DeploymentConfig根本不支持并发更新，在Kubernetes中您可以拥有许多更新，并且它将设法适当地扩展它们。

哪个更好？

OpenShift DeploymentConfig具有更多选项并支持ImageStream，因此我选择它而不是经典的Kubernetes Deployment。

7.更好地管理容器镜像

现在，这是我在Kubernetes中真正想念的东西，也是我个人最喜欢的OpenShift功能。ImageStreams用于管理容器镜像。您是否知道在容器注册表中更改镜像的标签有多“容易”？如果没有skopeo之类的外部工具，则需要下载整个镜像，在本地进行更改，然后将其推回。通过更改容器标签和更新Deployment对象定义来提升应用程序也不是一种令人愉快的方法。

这就是为什么我喜欢ImageStreams的原因，这是主要原因和功能：

使用ImageStream，您一次上传一个容器镜像，然后在OpenShift内部管理它的虚拟标签 ——在一个项目中，您将始终使用devel标签，并且仅在内部更改对它的引用；在prod上，您将使用稳定或prod标签并在内部进行管理在OpenShift中，不处理注册表！
当将ImageStream与DeploymentConfig结合使用时，您可以设置一个触发器，该触发器将在出现新映像或标记更改其引用时启动部署——非常适合在开发环境中构建新版本时应用程序自行部署的开发环境（无需任何CICD流程！）
借助触发器，您可以实现更多目标—— 链式构建可在发布新版本的基础镜像时创建应用程序/工具的更新版本——这是对从不安全镜像创建的所有容器映像的自动修补！
您可以通过将镜像公开为ImageStream来隐藏镜像的来源——例如，jinkins一次指向原始的正式镜像，并且当您要更改某些内容时，可以构建自己的镜像，将其推入注册表并仅更改ImageStream中的引用，而不是像传统docker镜像那样在部署配置中

哪个更好？

OpenShift中的ImageStream非常棒！

8.与Jenkins集成的CI/CD

红帽早在找到Kubernetes项目之前就创建了OpenShift，从一开始它就是一个PaaS平台。通过从其自定义解决方案切换（他们使用了称为*齿轮的*东西而不是容器）到Kubernetes上，带来更多功能变得更加容易，最令人兴奋的功能之一就是集成的Jenkins。有多种CI/CD软件解决方案可用，但Jenkins仍然是最大，最通用，通用和成熟的解决方案。它也经常与Kubernetes集群一起使用来构建容器镜像，在其上执行持续集成任务并通过持续部署管道将它们作为容器部署在多个环境中。由于它非常流行，因此将其作为OpenShift的内置部分可以减轻整个CI/CD的痛苦。这是我在OpenShift上集成Jenkins最喜欢的功能的列表：

OAuth身份验证——使用您的OpenShift登录名登录Jenkins，然后根据您在项目中所扮演的角色，获得分配的三个jenkins角色之一（查看，编辑或管理）。在OpenShift 4中，它最终可以用作单一登录（在版本3中，您每次必须使用相同的凭据登录到服务）。
支持源到镜像，允许您创建自定义的Jenkins镜像——带有插件列表，自定义配置和其他资源的一些文件，使您可以在源镜像更改时轻松更新它（该部分也可以自动化！）并在完全*“不变”的*模式下使用Jenkins
提供两个版本的模板——用于测试目的的临时模板和用于更重要的作业的持久存储模板，配置数据和作业历史记录与Jenkins本身分开保存，因此非常易于管理（例如升级、测试不同的插件集）
从运行它的命名空间中同步密钥对象——不同的密钥与Jenkins凭据同步，因此用户名/密码，ssh密钥或秘密文本可在您的作业中使用，而无需在Jenkins中创建它们
最后但并非最不重要的——管道定义是一个单独的*BuildConfig*对象，并且在Jenkins之外还被定义为来自简单yaml文件的OpenShift对象

哪个更好？

OpenShift的另一个功能再次使您可以轻松地通过CI/CD管道部署应用程序。

9. OpenShift项目不仅仅是Kubernetes namespace

这是一个小的区别，但是在OpenShift上，有些项目仅仅是带有附加特性的Kubernetes名称空间。除了诸如描述和显示名之类的琐碎事情（相信我，当你有很多这样的东西时，它们会很有帮助），项目还添加了一些默认对象。目前，一些角色（确切地说是RoleBinding对象）是与项目一起创建的，但是您可以修改默认的项目模板并使用它来提供其他对象。一个很好的例子就是网络策略，它可以为外部流量关闭项目，这样在默认情况下是隔离和安全的——如果您想允许某种流量，您可以通过显式创建其他策略来这样做。以类似的方式，您可以提供默认配额或LimitRange对象，并根据组织规则预先配置新项目。

哪个更好？

实际上，项目是具有少量功能的namespace。这里没有明显的赢家

10. OpenShift对于初学者来说更容易

作为最后一部分，我想强调用户体验方面的差异。容器仍然是新事物，并且具有复杂，复杂的界面来管理它们，使学习和适应变得更加困难。这就是为什么我发现命令行和Web界面的OpenShift版本都优于Kubernetes的版本。

让我们从cli开始。在OpenShift上有一个oc等效于Kubernetes 的命令，kubectl具有以下区别：

oc支持登录到OpenShift集群——使用kubectl，您需要获取凭据并kubeconfig使用一些外部工具创建文件
oc让您可以在项目/命名空间之间进行切换，而kubectl不必在其中切换（您需要外部工具，例如kubens/kubectx）——如果您开始使用许多namespace和集群，那么您会欣赏该功能的，相信我
oc允许您从源代码构建容器镜像，然后使用单个命令将其部署到环境中！（oc new-app）它将为您创建所有必需的对象，然后您可以决定导出它们，更改并重新应用或将其存储在存储库中的某个位置

让我们面对现实——如果您是初学者，那么一开始您不会触摸命令行——您可能会选择使用某些Web界面。当你看到这个

Kubernetes仪表板截图

您可能会像我第一次看到它时那样灰心（这是几年前的事，但是不幸的是它并没有改变很多）。它可能会让人不知所措，而且我个人在使用Kubernetes时不使用仪表板，因为它不会带来比命令行更多的信息，并且您无法更改大多数事情——几乎就像只读面板一样。让我们面对现实吧——仪表板在许多Kubernetes项目中并不是一流的项目。

现在，这里是OpenShift 3 Web控制台：

OpenShift 3 Web控制台屏幕截图

并在OpenShift 4中提供了重新设计的版本：

OpenShift 4 Web控制台屏幕截图

现在，我并不是说它是最好的Web界面，但我认为它是OpenShift的最好功能之一。首先，它具有一个登录窗口，它简单而琐碎，我知道它不应该是一项功能，但是您是否看到过Kubernetes的“登录窗口”？仪表板有一个登录窗口，您可以在其中提供令牌，并且老实说是令人困惑的，特别是对于初学者。所有大多数OpenShift Web控制台都非常有用，比Kubernetes仪表板要有用得多。实际上，您可以直接从中执行大约80％（甚至在OpenShift 4中为90％）的任务——无需启动命令行或处理yaml对象——实际上，它可以是日常管理OpenShift的主要工具。

哪个更好？

OpenShift。抱歉，Kubernetes，但是人们（包括我！）都喜欢并需要精美的Web控制台:——)

结论

你们中的有些人可能认为我是OpenShift的狂热粉丝，但实际上，我喜欢与OpenShift和Kubernetes一起工作。毕竟，它们使部署和管理我们的容器化应用成为可能，而这种方式仅适用于像Google这样的独角兽企业。因此，无论您选择哪种方式，都将获得大量功能，使您的生活更轻松，并且您的旅程将开始向云原生世界发展。

原文：https://cloudowski.com/articles/10-differences-between-openshift-and-kubernetes/

Openshift与Kubernetes的区别

Openshift首个支持企业级 Java 的 PaaS 平台，支持 JEE6 与 JBoss 和其 Eclipse 集成开发环境以及 Maven 和 Jenkins 自动化。使用 OpenShift 的人数及社区人数在不断增长。OpenShift基于Kubernetes，增加哪儿些功能？有什么区别?

1.Openshift 的 Web console

Openshift的web console采用node.js 与angularJS开发，支持实时推送,如下示例

2.集成容器管理与ImageStream

OpenShift Container Registry 自动管理镜像的版本，ImageStream包含所有镜像的原数据，但ImageStream不包含Image数据。

使用Image Stream的目的是方便地将一组相关联的镜像进行整合管理和使用。

Openshift默认为用户定义了一系列开箱即用的Image Stream。

#查看Image Stream对象
#oc get is -n openshift

3. Native CI/CD factory
原生支持Pipeline的Build实现CI/CD过程

Jenkins Plugin能直接触发openshift的构建和部署过程, 同时最吸引的特点是:

支持流水线Pipeline这种模式,便于在同一集群的多个项目(对应开发，测试，生产)环境或者多个集群(对应开发集群，Stage集群，生产集群)中进行发布。
流水线支持自定义不同的阶段，每个阶段完成不同的任务，比如可以定义阶段为: CI环境部署->Stage环境部署->Prd部署
一条流水线支持包含多个微服务，针对项目中包含多个微服务，一旦定制好流水线，就可以重复运行

4. 日志与监控

Openshift集成EFK(Elasticsearch, Fluentd and Kibana),实现应用程序日志聚合功能。从Openshift 3.7版本开始，可以选择部署Hawkular metrics或Prometheus做系统监控. 集成Source control management (SCM)，创建BuildConfig。

5. 版本控制集成

Openshift容器平台内置Git server的，也可以部署Gitlab。

6. Security安全

基于RBAC体系管理用户权限, 支持identity providers. 由于群集上运行的每个容器都与service accounts相关联，因此可能将secrects与这些service accounts相关联，并使它们自动关联到容器。这使基础结构能够管理提取和推送Image的secrects，生成和部署组件，还允许应用程序代码轻松利用这些secrects。开发人员（系统的客户端）通常从客户端程序进行 REST API 调用，例如或通过浏览器到 Web 控制台，并使用 OAuth 承载令牌进行通信。基础结构组件（如节点）使用由系统生成的客户端证书，包含他们的身份。在容器中运行的基础结构组件使用关联的令牌及其service account连接到 API。

7.Resources and API
有一些对象与Kubernates共享：