👴 👂🏾 ✊ OpenShift作为Kubernetes的企业版 👩🏾‍🤝‍👨🏽 ‼️ 🧑🏽‍🤝‍🧑🏼

“ Kubernetes和OpenShift有什么区别？” -令人羡慕的持续性引起了这个问题。尽管实际上这就像问汽车与引擎有何不同。如果我们继续类推，那么汽车就是成品，您可以立即按字面意义使用它：您坐下来走了。另一方面，为了使引擎将您带到某个地方，必须首先补充许多其他事项，以便最终获得同一辆汽车。

因此，Kubernetes就是这样一种引擎，在其周围组装了OpenShift品牌的汽车（平台），将您带到了目标。

在本文中，我们想回顾并更详细地分析以下关键点：

Kubernetes是OpenShift平台的核心，它是100％Kubernetes认证的，完全开源的，没有丝毫的专有性。简而言之：
- API OpenShift – Kubernetes.
- Kubernetes, - OpenShift. .
OpenShift Kubernetes . , OpenShift , , , . OpenShift . , PaaS- , . Container-as-a-Service .

OpenShift – Kubernetes 100% CNCF

OpenShift基于Kubernetes认证。因此，在经过适当的培训后，用户会欣赏kubectl的强大功能。那些使用Kubernetes Cluster切换到OpenShift的人经常说，将kubeconfig重定向到OpenShift集群后，他们有多喜欢，所有可用的脚本都能正常工作。

您可能听说过称为OC的OpenShift命令行实用程序。它与kubectl命令完全兼容，此外它还提供了一些有用的helper'ov，它们在执行许多任务时非常有用。但是首先，更多关于OC和kubectl的兼容性：

Kubectl团队	OC团队
kubectl得到豆荚	oc获取广告连播
kubectl获取名称空间	oc获取名称空间
kubectl创建-f deployment.yaml	oc创建-f deployment.yaml

在OpenShift API上使用kubectl的结果如下所示：

•kubectl get pods-预期会返回pods。

•kubectl get命名空间-完全可以返回命名空间。

就像在任何其他Kubernetes平台上一样，kubectl create -f mydeployment.yaml命令创建kubernetes资源，如以下视频所示：

换句话说，所有Kubernetes的API都可以在OpenShift中完全访问，并且具有100％的兼容性。这就是为什么OpenShift被Cloud Native Computing Foundation（CNCF）认可为经过认证的Kubernetes平台。

OpenShift具有实用功能支持Kubernetes

Kubernetes的API在OpenShift中100％可用，但是常规Kubernetes的kubectl实用程序显然缺乏功能和便利性。因此，红帽添加了具有有用功能和命令行工具的Kubernetes，例如OC（OpenShift客户端的缩写）和ODO（OpenShift DO，此实用程序是为开发人员设计的）。

1. OC实用程序-Kubectl的更强大和便捷的版本

例如，与kubectl不同，它允许您创建新的名称空间并轻松切换上下文，还为开发人员提供了许多有用的命令，例如，用于构建容器映像并直接从源代码或二进制文件（源到映像， s2i）。

让我们看一下OC实用程序的内置帮助程序和高级功能如何帮助简化日常工作的示例。

示例一是名称空间管理。每个Kubernetes集群始终具有多个名称空间。通常，它们用于创建开发和生产环境，但也可以用于例如为每个开发人员提供个人的“沙盒”。实际上，由于kubectl在当前空间的上下文中工作，因此这导致开发人员经常必须在命名空间之间切换。因此，在kubectl的情况下，人们为此积极使用帮助程序脚本。但是，当使用OC切换到所需的空间时，只需说“ oc project namespace_”。

