1.2. 规划迁移

在把系统迁移到 OpenShift Container Platform 4.2 前,需要花时间来正确地规划整个转换过程。OpenShift Container Platform 4 引入了与架构相关的更改和增强,因此您用来管理 OpenShift Container Platform 3 集群的操作可能不适用于 OpenShift Container Platform 4。

注意

本计划文档假定您要从 OpenShift Container Platform 3.11 转换到 OpenShift Container Platform 4.2。

本文档提供了有关 OpenShift Container Platform 3 和 OpenShift Container Platform 4 之间重要的区别,以及在迁移时需要注意的重要迁移注意事项。有关配置 OpenShift Container Platform 4 集群的详细信息,请查阅 OpenShift Container Platform 文档的适当章节。如需了解有关新功能和其他显著技术更改的详细信息,请参阅 OpenShift Container Platform 4.2 发行注记

无法将现有 OpenShift Container Platform 3 集群升级到 OpenShift Container Platform 4。您必须开始新的 OpenShift Container Platform 4 安装。然后使用提供的工具来帮助迁移 control plane 设置和应用程序工作负载。

1.2.1. OpenShift Container Platform 3 和 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 、MachineSets 和 Red Hat Enterprise Linux CoreOS (RHCOS) ,它们是集群操作的核心。这个技术转换使集群能够自我管理以前需要由管理员执行的一些功能。这也确保平台的稳定性和一致性,并简化了安装和扩展。

如需更多信息,请参阅 OpenShift Container Platform 架构

1.2.1.1. 架构的不同

不可变基础架构

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 中,control plane 节点必须运行 RHCOS,以确保为 control plane 维护全堆栈的自动化。这使得更新和升级的过程比在 OpenShift Container Platform 3 中要容易。

如需更多信息,请参阅 Red Hat Enterprise Linux CoreOS

Operator

Operator 是一种打包、部署和管理 Kubernetes 应用程序的方法。Operator 可简化运行另一部分软件的操作复杂性。它们会关检测您的环境,并使用当前状态实时做出决定。高级 Operator 旨在自动升级并对失败做出适当的响应。

如需更多信息,请参阅 Understanding Operators

1.2.1.2. 安装和更新的不同

安装过程

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

对于 OpenShift Container Platform 4.2,需要使用 OpenShift 安装程序创建集群所需的最小资源集合。集群运行后,您可以使用 Operator 来进一步配置集群并安装新服务。首次启动后,RHCOS 系统由 OpenShift Container Platform 集群中运行的 Machine Config Operator (MCO) 进行管理。

如需更多信息,请参阅 安装过程

如果要将 RHEL worker 机器添加到 OpenShift Container Platform 4.2 集群中,您可以使用 Ansible playbook 在集群运行后加入 RHEL worker 机器。如需更多信息,请参阅在 OpenShift Container Platform 集群中添加 RHEL 计算机器

基础架构选项

对于 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.2 中,集群管理自己的更新,包括集群节点上的 Red Hat Enterprise Linux CoreOS (RHCOS) 的更新。您可以使用 Web 控制台或使用 OpenShift CLI 的 oc adm upgrade 命令轻松升级集群,Operator 会自动升级其自身。如果您的 OpenShift Container Platform 4.2 集群有 Red Hat Enterprise Linux worker 机器,那么您仍需要运行 Ansible playbook 来升级这些 worker 机器。

详细信息请参阅 Updating a cluster。

1.2.2. 迁移考虑

查看可能会影响 OpenShift Container Platform 3.11 转换到 OpenShift Container Platform 4 的更改和其他注意事项。

1.2.2.1. 存储注意事项

在从 OpenShift Container Platform 3.11 转换到 OpenShift Container Platform 4.2 时,请考虑以下与存储相关的变化。

本地卷持久性存储

只有在 OpenShift Container Platform 4.2 中使用 Local Storage Operator 才支持本地存储。不支持使用 OpenShift Container Platform 3.11 的 local provisioner 方法。

如需更多信息,请参阅 使用本地卷的持久性存储

FlexVolume 持久性存储

FlexVolume 插件位置已与 OpenShift Container Platform 3.11 中的不同。它在 OpenShift Container Platform 4.2 中的新位置为 /etc/kubernetes/kubelet-plugins/volume/exec。不再支持可附加的 FlexVolume 插件。

如需更多信息,请参阅使用 FlexVolume 的持久性存储

使用容器存储接口 (CSI) 的持久性存储

使用 Container Storage Interface (CSI) 的持久性存储在 OpenShift Container Platform 3.11 中是一个技术预览功能 。OpenShift Container Platform 4.2 完全支持 CSI 版本 1.1.0,但不附带任何 CSI 驱动程序。您必须安装自己的驱动程序。

使用容器存储接口 (CSI) 的持久性存储

OpenShift Container Storage

