“Kubernetes 和 OpenShift 有什么区别？” ——这个问题的提出令人羡慕。 尽管实际上这就像问汽车与发动机有何不同。 如果继续类比的话，那么汽车就是一个成品，你可以马上使用它，字面意思是：上车就走。 另一方面，为了让引擎带你去某个地方，它必须首先补充很多其他东西，才能最终得到同样的汽车。
因此，Kubernetes 是 OpenShift 品牌汽车（平台）的组装引擎，它将带您实现目标。
在本文中，我们想提醒您并更详细地检查以下要点：
- Kubernetes 是 OpenShift 平台的核心，它是 100% 认证的 Kubernetes，完全开源，没有丝毫专有性质。 简要地：
- OpenShift 集群 API XNUMX% Kubernetes。
- 如果容器在任何其他 Kubernetes 系统上运行，那么它将在 OpenShift 上运行，无需任何更改。 无需对应用程序进行更改。
- OpenShift 不仅为 Kubernetes 添加了有用的特性和功能。 就像汽车一样，OpenShift 开箱即用，可以立即投入生产，并且正如我们将在下面展示的那样，它使开发人员的生活变得更加轻松。 这就是 OpenShift 团结在两个人身上的原因。 从开发者的角度来看，它既是一个成功且知名的企业级PaaS平台。 同时，从产业运营的角度来看，它是一个超级可靠的容器即服务解决方案。
OpenShift 是 100% CNCF 认证的 Kubernetes
OpenShift 是基于 。 因此，经过适当的培训，用户会对 kubectl 的强大感到惊讶。 那些从 Kubernetes 集群切换到 OpenShift 的人经常说，他们非常喜欢将 kubeconfig 重定向到 OpenShift 集群后，所有现有脚本都能完美运行。
您可能听说过 OpenShift 的命令行实用程序 OC。 它与 kubectl 命令完全兼容，此外它还提供了几个有用的帮助程序，在执行许多任务时会派上用场。 但首先，我们先了解一下 OC 和 kubectl 的兼容性：
kubectl 命令
OC 团队
kubectl得到豆荚
oc 获取 pod
kubectl 获取命名空间
oc 获取命名空间
kubectl create -f 部署.yaml
oc create -f 部署.yaml
以下是在 OpenShift API 上使用 kubectl 的结果：
• kubectl get pods – 按预期返回 pod。
• kubectl get namespaces – 按预期返回命名空间。
命令 kubectl create -f mydeployment.yaml 创建 kubernetes 资源，就像在任何其他 Kubernetes 平台上一样，如下面的视频所示：
换句话说，所有 Kubernetes API 在 OpenShift 中完全可用，同时保持 100% 兼容性。 因此 .
OpenShift 为 Kubernetes 添加了有用的功能
Kubernetes API 在 OpenShift 中 100% 可用，但标准 Kubernetes 实用程序 kubectl 显然缺乏功能和便利性。 这就是为什么红帽向 Kubernetes 添加了有用的功能和命令行工具，例如 OC（OpenShift 客户端的缩写）和 ODO（OpenShift DO，该实用程序针对开发人员）。
1. OC实用程序-更强大、更方便的Kubectl版本
例如，与 kubectl 不同，它允许您创建新的命名空间并轻松切换上下文，并且还为开发人员提供了许多有用的命令，例如构建容器映像以及直接从源代码或二进制文件部署应用程序（Source-to-image、 s2i）。
让我们看一下 OC 实用程序的内置帮助程序和高级功能如何帮助简化日常工作的示例。
第一个例子是命名空间管理。 每个 Kubernetes 集群总是有多个命名空间。 它们通常用于创建开发和生产环境，但也可用于为每个开发人员提供个人沙箱等。 实际上，这导致开发人员必须频繁地在命名空间之间切换，因为 kubectl 在当前空间的上下文中运行。 因此，就 kubectl 而言，人们积极使用辅助脚本来实现此目的。 但是在使用OC时，要切换到所需的空间，只需说“oc项目命名空间”即可。
不记得您需要的命名空间叫什么？ 没问题，只需输入“oc get items”即可显示完整列表。 怀疑如果您只能访问集群上有限的命名空间子集，这将如何工作？ 嗯，因为 kubectl 仅在 RBAC 允许您查看集群上的所有空间时才能正确执行此操作，并且在大型集群中，并非每个人都获得此类权限。 所以，我们的回答是：对于OC来说这根本不是问题，在这种情况下它很容易产生一个完整的列表。 正是这些小事，构成了Openshift的企业定位以及这个平台在用户和应用方面良好的可扩展性
2. ODO - 面向开发者的 kubectl 改进版本
红帽 OpenShift 相对 Kubernetes 的改进的另一个例子是 ODO 命令行实用程序。 它专为开发人员设计，允许您快速将本地代码部署到远程 OpenShift 集群。 它还可以简化内部流程，立即将所有代码更改同步到远程 OpenShift 集群上的容器，而无需重新构建、注册和重新部署映像。
让我们看看 OC 和 ODO 如何使容器和 Kubernetes 的使用变得更容易。
只需比较几个基于 kubectl 构建的工作流程以及使用 OC 或 ODO 的工作流程即可。
• 为不会使用 YAML 的人员在 OpenShift 上部署代码：
Kubernetes/kubectl
$>git 克隆
1- 创建一个从代码构建镜像的 Dockerfile
-----
从节点
工作目录 /usr/src/app
复制包*.json ./
复制index.js ./
复制 ./应用程序 ./应用程序
运行 npm 安装
曝光 3000
CMD [“npm”,“开始”] ————–
2-我们建立形象
$>podman 构建...
3-登录注册表
podman登录...
4-将图像放入注册表中
podman 推送
5- 创建用于应用程序部署的 yaml 文件（deployment.yaml、service.yaml、ingress.yaml） - 这是绝对最小值
6-部署清单文件：
Kubectl apply -f 。
OpenShift/oc
$> oc 新应用程序 – 我们的应用程序名称
OpenShift/odo
$>git 克隆
$> odo 创建组件 nodejs myapp
$>odo 推送
• 上下文切换：更改工作命名空间或工作集群。
Kubernetes/kubectl
1- 在 kubeconfig 中为项目“myproject”创建上下文
2- kubectl 设置上下文...
OpenShift/oc
oc 项目“myproject”
质量控制：“这里出现了一个有趣的功能，仍处于 alpha 版本。 也许我们可以将其投入生产？”
想象一下，坐在一辆赛车里，被告知：“我们安装了一种新型制动器，说实话，它们的可靠性还不太好……不过不用担心，我们会在课程中积极改进它们”冠军的。” 您觉得这个前景如何？ 不知何故，我们红帽不太高兴。 🙂
因此，我们尝试推迟 alpha 版本，直到它们足够成熟并且我们已经完成了彻底的战斗测试并认为它们可以安全使用。 通常，一切都会首先经过开发预览阶段，然后经过 然后才作为公开发布 （GA），它已经非常稳定，适合生产。
这是为什么？ 因为，与任何其他软件的开发一样，并非 Kubernetes 中的所有最初想法都会达到最终版本。 或者他们达到了目标，甚至保留了预期的功能，但他们的实现与 alpha 版本中的实现完全不同。 由于成千上万的红帽客户使用 OpenShift 来支持关键任务工作负载，因此我们特别重视平台的稳定性和长期支持。
红帽致力于频繁发布 OpenShift 并更新其附带的 Kubernetes 版本。 例如，在撰写本文时，OpenShift 4.3 的当前 GA 版本包括 Kubernetes 1.16，它仅比 Kubernetes 上游版本 1.17 落后一个单元。 因此，我们正在努力为客户提供企业级 Kubernetes，并在发布新版本的 OpenShift 时提供额外的质量控制。
软件修复：“我们生产的 Kubernetes 版本存在一个漏洞。 而且你只能通过更新三个版本来关闭它。 或者有什么选择吗？
在 Kubernetes 开源项目中，软件修复通常作为下一个版本的一部分发布，有时覆盖一两个之前的里程碑版本，覆盖范围可缩短至 6 个月。
红帽以比其他公司更早发布关键修复程序并提供更长时间的支持而自豪。 以 Kubernetes 提权漏洞为例（）：它是在 Kubernetes 1.11 中发现的，并且仅在 1.10.11 版本之前发布了对之前版本的修复，使得这一问题在所有之前的 Kubernetes 版本（从 1.x 到 1.9）中都存在。
反过来， （Kubernetes 1.2 已经存在），捕获了 XNUMX 个 OpenShift 版本并清楚地展示了对客户的关心（更多详细信息 ).
OpenShift 和 Red Hat 如何推动 Kubernetes 向前发展
红帽是开源 Kubernetes 项目的第二大软件贡献者，仅次于 Google，最多产的 3 个开发人员中有 5 位来自红帽。 另一个鲜为人知的事实是：Kubernetes 中出现的许多关键功能正是在红帽的倡议下出现的，特别是，例如：
- RBAC。 Kubernetes 没有 RBAC 功能（ClusterRole、ClusterRoleBinding），直到红帽工程师决定将它们实现为平台本身的一部分，而不是作为附加的 OpenShift 功能。 红帽是否害怕改进 Kubernetes？ 当然不是，因为红帽严格遵循开源原则，不玩Open Core游戏。 由开发社区（而不是专有社区）推动的改进和创新更可行且更广泛采用，这与我们使开源软件对客户更有用的核心目标非常一致。
- Pod 的安全策略（Pod 安全策略）。 这种在 Pod 内安全运行应用程序的概念最初是在 OpenShift 中以 SCC（安全上下文约束）的名称实现的。 和前面的例子一样，红帽决定将这些开发引入到开放的 Kubernetes 项目中，以便每个人都可以使用它们。
这一系列的例子可以继续，但我们只是想表明红帽真正致力于开发 Kubernetes 并使其更好地为每个人服务。
很明显，OpenShift 就是 Kubernetes。 有什么区别？ 🙂
我们希望通过阅读本文，您已经意识到 Kubernetes 是 OpenShift 的核心组件。 主要的一个，但远非唯一的一个。 换句话说，仅仅安装 Kubernetes 并不会给你一个企业级平台。 您需要添加身份验证、网络、安全、监控、日志管理等。 另外，您必须从大量可用工具中做出一些艰难的选择（要了解生态系统的多样性，只需看看 ）并以某种方式确保一致性和连贯性，以便它们作为一个整体工作。 此外，每当您使用的任何组件的新版本发布时，您都需要定期执行更新和回归测试。 也就是说，除了创建和维护平台本身之外，您还需要处理所有这些软件。 不太可能有太多时间来解决业务问题并获得竞争优势。
但就 OpenShift 而言，红帽承担了所有这些复杂性，只是为您提供了一个功能完整的平台，其中不仅包括 Kubernetes 本身，还包括将 Kubernetes 转变为真正的企业级的整套必要的开源工具您可以立即、完全从容地投入生产的解决方案。 当然，如果您拥有一些自己的技术堆栈，那么您可以将 OpenShift 集成到现有的解决方案中。
看一下上图：Kubernetes 矩形之外的所有内容都是红帽添加的功能，正如他们所说，Kubernetes 没有的功能。 现在我们将看看这些领域的主要内容。
1. 强大的操作系统作为基础：RHEL CoreOS 或 RHEL
20 多年来，红帽一直是关键业务应用程序 Linux 发行版的领先提供商。 我们在该领域积累和不断更新的经验使我们能够为集装箱的工业运营提供真正可靠和值得信赖的基础。 RHEL CoreOS 使用与 RHEL 相同的内核，但主要针对运行容器和运行 Kubernetes 集群等任务进行了优化：其较小的尺寸和不变性使得设置集群、自动扩展、部署补丁等变得更加容易。所有这些功能都使其为在从裸机到私有云和公共云的各种计算环境中使用 OpenShift 提供相同的用户体验奠定了理想的基础。
2. IT运营自动化
安装过程和第二天操作（即日常操作）的自动化是 OpenShift 的强项，使得在最高级别上管理、更新和维护容器平台的性能变得更加容易。 这是通过 OpenShift 4 内核级别对 Kubernetes 运算符的支持来实现的。
OpenShift 4 也是一个基于 Kubernetes Operator 的完整解决方案生态系统，由红帽本身和第三方合作伙伴开发（请参阅. 红帽或运营商商店 ，由红帽为第三方开发人员创建）。
集成的 OpenShift 4 目录包括 180 多个 Kubernetes Operator
3. 开发者工具
自 2011 年以来，OpenShift 已作为 PaaS（平台即服务）平台提供，使开发人员的生活变得更加轻松，帮助他们专注于编码，并为 Java、Node.js 等编程语言提供本机支持、PHP、Ruby、Python、Go，以及 CI/CD 持续集成和交付服务、数据库等。OpenShift 4 提供 ，其中包括红帽和我们的合作伙伴开发的基于 Kubernetes Operator 的 100 多个服务。
与 Kubernetes 不同，OpenShift 4 有一个专用的 GUI（），它可以帮助开发人员轻松地将来自各种来源（git、外部注册表、Dockerfile 等）的应用程序部署到其命名空间中，并清晰地可视化应用程序组件之间的关系。
此外，OpenShift 还提供了一套 Codeready 开发工具，其中特别包括 ，一个完全容器化的 IDE，具有直接在 OpenShift 之上运行的 Web 界面，并实现了 IDE 即服务方法。 另一方面，对于那些想要严格在本地模式下工作的人来说，可以使用 Codeready Containers，它是 OpenShift 4 的全功能版本，可以部署在笔记本电脑上。
集成 IDE 即服务，可在 Kubernetes/OpenShift 平台上进行高效开发
OpenShift 提供开箱即用的完整 CI/CD 系统，基于容器化 Jenkins 和插件 用于使用管道或面向 Kubernetes 的 CI/CD 系统 （目前处于技术预览版）。 这两种解决方案都与 OpenShift 控制台完全集成，允许您运行管道触发器、查看部署、日志等。
4. 应用工具
OpenShift 允许您部署传统的有状态应用程序和基于新架构（例如微服务或无服务器）的基于云的解决方案。 OpenShift Service Mesh 解决方案开箱即用，配有用于维护微服务的关键工具，例如 Istio、Kiali 和 Jaeger。 反过来，OpenShift Serverless 解决方案不仅包括 Knative，还包括 Keda 等工具，这些工具是与 Microsoft 联合计划的一部分，旨在在 OpenShift 平台上提供 Azure 功能。
集成解决方案 OpenShift ServiceMesh（Istio、Kiali、Jaeger）在开发微服务时将非常有用
为了弥合遗留应用程序和容器之间的差距，OpenShift 现在允许使用容器本机虚拟化（目前处于 TechPreview 状态）将虚拟机迁移到 OpenShift 平台，从而使混合应用程序成为现实，并促进它们在不同云（私有云和公共云）之间的迁移。
通过容器本机虚拟化在 OpenShift 上运行的 Windows 2019 Virtual 虚拟机（当前处于技术预览版）
5. 集群工具
任何企业级平台都必须具有监控和集中日志服务、安全机制、身份验证和授权以及网络管理工具。 而 OpenShift 开箱即用地提供了这一切，而且全部是 100% 开源的，包括 ElasticSearch、Prometheus、Grafana 等解决方案。 所有这些解决方案都附带使用红帽广泛的集群监控专业知识构建和配置的仪表板、指标和警报，使您可以从一开始就有效地控制和监控您的生产环境。
OpenShift 还标配了对企业客户来说非常重要的功能，例如使用内置 oauth 提供程序进行身份验证、与凭证提供程序（包括 LDAP、ActiveDirectory、OpenID Connect 等）集成。
用于 OpenShift 集群监控的预配置 Grafana 仪表板
超过 150 个用于 OpenShift 集群监控的预配置 Prometheus 指标和警报
待续
解决方案的丰富功能以及红帽在 Kubernetes 领域的丰富经验是 OpenShift 取得市场主导地位的原因，如下图所示（了解更多 ).
“红帽目前以 44% 的份额领先市场。
该公司正在收获以客户为中心的销售策略的好处，该策略首先为企业开发人员提供咨询和培训，然后随着企业开始将容器部署到生产中而转向货币化。”
（来源： )
我们希望您喜欢这篇文章。 在本系列的后续文章中，我们将在此处讨论的每个类别中仔细研究 OpenShift 相对于 Kubernetes 的优势。
来源： habr.com