不记得命名空间是什么了吗？没问题，只需键入“ oc get projects”即可显示完整列表。怀疑地想知道如果您只能访问群集上有限的一部分名称空间，这将如何工作？好吧，因为kubectl正确执行了此操作，所以只有在RBAC允许您查看群集上以及所有大型群集中的所有空间时，并不是每个人都具有这种权限。因此，我们回答：对于OC，这根本不是问题，在这种情况下，它很容易给出完整的列表。正是由于这些琐碎的事情，才构成了Openshift的企业重点以及该平台在用户和应用程序方面的良好可伸缩性

2. ODO-针对开发人员的kubectl的改进版本

Red Hat OpenShift对Kubernetes进行改进的另一个示例是ODO命令行实用程序。它供开发人员使用，并允许您在远程OpenShift群集上快速部署本地代码。此外，它可以用于优化内部流程，以立即将所有代码更改与远程OpenShift集群上的容器同步，而无需重新组装，放置在注册表中和重新部署映像。

让我们看看OC和ODO如何使容器和Kubernetes更容易。

只需比较几个基于kubectl构建的工作流程以及使用OC或ODO的工作流程即可。

•为不讲YAML语言的人在OpenShift上部署代码：

Kubernetes / kubectl	$> git clone github.com/sclorg/nodejs-ex.git 1- Dockerfile, ————– FROM node WORKDIR /usr/src/app COPY package*.json ./ COPY index.js ./ COPY ./app ./app RUN npm install EXPOSE 3000 CMD [ “npm”, “start” ] ————– 2- $> podman build … 3- podman login … 4- podman push 5- yaml- (deployment.yaml, service.yaml, ingress.yaml) – 6- manifest-: Kubectl apply -f .
OpenShift / oc	$> oc new-app github.com/sclorg/nodejs-ex.git – __
OpenShift / odo	$> git clone github.com/sclorg/nodejs-ex.git $> odo create component nodejs myapp $> odo push

• : .

Kubernetes / kubectl	1- kubeconfig “myproject” 2- kubectl set-context …
OpenShift / oc	oc project “myproject”

: « , -. ?»

想象一下，您坐在一辆赛车上，他们说：“我们在这里放了一种新型的制动器，坦率地说，它们还没有满足可靠性的所有要求。但是不用担心，我们会在锦标赛过程中积极改进它们。”您如何看待这个前景？在红帽，我们不是很满意。 :)

因此，我们尽量避免使用Alpha版本，直到它们足够成熟为止，并且我们没有进行全面的战斗测试，并认为可以安全使用它们。通常，一切都首先经过开发预览阶段，然后经过技术预览，然后才以公开发布的通用可用性（GA）形式出现，该通用性已经足够稳定以适合于生产。

这是为什么？因为，与开发任何其他软件一样，并不是Kubernetes中的所有最初构想都能达到最终版本。或者它们达到甚至保留了预期的功能，但是它们的实现与alpha版本中的实现根本不同。由于成千上万的Red Hat客户使用OpenShift来支持关键任务，因此我们特别强调平台的稳定性和长期支持。

红帽故意发布频繁的OpenShift版本，并更新其Kubernetes版本。例如，在撰写本文时，OpenShift 4.3的GA版本包括Kubernetes 1.16，它仅比Kubernetes上游版本1.17落后一个单位。因此，我们尝试为企业级Kubernetes客户提供服务，并在发布新版本的OpenShift的过程中提供额外的质量控制。

软件修复：“我们在生产中使用的Kubernetes版本存在漏洞。而且您只能通过更新三个版本来关闭它。还是有选择？”

作为Kubernetes开源项目的一部分，软件修补程序通常作为下一个版本的一部分发布，有时它们涵盖一个或两个以前的临时版本，而这些临时版本仅在6个月前才涉及。

红帽公司有理由以比其他公司更早发布关键修订并提供更长的支持为荣。例如，Kubernetes特权升级漏洞（CVE-2018-1002105）：在Kubernetes 1.11中发现了该漏洞，并且以前版本的补丁仅发布到了1.10.11版本，在所有以前的Kubernetes版本中都存在漏洞，从1开始.x到1.9。