Red Hat OpenShift Container Storage 3 可以与 OpenShift Container Platform 3.11 一起使用,使用 Red Hat Gluster Storage 作为后端存储。

Red Hat OpenShift Container Storage 4 可以与 OpenShift Container Platform 4 一起使用,使用 Red Hat Ceph Storage 作为后备存储。

如需更多信息,请参阅使用 Red Hat OpenShift Container Storage 做为持久性存储系统互操作性文档 。

可用的持久性存储选项

OpenShift Container Platform 4.2 中更改了对 OpenShift Container Platform 3.11 的以下持久性存储选项的支持:

  • GlusterFS 不再被支持。
  • CephFS 作为独立产品不再被支持。
  • Ceph RBD 作为独立产品不再被支持。
  • iSCSI 现在是技术预览。

如果您在 OpenShift Container Platform 3.11 中使用了其中之一,则需要选择不同的持久性存储选项以便在 OpenShift Container Platform 4.2 中提供全面支持。

如需更多信息,请参阅了解持久性存储

1.2.2.2. 网络注意事项

在从 OpenShift Container Platform 3.11 转换到 OpenShift Container Platform 4.2 时,请考虑以下与网络相关的变化。

网络隔离模式

虽然用户经常切换为使用 ovn-multitenant,但是 OpenShift Container Platform 3.11 的默认网络隔离模式是 ovs-subnet。OpenShift Container Platform 4.2 的默认网络隔离模式是 NetworkPolicy。

如果您的 OpenShift Container Platform 3.11 集群使用了 ovs-subnetovs-multitenant 模式,则建议在 OpenShift Container Platform 4.2 集群中将模式切换为 NetworkPolicy。NetworkPolicy 支持上游,更灵活,同时还提供 ovs-multitenant 的功能。如果您要在 OpenShift Container Platform 4.2 中使用 NetworkPolicy 时仍然希望维持 ovs-multitenant 的行为 ,请按照以下步骤使用 NetworkPolicy 配置多租户隔离

如需更多信息,请参阅 关于网络策略

加密主机间的网络数据

在 OpenShift Container Platform 3.11 中,您可以使用 IPsec 来加密主机间的网络流量。OpenShift Container Platform 4.2 不支持 IPsec。建议使用 Red Hat OpenShift Service Mesh 在服务间启用 mutual TLS。

如需更多信息,请参阅了解 Red Hat OpenShift Service Mesh

1.2.2.3. 日志记录注意事项

在从 OpenShift Container Platform 3.11 转换到 OpenShift Container Platform 4.2 时,请考虑以下与日志相关的变化。

部署集群日志记录

OpenShift Container Platform 4 通过使用集群日志记录自定义资源,为集群日志记录提供了一个简单的部署机制。部署后,集群日志记录体验与 OpenShift Container Platform 3.11 相同。

如需更多信息,请参阅关于部署和配置集群日志记录

聚合日志数据

您无法将 OpenShift Container Platform 3.11 的聚合日志记录数据转换到新的 OpenShift Container Platform 4 集群中。

如需更多信息,请参阅关于集群日志记录

1.2.2.4. 安全考虑

在从 OpenShift Container Platform 3.11 转换到 OpenShift Container Platform 4.2 时,请考虑以下与安全相关的变化。

对发现端点的未验证访问

在 OpenShift Container Platform 3.11 中,未经身份验证的用户可以访问发现端点(例如: /api/*/apis/*)。为了安全起见,OpenShift Container Platform 4.2 不再允许对发现端点进行未经身份验证的访问。如果确实需要允许未经身份验证的访问,可根据需要配置 RBAC 设置,但请务必考虑安全性影响,因为这可能会使内部集群组件暴露给外部网络。

用户身份供应商

为 OpenShift Container Platform 4 配置身份供应商包括以下显著的更改:

  • OpenShift Container Platform 4.2 中的请求标头身份提供程序需要 mutual TLS,而这在 OpenShift Container Platform 3.11 中不需要。
  • OpenShift Container Platform 4.2 中简化了 OpenID Connect 身份提供程序的配置。现在,它从供应商的 /.well-known/OpenID-configuration 端点获取数据。而之前需要在 OpenShift Container Platform 3.11 中指定。

如需更多信息,请参阅 Understanding identity provider configuration

1.2.2.5. 监控注意事项

在从 OpenShift Container Platform 3.11 转换到 OpenShift Container Platform 4.2 时,请考虑以下与监控相关的变化。

监控基础架构可用性的警报

OpenShift Container Platform 3.11 中,触发的确保监控结构可用的默认警报称为 DeadMansSwitch 。在 OpenShift Container Platform 4 中,它被重新命名为 Watchdog 。如果您在 OpenShift Container Platform 3.11 中使用带有此警报设置的 PagerDuty 集成,则需要在 OpenShift Container Platform 4 中使用带有 Watchdog 警报设置的 PagerDuty 集成。

如需更多信息,请参阅 应用自定义 Alertmanager 配置