OpenShift 文档正在迁移，很快将仅在 docs.redhat.com（所有 Red Hat 产品文档的中心）提供。立即体验 新的文档体验。
  1. 文档
    2. history bug_report picture_as_pdf
×

OpenShift Container Platform 3 和 4 的区别

OpenShift Container Platform 4.17 引入了架构更改和增强功能/您用于管理 OpenShift Container Platform 3 集群的过程可能不适用于 OpenShift Container Platform 4。

有关配置 OpenShift Container Platform 4 集群的信息，请查看 OpenShift Container Platform 文档中的相关章节。有关新功能和其他值得注意的技术更改的信息，请查看OpenShift Container Platform 4.17 发行说明。

无法将现有的 OpenShift Container Platform 3 集群升级到 OpenShift Container Platform 4。必须从新的 OpenShift Container Platform 4 安装开始。可以使用一些工具来帮助迁移控制平面设置和应用程序工作负载。

架构

在 OpenShift Container Platform 3 中，管理员单独部署 Red Hat Enterprise Linux (RHEL) 主机，然后在其上安装 OpenShift Container Platform 以形成集群。管理员负责正确配置这些主机并执行更新。

OpenShift Container Platform 4 代表了 OpenShift Container Platform 集群部署和管理方式的重大变化。OpenShift Container Platform 4 包含新的技术和功能，例如 Operators、机器集和 Red Hat Enterprise Linux CoreOS (RHCOS)，这些都是集群运行的核心。这种技术转变使集群能够自我管理以前由管理员执行的一些功能。这也有助于确保平台的稳定性和一致性，并简化安装和扩展。

从 OpenShift Container Platform 4.13 开始，RHCOS 现在使用 Red Hat Enterprise Linux (RHEL) 9.2 包。此增强功能支持最新的修复程序和功能以及最新的硬件支持和驱动程序更新。有关此 RHEL 9.2 升级如何影响您的选项配置和服务以及驱动程序和容器支持的更多信息，请参阅OpenShift Container Platform 4.13 发行说明中的RHCOS 现在使用 RHEL 9.2。

有关更多信息，请参阅OpenShift Container Platform 架构。

不可变基础设施

OpenShift Container Platform 4 使用 Red Hat Enterprise Linux CoreOS (RHCOS)，它专为运行容器化应用程序而设计，并提供高效的安装、基于 Operator 的管理和简化的升级。RHCOS 是一个不可变的容器主机，而不是像 RHEL 那样可定制的操作系统。RHCOS 使 OpenShift Container Platform 4 能够管理和自动化底层容器主机的部署。RHCOS 是 OpenShift Container Platform 的一部分，这意味着所有内容都在容器内运行，并使用 OpenShift Container Platform 部署。

在 OpenShift Container Platform 4 中，控制平面节点必须运行 RHCOS，以确保控制平面的全栈自动化。这使得推出更新和升级比在 OpenShift Container Platform 3 中容易得多。

更多信息，请参见 Red Hat Enterprise Linux CoreOS (RHCOS)。

Operators

Operators 是一种打包、部署和管理 Kubernetes 应用程序的方法。Operators 降低了运行另一软件的操作复杂性。它们监控您的环境，并使用当前状态实时做出决策。高级 Operators 旨在自动升级并对故障做出反应。

更多信息，请参见 理解 Operators。

安装和升级

安装过程

要安装 OpenShift Container Platform 3.11，您需要准备 Red Hat Enterprise Linux (RHEL) 主机，设置集群所需的所有配置值，然后运行 Ansible playbook 来安装和设置您的集群。

在 OpenShift Container Platform 4.17 中，您使用 OpenShift 安装程序创建集群所需的最小资源集。集群运行后，您可以使用 Operators 来进一步配置集群并安装新服务。首次启动后，Red Hat Enterprise Linux CoreOS (RHCOS) 系统由在 OpenShift Container Platform 集群中运行的 Machine Config Operator (MCO) 管理。

更多信息，请参见 安装过程。

如果要将 Red Hat Enterprise Linux (RHEL) 工作节点添加到 OpenShift Container Platform 4.17 集群，则可以在集群运行后使用 Ansible playbook 加入 RHEL 工作节点。更多信息，请参见 将 RHEL 计算节点添加到 OpenShift Container Platform 集群。

基础架构选项