反过来，Red Hat将OpenShift修补回3.2版（Kubernetes 1.2站在那里），捕捉9点OpenShift发布和展示客户服务（更多信息在这里）。

OpenShift和Red Hat如何推动Kubernetes向前发展

在对Kubernetes开源软件的贡献方面，红帽排名第二，仅次于Google，在5个最丰富的开发人员中有3个在Red Hat工作。另一个鲜为人知的事实：Kubernetes正是在Red Hat的倡议下出现了许多关键功能，例如：

RBAC. Kubernetes RBAC (ClusterRole, ClusterRoleBinding) , Red Hat , OpenShift. Red Hat Kubernetes? , Red Hat , Open Core. , , , , – .
Pod的安全策略（Pod安全策略）。最初，这种在Pod中安全执行应用程序的概念是在OpenShift中以SCC（安全上下文约束）的名称实现的。就像前面的示例一样，Red Hat决定将这些开发内容引入开源Kubernetes项目中，以便每个人都可以使用它们。

这一系列示例可以继续，但是我们只是想表明Red Hat确实在努力开发Kubernetes，并使其对每个人都更好。

显然，OpenShift是Kubernetes。有什么区别？:)

我们希望阅读完这一点后，您意识到Kubernetes是OpenShift的主要组件。基本的，但不是唯一的。换句话说，仅安装Kubernetes就不会获得企业级平台。您将需要添加身份验证，网络，安全性，监视，日志管理等。此外，您将不得不从大量可用工具中做出艰难的选择（要评估生态系统的多样性，只需查看CNCF图），并以某种方式确保连贯性和连贯性，以使它们作为一个整体发挥作用。此外，发布任何使用的组件的新版本时，您将必须定期执行更新和回归测试。也就是说，除了创建和维护平台本身之外，您还需要处理所有这些软件。在这里解决解决业务问题和获得竞争优势的时间不多。

但是在OpenShift的情况下，Red Hat克服了所有这些困难，只为您提供了功能上完整的平台，其中不仅包括Kubernetes本身，而且还包括使Kubernetes成为真正的企业级解决方案的全套必要开源工具。立即完全平静地投入生产。当然，如果您拥有任何技术堆栈，则可以将OpenShift嵌入到现有解决方案中。

OpenShift是一个智能的Kubernetes平台，

请看上面的图片：Kubernetes矩形之外的所有区域都是Red Hat添加Kubernetes不具备的功能的区域，这被称为设计。现在，我们将考虑这些领域中的主要领域。

1.以可靠的操作系统为基础：RHEL CoreOS或RHEL

20多年来，红帽一直是关键任务业务应用程序Linux发行版的领先提供商。在这方面获得的经验和不断更新的经验使我们能够为集装箱的工业运行提供真正可靠和可信赖的基础。RHEL CoreOS使用与RHEL相同的内核，但主要针对诸如运行容器和在Kubernetes集群中工作之类的任务进行了优化：减小的尺寸和不变性简化了集群的安装，自动扩展，补丁的部署等。所有这些功能使其成为在从裸机到私有云和公共云的各种计算环境中使用OpenShift时获得相同用户体验的理想基础。

2. IT操作自动化

第二天的安装过程和操作（即日常操作）的自动化是OpenShift的特长，它极大地简化了最高级别的容器平台的管理，更新和维护。这是通过在

OpenShift 4 的核心级别上对Kubernetes运营商提供支持来实现的。OpenShift4 还是基于Red Hat和第三方合作伙伴共同开发的Kubernetes运营商的完整解决方案生态系统（请参阅Red Hat 运营商目录或运营商商店）。由Red Hat为第三方开发人员创建的operatorhub.io）。

OpenShift 4集成目录包括180多个Kubernetes运营商

3.开发人员工具

自2011年以来，OpenShift已作为PaaS（平台即服务）平台提供，这大大简化了开发人员的生活，帮助他们专注于代码创建，并为Java，Node.js，PHP， Ruby，Python，Go以及CI / CD持续集成和交付服务，数据库等。OpenShift4提供了广泛的目录，其中包括基于Red Hat及其合作伙伴开发的Kubernetes运营商的100多种服务。

