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) anywhere
如果您决定安装OpenShift，则需要将Red Hat Enterprise Linux（或Red Hat Atomic）用于OpenShift Container Platform或CentOS for OKD（也就是说OpenShift安装是受限制的）。 您无法将其安装在其他Linux发行版上。 另一方面，Kubernetes几乎可以安装在任何Linux发行版上，如Debian，Ubuntu（最受欢迎的版本）等等。
在选择OpenShift时，您可以按照参考指南手动安装它（是的，您需要使用ssh，yum，vim和其他老式工具安装它）或者使用openshift-ansible项目。 后者可能是一个更好的选择，但由于它需要考虑通用性，并且它是用Ansible编写的，它有点慢，复杂且难以排除故障。 它确实带来了企业环境所憧憬的一个主要特征 - 整个集群的滚动更新升级。 这是一个主要优势，当您决定升级Kubernetes集群时，您可能会很对这个特性非常感激。 Kubernetes有许多可用的安装工具（例如kubeadm，kube-spray，kops），其中一些更适合云，有些更通用也更复杂，由您自行决定如何安装集群并进行升级（ 如果它得到了工具的支持）。
关于平台选择自由的最后一件事是主要云平台上可用的服务。 Kubernetes可用于其中三个 - Google GCP上的GKE，亚马逊上的EKS和Microsoft Azure上的AKS。 OpenShift没有这样的服务 - 有一个名为OpenShift Online和OpenShift Dedicated的产品，但它们不能直接在云端和按需付费模式下使用。 但是，您始终可以使用以下方法测试单节点安装：
Minikube for Kubernetes
Minishift for OKD (formerly OpenShift Origin)
CDK for OpenShift Container Platform
哪一个更好？
Kubernetes已经成为一种标准，并且可以在比OpenShift更多的平台上使用。
3. OpenShift has more strict security policies than default Kubernetes
这可能是因为OpenShift产品的目标群体——企业级客户，其默认安全策略比Kubernetes更严格。 例如，Docker Hub上可用的大多数容器映像都不能在OpenShift上运行，因为它禁止以root身份运行容器，甚至许多官方映像都不符合此要求。 这就是为什么人们有时会感到困惑和愤怒，因为他们无法运行像Kubernetes那样的简单应用程序。 有一种简单的方法来禁用该策略，但它仍然显示了一种不同的安全方法。
此外，RBAC是OpenShift不可或缺的一部分，相对应的，有许多人在没有RBAC安全的情况下使用Kubernetes的很多版本。 这对于小型开发/测试设置是可以的，但在现实生活中，您希望拥有一定级别的权限 - 即使它有时难以学习和理解（因为它起初是这样）。 在OpenShift中，您实际上没有选择，您必须使用它并在部署越来越多的应用程序时学习它。
最后一部分是身份验证和授权模型。 OpenShift中还有其他机制可以轻松地与Active Directory集成，但更有趣的部分是对外部应用程序的授权。 作为OpenShift的一部分，您可以安装其他组件，如
Internal Container Registry
Logging stack based on EFK (ElasticSearch, Fluentd, Kibana)
Monitoring based on Prometheus
Jenkins
并且您使用单个帐户通过OAuth机制对其进行身份验证（运行为sidecars的oauth-proxies）。 这使得权限管理变得更容易，并且可以带来其他功能，例如EFK，您只能从您有权访问的命名空间/项目中查看日志。 是的 - 你也可以在Kubernetes上实现同样的目标，但这需要大量的工作。
哪一个更好？
当然是在OpenShift中默认采用绝对安全的方法。
4. OpenShift templates are less flexible than Kubernetes Helm charts
对于直接从Kubernetes世界直接使用Helm及charts的人来说，OpenShift模板作为部署整个资源堆栈的主要方法实在太简单了。 Helm charts使用了复杂模板和软件包版本控制而这是OpenShift模板所缺少的。 它使OpenShift上的部署更加困难，并且在大多数情况下，您需要一些外部包装器（就像我一样），使其在更复杂的场景中更加灵活和有用，而不仅仅是简单的一个pod应用程序部署。 Helm要好得多，但它的当前架构（Tiller组件安装为具有巨大权限的Pod）与OpenShift中更严格的安全策略不兼容。
OpenShift中还有一些其他选项，例如Automation Broker（以前称为Ansible Service Broker）或Service Catalog，但它们可以安装在Kubernetes上，反之，Helm不是OpenShift上的（支持）选项。 希望它将来Helm的第3版会改变，去除Tiller组件——Tiller组件很难保证安全。 在那之前，在使用OpenShift时，你需要以某种方式生活在那些不灵活的模板上，私底下羡慕那些看起来花哨的Helm charts。
哪一个更好？
Kubernetes Helm更灵活，即将推出的版本3将使其更安全，适用于更严肃的项目。
5. Routers on OpenShift vs. Ingress on Kubernetes
在Kubernetes推出Ingress之前很久，Red Hat就需要为OpenShift上运行的容器提供自动反向代理解决方案。 所以现在在OpenShift中我们有一个Route对象，它与Kubernetes中的Ingress几乎完全相同。 主要区别在于Route是由良好的、老旧的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 Ingres对象被OpenShift识别并由…router 翻译/实现。 这是向与Kubernetes的配置兼容的一大步，将来Ingres配置在OpenShift上无需任何修改即可启动。
哪一个更好？
两者都很棒，Ingress比Router更新，但没有Router成熟，但它们都做得很好。
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。 你知道在传统容器Registry中更改镜像的标签（Tag）有多“简单”吗？ 如果没有skopeo等外部工具，您需要下载整个镜像，在本地更改并将其推回Registry。 通过更改容器tag和更新Deployment对象定义来提升应用程序也不是一种愉快的方法。 这就是我喜欢ImageStreams的原因，以下是主要原因和特点：
- 使用ImageStream，您可以上传一个容器镜像，然后在OpenShift内部管理它的虚拟标记（tag） - 在一个项目中，您将始终使用devel标记并仅在内部更改对它的引用，在prod上您将使用stable或prod标记并在内部管理它 在OpenShift中，不需要对Registry进行处理操作！
- 当使用带有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 Deployment管道的多个环境中。 由于它如此受欢迎，因此将其作为OpenShift的内置部分使得整个CI / CD不那么痛苦。 这是我在OpenShift上集成的Jenkins最喜欢的功能列表：
- OAuth身份验证 - 使用您的OpenShift登录信息登录Jenkins，根据您在项目中的角色，您可以获得三个jenkins角色中的一个（查看，编辑或管理员）
- 支持源代码到镜像整个生命周期，允许您创建自定义jenkins镜像 —— 一些带有插件列表，自定义配置和其他资源的文件，使您可以在基础镜像更改时轻松更新它（该部分也可以自动化！） 并使用Jekins完全“immutable”模式
- 提供两个版本的模板 - 用于测试目的的临时版本和持久存储的持久存储，用于更严肃的工作，配置数据和作业历史记录与Jenkins本身分开保存，从而使其易于管理（例如升级，测试不同的插件集）
- 从正在运行的命名空间同步涉密对象 - 不同的涉密对象与Jenkins凭证同步，以便您的作业中可以使用用户名/密码，ssh密钥或秘密文本，而无需在Jenkins中创建它们
- 最后但并非也很重要 - 管道定义是一个单独的BuildConfig对象，是在Jenkins之外定义为一个简单的yaml文件中的OpenShift对象
哪一个更好？
再一次，OpenShift的一个附加功能使您可以轻松地使用CI / CD管道部署您的应用程序。
9. OpenShift projects are more than Kubernetes namespaces
这是一个微小的差异，在OpenShift中，projects只不过是具有附加功能的Kubernetes namespace。 除了支持描述和显示名称之类的琐碎事物（相信我 - 当你有几十个它们时它们会很有帮助），projects会添加一些默认对象。 目前，一些角色（精确的角色绑定对象）与project一起创建，但您可以修改默认project模板并使用它来设置其他对象。 一个很好的例子是关闭project以拒绝外部网络访问的网络策略——使得project默认情况下是隔离和安全的 - 如果您想通过明确创建其他策略来允许某种外部网络访问。 以类似的方式，您可以提供默认配额或限制范围对象，并根据您的组织规则预先配置新项目。
哪一个更好？
因为projects仅仅是添加了一些小特性的namespace，谈不上谁更好。
10. OpenShift is easier for beginners
作为最后一部分，我想强调用户体验方面的差异。 容器仍然是非常新的技术，并且其复杂的操作界面、访问接口使得它更难学习和掌握容器技术。 OpenShift版本的命令行和Web界面都要优于Kubernetes版本。
让我们从命令行操作界面开始吧。 在OpenShift上有一个oc命令，相当于Kubernetes的kubectl，但有以下不同之处：
- oc支持登录到OpenShift集群 - 使用kubectl，您需要获取认证凭据并使用一些外部工具创建kubeconfig文件
- oc允许你在项目/命名空间之间切换，而kubectl没有（你需要诸如kubens/kubectx之类的外部工具） - 如果你开始使用许多名称空间和集群，你会欣赏这个功能，相信我
- oc允许您从源构建容器映像，然后使用单个命令将其部署到环境中！ （oc new-app）它将为您创建所有必需的对象，然后您可以决定导出它们，更改并重新应用或存储在镜像库中的某个位置
另外，OpenShift的web console使用体验要明显优于Kubernetes dashboard。
总结：
有些人可能会认为我是一个完全的OpenShift粉丝，但实际上，我两个都爱。 毕竟，他们给予可以如此管理我们的容器化应用程序的能力，之前是只有像谷歌这样的独角兽公司才具备的。 因此，无论您选择哪种方式，您都将获得大量功能，让您的生活更轻松，您将进一步的爱上这种原生云世界(DevOps, CD, MicroService …)。
原文链接： https://cloudowski.com/articles/10-differences-between-openshift-and-kubernetes/