在 OpenShift Container Platform 3.11 中，您在已准备和维护的基础架构上安装集群。除了提供您自己的基础架构外，OpenShift Container Platform 4 还提供了一个选项，可以在 OpenShift Container Platform 安装程序配置并由集群维护的基础架构上部署集群。

更多信息，请参见 OpenShift Container Platform 安装概述。

升级您的集群

在 OpenShift Container Platform 3.11 中，您可以通过运行 Ansible playbook 来升级集群。在 OpenShift Container Platform 4.17 中，集群管理自身的更新，包括集群节点上 Red Hat Enterprise Linux CoreOS (RHCOS) 的更新。您可以使用 Web 控制台或使用 OpenShift CLI 中的 `oc adm upgrade` 命令轻松升级集群，并且 Operators 将自动升级自身。如果您的 OpenShift Container Platform 4.17 集群有 RHEL 工作节点，则您仍然需要运行 Ansible playbook 来升级这些工作节点。

更多信息，请参见 更新集群。

迁移注意事项

查看可能影响您从 OpenShift Container Platform 3.11 迁移到 OpenShift Container Platform 4 的更改和其他注意事项。

存储注意事项

查看从 OpenShift Container Platform 3.11 迁移到 OpenShift Container Platform 4.17 时需要考虑的以下存储更改。

本地卷持久存储

本地存储仅在 OpenShift Container Platform 4.17 中使用 Local Storage Operator 支持。不支持使用 OpenShift Container Platform 3.11 中的本地供应程序方法。

更多信息，请参见 使用本地卷的持久存储。

FlexVolume 持久存储

FlexVolume 插件位置已从 OpenShift Container Platform 3.11 更改。OpenShift Container Platform 4.17 中的新位置是 `/etc/kubernetes/kubelet-plugins/volume/exec`。不再支持可附加 FlexVolume 插件。

更多信息，请参见 使用 FlexVolume 的持久存储。

容器存储接口 (CSI) 持久存储

使用容器存储接口 (CSI) 的持久存储在 OpenShift Container Platform 3.11 中为 技术预览。OpenShift Container Platform 4.17 附带 多个 CSI 驱动程序。您也可以安装您自己的驱动程序。

更多信息，请参见 使用容器存储接口 (CSI) 的持久存储。

Red Hat OpenShift Data Foundation

OpenShift Container Storage 3 可用于 OpenShift Container Platform 3.11，它使用 Red Hat Gluster Storage 作为后端存储。

Red Hat OpenShift Data Foundation 4 可用于 OpenShift Container Platform 4，它使用 Red Hat Ceph Storage 作为后端存储。

更多信息，请参见 使用 Red Hat OpenShift Data Foundation 的持久存储 和 互操作性矩阵 文章。

不受支持的持久存储选项

OpenShift Container Platform 4.17 中对 OpenShift Container Platform 3.11 中以下持久存储选项的支持已更改

  • 不再支持 GlusterFS。

  • 不再支持 CephFS 作为独立产品。

  • 不再支持 Ceph RBD 作为独立产品。

如果您在 OpenShift Container Platform 3.11 中使用了其中一种，则必须为 OpenShift Container Platform 4.17 中的全面支持选择其他持久存储选项。

更多信息，请参见 理解持久存储。

将树内卷迁移到 CSI 驱动程序

OpenShift Container Platform 4 正在将其树内卷插件迁移到其容器存储接口 (CSI) 对应项。在 OpenShift Container Platform 4.17 中，CSI 驱动程序是以下树内卷类型的新的默认值

  • Amazon Web Services (AWS) Elastic Block Storage (EBS)

  • Azure 磁盘

  • Azure 文件

  • Google Cloud Platform 持久磁盘 (GCP PD)

  • OpenStack Cinder

  • VMware vSphere

    从 OpenShift Container Platform 4.13 开始，默认情况下 VMware vSphere 不可用。但是，您可以选择加入 VMware vSphere。

卷生命周期的所有方面，例如创建、删除、安装和卸载，都由 CSI 驱动程序处理。

更多信息，请参见 CSI 自动迁移。

网络注意事项

查看从 OpenShift Container Platform 3.11 迁移到 OpenShift Container Platform 4.17 时需要考虑的以下网络更改。

网络隔离模式

OpenShift Container Platform 3.11 的默认网络隔离模式为 `ovs-subnet`，尽管用户经常切换到使用 `ovn-multitenant`。OpenShift Container Platform 4.17 的默认网络隔离模式由网络策略控制。