与Kubernetes不同，OpenShift 4具有特殊的图形界面（开发人员控制台），这有助于开发人员轻松地从各种来源（git，外部注册表，Dockerfile等）在其命名空间中部署应用程序，并可视化可视化应用程序组件之间的连接。

开发者控制台可可视化应用程序组件并简化使用Kubernetes的工作

；此外，OpenShift还提供了一套Codeready开发工具，其中包括 Codeready Workspaces，这是一个完全基于容器的基于Web的IDE，可直接在OpenShift之上运行并实现类似IDE的方法服务”。另一方面，对于那些希望严格在本地模式下工作的人，还有Codeready容器-可在笔记本电脑上部署的OpenShift 4的完整功能版本。

集成的“ IDE即服务”，可在Kubernetes / OpenShift平台上进行有效开发。OpenShift即开即用地

提供了完整的CI / CD系统，该系统基于容器化的Jenkins和用于管道的DSL插件，或基于Kubernetes CI / CD的Tekton系统（目前）在技术预览版中）。这两个解决方案都与OpenShift控制台完全集成，从而允许您运行管道触发器，查看部署，日志等。

4.应用工具

OpenShift允许您基于新架构（例如微服务或无服务器）部署传统的有状态应用程序和基于云的解决方案。开箱即用的OpenShift Service Mesh解决方案是支持Istio，Kiali和Jaeger等微服务工具的关键。反过来，OpenShift Serverless解决方案不仅包括Knative，还包括与Microsoft共同发起创建的Keda之类的工具，以在OpenShift平台上提供Azure功能。

集成的OpenShift ServiceMesh解决方案（Istio，Kiali，Jaeger）在开发微服务时非常有用，

为缩小传统应用程序和容器之间的差距，OpenShift现在允许使用Container Native Virtualization（当前为TechPreview版本）将虚拟机迁移到OpenShift平台，从而转变混合应用程序成为现实，并促进它们在私有云和公共云之间的转移。

通过容器本机虚拟化在OpenShift上运行的Windows 2019虚拟虚拟机（当前在技术预览版中）

5.集群工具

任何企业级平台都应具有监视和集中式日志记录服务，安全机制，身份验证和授权以及网络管理工具。 OpenShift提供了所有现成的功能，并且所有这些都是100％开源的，包括诸如ElasticSearch，Prometheus，Grafana之类的解决方案。所有这些解决方案均随附仪表板，指标和警报，这些仪表板，指标和警报已经基于Red Hat广泛的集群监视经验进行了配置，从而使您能够从一开始就有效地监视和跟踪生产环境。

OpenShift对于企业客户还具有重要的作用，例如与内置的oauth提供程序进行身份验证，与LDAP，ActiveDirectory，OpenID Connect等凭据提供程序集成。

预先配置的Grafana仪表板，用于监视OpenShift集群

超过150种Prometheus预先配置的度量标准和警报，用于监视OpenShift集群

未完待续

正是由于这些原因，OpenShift在市场上占据了主导地位，正因为这些原因，该解决方案的丰富功能和Red Hat在Kubernetes领域的丰富经验，如下图所示（此处有更多详细信息）。

“目前，红帽以44％的份额领先市场。
通过积极参与客户事务，该公司正在从销售策略中获益，在该过程中，该公司首先为公司开发人员提供咨询和培训，然后在该公司开始将容器引入生产中时进行货币化。”

（来源：www.lightreading.com/nfv/containers/ihs-red-hat-container-strategy-is-paying-off/d/d-id/753863）

我们希望您喜欢这篇文章。在本系列的下一篇文章中，我们将仔细研究OpenShift与Kubernetes相比在这里讨论的每个类别中的优势。

OpenShift作为Kubernetes的企业版