如果您的 OpenShift Container Platform 3.11 集群使用了ovs-subnet或ovs-multitenant模式，建议您在 OpenShift Container Platform 4.17 集群中切换到网络策略。网络策略得到上游支持，更加灵活，并且提供了ovs-multitenant的功能。如果您想在 OpenShift Container Platform 4.17 中使用网络策略的同时保持ovs-multitenant的行为，请按照步骤使用网络策略配置多租户隔离。

更多信息，请参见关于网络策略。

OVN-Kubernetes 作为 Red Hat OpenShift Networking 中的默认网络插件

在 OpenShift Container Platform 3.11 中，OpenShift SDN 是 Red Hat OpenShift Networking 中的默认网络插件。在 OpenShift Container Platform 4.17 中，OVN-Kubernetes 现在是默认的网络插件。

有关移除 OpenShift SDN 网络插件以及移除原因的更多信息，请参见OCP 4.17 中的 OpenShiftSDN CNI 移除。

有关 OVN-Kubernetes 中与 OpenShift SDN 插件中的功能类似的功能信息，请参见

您应该使用 OVN-Kubernetes 网络插件安装 OpenShift Container Platform 4，因为如果使用 OpenShift SDN 网络插件，则无法将集群升级到 OpenShift Container Platform 4.17。

日志记录注意事项

从 OpenShift Container Platform 3.11 迁移到 OpenShift Container Platform 4.17 时，请查看以下需要考虑的日志记录更改。

部署 OpenShift 日志记录

OpenShift Container Platform 4 通过使用集群日志记录自定义资源，提供了一种简单的 OpenShift 日志记录部署机制。

聚合日志数据

您无法将聚合日志数据从 OpenShift Container Platform 3.11 迁移到新的 OpenShift Container Platform 4 集群。

不支持的日志记录配置

OpenShift Container Platform 3.11 中提供的一些日志记录配置在 OpenShift Container Platform 4.17 中不再受支持。

安全注意事项

从 OpenShift Container Platform 3.11 迁移到 OpenShift Container Platform 4.17 时，请查看以下需要考虑的安全更改。

对发现端点的未经身份验证的访问

在 OpenShift Container Platform 3.11 中，未经身份验证的用户可以访问发现端点（例如，/api/*和/apis/*）。出于安全原因，OpenShift Container Platform 4.17 中不再允许对发现端点进行未经身份验证的访问。如果您确实需要允许未经身份验证的访问，您可以根据需要配置 RBAC 设置；但是，请务必考虑安全隐患，因为这可能会将内部集群组件暴露给外部网络。

身份提供者

OpenShift Container Platform 4 的身份提供者配置已更改，包括以下值得注意的更改

  • OpenShift Container Platform 4.17 中的请求头身份提供者需要相互 TLS，而 OpenShift Container Platform 3.11 中则不需要。

  • OpenShift Container Platform 4.17 中简化了 OpenID Connect 身份提供者的配置。它现在从提供程序的/.well-known/openid-configuration端点获取以前必须在 OpenShift Container Platform 3.11 中指定的数据。

更多信息，请参见了解身份提供者配置。

OAuth 令牌存储格式

新创建的 OAuth HTTP 承载令牌不再与其 OAuth 访问令牌对象名称匹配。对象名称现在是承载令牌的哈希值，不再敏感。这降低了泄露敏感信息的风险。

默认安全上下文约束

OpenShift Container Platform 4 中的restricted安全上下文约束 (SCC) 不再像 OpenShift Container Platform 3.11 中的restricted SCC 一样可以被任何已验证用户访问。现在，广泛的已验证访问权限授予restricted-v2 SCC，它比旧的restricted SCC 更严格。restricted SCC 仍然存在；想要使用它的用户必须被明确授予权限。

更多信息，请参见管理安全上下文约束。

监控注意事项

从 OpenShift Container Platform 3.11 迁移到 OpenShift Container Platform 4.17 时，请查看以下监控更改。您无法将 Hawkular 配置和指标迁移到 Prometheus。

监控基础设施可用性警报

在 OpenShift Container Platform 3.11 中，触发以确保监控结构可用性的默认警报称为DeadMansSwitch。在 OpenShift Container Platform 4 中，它被重命名为Watchdog。如果您在 OpenShift Container Platform 3.11 中为此警报设置了 PagerDuty 集成，则必须在 OpenShift Container Platform 4 中为Watchdog警报设置 PagerDuty 集成。

更多信息，请参见应用自定义 Alertmanager 配置。